From otroan@employees.org Fri Feb 1 01:35:24 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E36621F87D4 for ; Fri, 1 Feb 2013 01:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jo7hdTCIQANC for ; Fri, 1 Feb 2013 01:35:24 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF2621F879D for ; Fri, 1 Feb 2013 01:35:24 -0800 (PST) Received: from dhcp-lys01-vla250-10-147-112-125.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 989595EA8; Fri, 1 Feb 2013 01:35:23 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474782DB@mbx-01.win.nominum.com> Date: Fri, 1 Feb 2013 10:35:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5BBAAB88-1770-42F3-AF0A-28D6F904D847@employees.org> References: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474782DB@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1499) Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-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, 01 Feb 2013 09:35:24 -0000 Ted, >> Folks, the authors of this draft feel it's ready for a WGLC. = There's been substantial discussion and comment already. This is = pretty important IPv6 deployment work, so more eyes are better. Please = review the draft and indicate whether or not you feel it is ready to be = published. We have been getting very anemic responses to working group = messages recently. Your response matters, so please do respond. >>=20 >> We will evaluate consensus after January 28. Thanks! >=20 > Bud offered some comment. Aside from that, nobody said they wanted = the draft to advance, and nobody objected. By default this means it = fails the last call and will not advance. Is that really the outcome = that people want, or was everybody just asleep when the WGLC went out? if I didn't say so, my apologies. I'm biased as one of the authors = though. the combination of RFC3315 and RFC3633 is broken. this document fixes = that. I really think we should advance this. cheers, Ole= From dankney@network1.net Fri Feb 1 05:30:40 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C797E21F8D94 for ; Fri, 1 Feb 2013 05:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVT7cA-By8qo for ; Fri, 1 Feb 2013 05:30:39 -0800 (PST) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id D641321F8D76 for ; Fri, 1 Feb 2013 05:30:39 -0800 (PST) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id CF778540039; Fri, 1 Feb 2013 08:30:38 -0500 (EST) Date: Fri, 1 Feb 2013 08:30:38 -0500 (EST) From: perl-list To: Ted Lemon Message-ID: <1407914982.50557.1359725438734.JavaMail.root@network1.net> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474782A7@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_50556_109457602.1359725438733" X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.2.2_GA_2852 (ZimbraWebClient - GC24 (Mac)/7.2.2_GA_2852) Cc: WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-load-balancing-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, 01 Feb 2013 13:30:40 -0000 ------=_Part_50556_109457602.1359725438733 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit in favor +1 > From: "Ted Lemon" > To: " WG" > Sent: Thursday, January 31, 2013 10:51:09 PM > Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-load-balancing-00 > This document got significant attention during the call for adoption. > The author feels it is ready to publish and have asked for a last > call. The document describes a load balancing algorithm for DHCPv6, > similar to the one described in RFC3074 for DHCPv4. > Please review the document if you haven't already. If you are in > favor of publishing the document, please say so on the mailing list. > If you oppose publication of the document, please also say so. If > you have comments, please raise them on the mailing list. > We will evaluate consensus on February 14. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg ------=_Part_50556_109457602.1359725438733 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'>in favor +1

From: "Ted Lemon" <Ted.Lemon@nominum.com>To: "<dhcwg@ietf.org> WG" <dhcwg@ietf.org>
Sent:= Thursday, January 31, 2013 10:51:09 PM
Subject: [dhcwg] WGLC= : draft-ietf-dhc-dhcpv6-load-balancing-00

This document got signific= ant attention during the call for adoption.   The author feels it is r= eady to publish and have asked for a last call.   The document describ= es a load balancing algorithm for DHCPv6, similar to the one described in R= FC3074 for DHCPv4.

Please review the document if you haven't already= .   If you are in favor of publishing the document, please say so on t= he mailing list.   If you oppose publication of the document, please a= lso say so.   If you have comments, please raise them on the mailing l= ist.

We will evaluate consensus on February 14.

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


------=_Part_50556_109457602.1359725438733-- From bs7652@att.com Fri Feb 1 06:17:51 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCC721F8849 for ; Fri, 1 Feb 2013 06:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.099 X-Spam-Level: X-Spam-Status: No, score=-107.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CglOsaVaKFbh for ; Fri, 1 Feb 2013 06:17:50 -0800 (PST) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id E0BFF21F8D8E for ; Fri, 1 Feb 2013 06:17:09 -0800 (PST) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo04.seg.att.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 56ecb015.728a4940.2528344.00-532.7012228.nbfkord-smmo04.seg.att.com (envelope-from ); Fri, 01 Feb 2013 14:17:09 +0000 (UTC) X-MXL-Hash: 510bce6547266df6-baae69361e60137bac30ed952c0b5bbac1fd4e13 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 46ecb015.0.2528333.00-250.7012181.nbfkord-smmo04.seg.att.com (envelope-from ); Fri, 01 Feb 2013 14:17:09 +0000 (UTC) X-MXL-Hash: 510bce6530e3a889-1dbbcb122cdec29b0b12f565cf71686b06296955 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r11EH66T013196; Fri, 1 Feb 2013 09:17:08 -0500 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r11EGx4w012895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Feb 2013 09:17:01 -0500 Received: from GAALPA1MSGHUB9F.ITServices.sbc.com (gaalpa1msghub9f.itservices.sbc.com [130.8.36.92]) by sflint04.pst.cso.att.com (RSA Interceptor); Fri, 1 Feb 2013 09:16:32 -0500 Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9F.ITServices.sbc.com ([130.8.36.92]) with mapi id 14.02.0328.009; Fri, 1 Feb 2013 09:16:31 -0500 From: "STARK, BARBARA H" To: Ole Troan , Ted Lemon Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 Thread-Index: Ac3Q9Rt2+8Dix9CVTYmAMJDRC/+QkghlkQXAABF0soADaH5GgAAFjGGAAACyGoA= Date: Fri, 1 Feb 2013 14:16:30 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130239E3D@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474782DB@mbx-01.win.nominum.com> <5BBAAB88-1770-42F3-AF0A-28D6F904D847@employees.org> In-Reply-To: <5BBAAB88-1770-42F3-AF0A-28D6F904D847@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.199.78.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=OKOQK1mB c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=XF2aQeIDtRMA:10 a=9oV8spxUhDkA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=jZl-t09KiaAA:10 a=48vgC7mUAAAA:8 a=8UUDuznKw0cwvv] X-AnalysisOut: [SNRDQA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10] Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-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, 01 Feb 2013 14:17:52 -0000 +1 I would like to see this draft published. Barbara > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Ole Troan > Sent: Friday, February 01, 2013 4:35 AM > To: Ted Lemon > Cc: dhc WG > Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >=20 > Ted, >=20 > >> Folks, the authors of this draft feel it's ready for a WGLC. There's= been > substantial discussion and comment already. This is pretty important IP= v6 > deployment work, so more eyes are better. Please review the draft and > indicate whether or not you feel it is ready to be published. We have b= een > getting very anemic responses to working group messages recently. Your > response matters, so please do respond. > >> > >> We will evaluate consensus after January 28. Thanks! > > > > Bud offered some comment. Aside from that, nobody said they wanted > the draft to advance, and nobody objected. By default this means it fai= ls the > last call and will not advance. Is that really the outcome that people = want, or > was everybody just asleep when the WGLC went out? >=20 > if I didn't say so, my apologies. I'm biased as one of the authors though= . >=20 > the combination of RFC3315 and RFC3633 is broken. this document fixes tha= t. > I really think we should advance this. >=20 > cheers, > Ole > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From rajiva@cisco.com Fri Feb 1 06:56:06 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D1A11E80A2; Fri, 1 Feb 2013 06:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpCX0Pg-DC5z; Fri, 1 Feb 2013 06:56:05 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id D298211E809B; Fri, 1 Feb 2013 06:56:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4000; q=dns/txt; s=iport; t=1359730565; x=1360940165; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=i+KYrgczB1Qq65fETSugpl42RSJF5saG26vSiy8M/oQ=; b=WIIW23X4XtPAeDxCo76vlzWRbqXgt9J7gsu488yuZSa4FVIvM6U9YAE4 Xlca+xxsxQ87B7ul3K8kOnRUkyMoKFBO5QnM75m2DsXYFSiveN+Tiopep VJlWi5fA+OnmstDc6LrXJAgDZ5H3Jj64yoNzGURuR/RMMNHgnQTFaOo8N s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMzWC1GtJV2Z/2dsb2JhbABFvy0Wc4IeAQEBBAEBATc0BAcMBgEIEQMBAQEBChQJLgsUCQgCBA4FCIgJDMMLjQsbg0dhA5c0jzOCfIFvNQ X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="scan'208";a="171765169" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 01 Feb 2013 14:56:04 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r11Eu4bw013045 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Feb 2013 14:56:04 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Fri, 1 Feb 2013 08:56:04 -0600 From: "Rajiv Asati (rajiva)" To: Maglione Roberta Thread-Topic: MAC Address Tracking via DHCP6 Thread-Index: AQHN/9giM3WALPSOxEqXmVcvCQGGwZhkq+IggAB9qoA= Date: Fri, 1 Feb 2013 14:56:03 +0000 Message-ID: In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE519D1A74F3@GRFMBX704BA020.griffon.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.86.115.198] Content-Type: text/plain; charset="us-ascii" Content-ID: <12E46AE29605234C94FE4AA57EF6C33E@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 01 Feb 2013 07:00:44 -0800 Cc: "dhcwg@ietf.org" , Brian Hamacher , "ipv6@ietf.org" , Philipp Kern Subject: Re: [dhcwg] MAC Address Tracking via DHCP6 X-BeenThere: dhcwg@ietf.org 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, 01 Feb 2013 14:56:06 -0000 Hi Maglione,=20 Thanks for your review and a good question. draft-ietf-dhc-addr-registration introduces a new IPv6 Neighbor Discovery option and a new DHCPv6 option to propagate the address registration information from the hosts to the network. It requires the changes on the host. draft-asati-dhc-ipv6-autoconfig-address-tracking, on the other hand, requires no changes to IPv6 Neighbor Discovery and no changes to the hosts. It introduces changes in DHCPv6 specific to the last hop router and the DHCP server, thereby keeping the changes within the network (and DHCP server). Cheers, Rajiv -----Original Message----- From: Maglione Roberta Date: Friday, February 1, 2013 3:26 AM To: Rajiv Asati Cc: "ipv6@ietf.org" , Philipp Kern , Brian Hamacher Subject: RE: MAC Address Tracking via DHCP6 >Hello Rajiv, > is there any relation between your draft and >draft-ietf-dhc-addr-registration-00? > >Thanks >Regards, >Roberta > > >-----Original Message----- >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of >Rajiv Asati (rajiva) >Sent: Thursday, January 31, 2013 6:27 PM >To: Philipp Kern; Brian Hamacher >Cc: ipv6@ietf.org >Subject: Re: MAC Address Tracking via DHCP6 > > >There is a better way out to track the IPv6 addresses used by the hosts >(via SLAAC or static) - > >http://tools.ietf.org/html/draft-asati-dhc-ipv6-autoconfig-address-trackin >g > >Cheers, >Rajiv > >-----Original Message----- >From: Philipp Kern >Organization: The Debian Project (http://www.debian.org) >Date: Wednesday, December 12, 2012 10:37 AM >To: Brian Hamacher >Cc: "ipv6@ietf.org" >Subject: Re: MAC Address Tracking > >>On Tue, Dec 11, 2012 at 04:04:14PM -0600, Brian Hamacher wrote: >>> I am looking for a good way to track my users MAC Addresses. I have a >>> test DHCPv6 server up and running ISC 4.1.1-P1. When I look through my >>> DHCP logs as well as my leases file I do not see the client MAC Address >>> anywhere. Do I need to enable an option to allow this to be logged? I >>> am looking to figure out how I can track what user had what IP Address >>> at any given time. The MAC Address is traditionally how I have done >>> this. >> >>One way would be to poll your routers' ND tables (like fetching ARP >>tables >>in IPv4). As soon as you use relaying you most certainly won't get a >>useable MAC address from your client, even though it might be possible in >>the same network segment. (The MAC address is not copied from the wire >>into the new relayed packet sent by the router to your server.) >> >>DHCPv6 uses the so-called client identifier extensively and not the MAC >>address anymore. So you cannot do any static assignment based on MAC >>addresses. >> >>Kind regards >>Philipp Kern > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > >Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >persone indicate. La diffusione, copia o qualsiasi altra azione derivante >dalla conoscenza di queste informazioni sono rigorosamente vietate. >Qualora abbiate ricevuto questo documento per errore siete cortesemente >pregati di darne 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, printing or use by anybody else is unauthorised. If you are not >the intended recipient, please delete this message and any attachments >and advise the sender by return e-mail, Thanks. > From cra@WPI.EDU Fri Feb 1 07:42:44 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D9121F8E09; Fri, 1 Feb 2013 07:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhUe3Bt8Bkop; Fri, 1 Feb 2013 07:42:43 -0800 (PST) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7090B21F8E08; Fri, 1 Feb 2013 07:42:43 -0800 (PST) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.14.6/8.14.6) with ESMTP id r11FgTZq004766; Fri, 1 Feb 2013 10:42:29 -0500 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU r11FgTZq004766 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1359733349; bh=GTRYhvZHV3IL9LYmgM4wnKz+fwL93lIidpTiy7ANdeY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=IBFLGH3UyY/cu9G1T2XgE3NBGW32IztDwaU4xr42XdjPkJcYDIjRlibM1WF/LyWU9 h1bk+IgoIs8RmhexQ56VTsV1u4fOtW3/59mGJ5WSEgs/7PBQQAgMiBjTYM6R525ZV0 1+P6aiYoMgeBX4eJLXdo8Xy0xjuDUy26eeiopnRQ= Received: from SMTP.WPI.EDU (SMTP.WPI.EDU [130.215.36.186]) by MAIL1.WPI.EDU (8.14.6/8.14.6) with ESMTP id r11FgTFq004759; Fri, 1 Feb 2013 10:42:29 -0500 Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by SMTP.WPI.EDU (8.14.4/8.14.4) with ESMTP id r11FgRYq013019; Fri, 1 Feb 2013 10:42:28 -0500 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (localhost [127.0.0.1]) by angus.ind.WPI.EDU (8.14.4/8.14.4) with ESMTP id r11FgRj7016358; Fri, 1 Feb 2013 10:42:27 -0500 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.4/8.14.4/Submit) id r11FgQ4F016357; Fri, 1 Feb 2013 10:42:26 -0500 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Fri, 1 Feb 2013 10:42:26 -0500 From: Chuck Anderson To: "Rajiv Asati (rajiva)" Message-ID: <20130201154226.GJ22295@angus.ind.WPI.EDU> Mail-Followup-To: "Rajiv Asati (rajiva)" , Maglione Roberta , "dhcwg@ietf.org" , Brian Hamacher , "ipv6@ietf.org" , Philipp Kern References: <282BBE8A501E1F4DA9C775F964BB21FE519D1A74F3@GRFMBX704BA020.griffon.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) Cc: "dhcwg@ietf.org" , Brian Hamacher , Philipp Kern , "ipv6@ietf.org" Subject: Re: [dhcwg] MAC Address Tracking via DHCP6 X-BeenThere: dhcwg@ietf.org 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, 01 Feb 2013 15:42:44 -0000 There is also draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04 which handles the case for DHCPv6 clients. That also requires no changes to clients--only the DHCPv6 Relay Agent. On Fri, Feb 01, 2013 at 02:56:03PM +0000, Rajiv Asati (rajiva) wrote: > Hi Maglione, > > Thanks for your review and a good question. > > draft-ietf-dhc-addr-registration introduces a new IPv6 Neighbor Discovery > option and a > new DHCPv6 option to propagate the address registration information > from the hosts to the network. It requires the changes on the host. > > > > draft-asati-dhc-ipv6-autoconfig-address-tracking, on the other hand, > requires no changes to IPv6 Neighbor Discovery and no changes to the > hosts. It introduces changes in DHCPv6 specific to the last hop router and > the DHCP server, thereby keeping the changes within the network (and DHCP > server). > > > Cheers, > Rajiv > > -----Original Message----- > From: Maglione Roberta > Date: Friday, February 1, 2013 3:26 AM > To: Rajiv Asati > Cc: "ipv6@ietf.org" , Philipp Kern , > Brian Hamacher > Subject: RE: MAC Address Tracking via DHCP6 > > >Hello Rajiv, > > is there any relation between your draft and > >draft-ietf-dhc-addr-registration-00? > > > >Thanks > >Regards, > >Roberta > > > > > >-----Original Message----- > >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > >Rajiv Asati (rajiva) > >Sent: Thursday, January 31, 2013 6:27 PM > >To: Philipp Kern; Brian Hamacher > >Cc: ipv6@ietf.org > >Subject: Re: MAC Address Tracking via DHCP6 > > > > > >There is a better way out to track the IPv6 addresses used by the hosts > >(via SLAAC or static) - > > > >http://tools.ietf.org/html/draft-asati-dhc-ipv6-autoconfig-address-trackin > >g > > > >Cheers, > >Rajiv > > > >-----Original Message----- > >From: Philipp Kern > >Organization: The Debian Project (http://www.debian.org) > >Date: Wednesday, December 12, 2012 10:37 AM > >To: Brian Hamacher > >Cc: "ipv6@ietf.org" > >Subject: Re: MAC Address Tracking > > > >>On Tue, Dec 11, 2012 at 04:04:14PM -0600, Brian Hamacher wrote: > >>> I am looking for a good way to track my users MAC Addresses. I have a > >>> test DHCPv6 server up and running ISC 4.1.1-P1. When I look through my > >>> DHCP logs as well as my leases file I do not see the client MAC Address > >>> anywhere. Do I need to enable an option to allow this to be logged? I > >>> am looking to figure out how I can track what user had what IP Address > >>> at any given time. The MAC Address is traditionally how I have done > >>> this. > >> > >>One way would be to poll your routers' ND tables (like fetching ARP > >>tables > >>in IPv4). As soon as you use relaying you most certainly won't get a > >>useable MAC address from your client, even though it might be possible in > >>the same network segment. (The MAC address is not copied from the wire > >>into the new relayed packet sent by the router to your server.) > >> > >>DHCPv6 uses the so-called client identifier extensively and not the MAC > >>address anymore. So you cannot do any static assignment based on MAC > >>addresses. > >> > >>Kind regards > >>Philipp Kern From rajiva@cisco.com Fri Feb 1 07:47:53 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB7511E8097; Fri, 1 Feb 2013 07:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.991 X-Spam-Level: X-Spam-Status: No, score=-8.991 tagged_above=-999 required=5 tests=[AWL=1.608, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSTdqPs8qdfK; Fri, 1 Feb 2013 07:47:53 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id F20C021E8039; Fri, 1 Feb 2013 07:47:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4138; q=dns/txt; s=iport; t=1359733673; x=1360943273; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=EzLj6QlsJMMLLkKvRXv8VuknxZopegpCA4AbyBF41gk=; b=cokzmuY+stk0iCW/AsNkm3ColW6bqoJ72R391wOBo3oFm8ews9O4CKw0 d242ZAZhPEfZGTQk2h6YnMV4JLgbwq67XIzCyjEsCqmusyPX+wmlff08t /h2eZQzmGcR+9dtBAjeVGfmYprJq9eHidsTLdkEg1peaYbGjVq7pbqE9S 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAIriC1GtJXG8/2dsb2JhbABFDr8fFnOCHgEBAQQ6OAcMBgEIDgMDAQEBAQoUCTkUCQgCBA4FCIgJDMMZjQuDYmEDlzSPM4I+PoIk X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="scan'208";a="168798546" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 01 Feb 2013 15:47:49 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r11FlnYI025644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Feb 2013 15:47:49 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Fri, 1 Feb 2013 09:47:49 -0600 From: "Rajiv Asati (rajiva)" To: Chuck Anderson Thread-Topic: [dhcwg] MAC Address Tracking via DHCP6 Thread-Index: AQHN/9giM3WALPSOxEqXmVcvCQGGwZhkq+IggAB9qoCAAGDQAP//raMA Date: Fri, 1 Feb 2013 15:47:48 +0000 Message-ID: In-Reply-To: <20130201154226.GJ22295@angus.ind.WPI.EDU> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.86.115.198] Content-Type: text/plain; charset="us-ascii" Content-ID: <87FC71402168074E86FBB05FBB6F5B59@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Brian Hamacher , Philipp Kern , "ipv6@ietf.org" Subject: Re: [dhcwg] MAC Address Tracking via DHCP6 X-BeenThere: dhcwg@ietf.org 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, 01 Feb 2013 15:47:53 -0000 Hi Chuck, Yah, but draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt is for DHCPv6 clients, as you rightly pointed out, and not for SLAAC/static hosts. Cheers, Rajiv -----Original Message----- From: Chuck Anderson Date: Friday, February 1, 2013 10:42 AM To: Rajiv Asati Cc: Maglione Roberta , "dhcwg@ietf.org" , Brian Hamacher , "ipv6@ietf.org" , Philipp Kern Subject: Re: [dhcwg] MAC Address Tracking via DHCP6 >There is also draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04 >which handles the case for DHCPv6 clients. That also requires no >changes to clients--only the DHCPv6 Relay Agent. > >On Fri, Feb 01, 2013 at 02:56:03PM +0000, Rajiv Asati (rajiva) wrote: >> Hi Maglione,=20 >>=20 >> Thanks for your review and a good question. >>=20 >> draft-ietf-dhc-addr-registration introduces a new IPv6 Neighbor >>Discovery >> option and a >> new DHCPv6 option to propagate the address registration information >> from the hosts to the network. It requires the changes on the host. >>=20 >>=20 >>=20 >> draft-asati-dhc-ipv6-autoconfig-address-tracking, on the other hand, >> requires no changes to IPv6 Neighbor Discovery and no changes to the >> hosts. It introduces changes in DHCPv6 specific to the last hop router >>and >> the DHCP server, thereby keeping the changes within the network (and >>DHCP >> server). >>=20 >>=20 >> Cheers, >> Rajiv >>=20 >> -----Original Message----- >> From: Maglione Roberta >> Date: Friday, February 1, 2013 3:26 AM >> To: Rajiv Asati >> Cc: "ipv6@ietf.org" , Philipp Kern , >> Brian Hamacher >> Subject: RE: MAC Address Tracking via DHCP6 >>=20 >> >Hello Rajiv, >> > is there any relation between your draft and >> >draft-ietf-dhc-addr-registration-00? >> > >> >Thanks >> >Regards, >> >Roberta >> > >> > >> >-----Original Message----- >> >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of >> >Rajiv Asati (rajiva) >> >Sent: Thursday, January 31, 2013 6:27 PM >> >To: Philipp Kern; Brian Hamacher >> >Cc: ipv6@ietf.org >> >Subject: Re: MAC Address Tracking via DHCP6 >> > >> > >> >There is a better way out to track the IPv6 addresses used by the hosts >> >(via SLAAC or static) - >> > >>=20 >>>http://tools.ietf.org/html/draft-asati-dhc-ipv6-autoconfig-address-track >>>in >> >g >> > >> >Cheers, >> >Rajiv >> > >> >-----Original Message----- >> >From: Philipp Kern >> >Organization: The Debian Project (http://www.debian.org) >> >Date: Wednesday, December 12, 2012 10:37 AM >> >To: Brian Hamacher >> >Cc: "ipv6@ietf.org" >> >Subject: Re: MAC Address Tracking >> > >> >>On Tue, Dec 11, 2012 at 04:04:14PM -0600, Brian Hamacher wrote: >> >>> I am looking for a good way to track my users MAC Addresses. I >>have a >> >>> test DHCPv6 server up and running ISC 4.1.1-P1. When I look >>through my >> >>> DHCP logs as well as my leases file I do not see the client MAC >>Address >> >>> anywhere. Do I need to enable an option to allow this to be >>logged? I >> >>> am looking to figure out how I can track what user had what IP >>Address >> >>> at any given time. The MAC Address is traditionally how I have done >> >>> this. >> >> >> >>One way would be to poll your routers' ND tables (like fetching ARP >> >>tables >> >>in IPv4). As soon as you use relaying you most certainly won't get a >> >>useable MAC address from your client, even though it might be >>possible in >> >>the same network segment. (The MAC address is not copied from the wire >> >>into the new relayed packet sent by the router to your server.) >> >> >> >>DHCPv6 uses the so-called client identifier extensively and not the >>MAC >> >>address anymore. So you cannot do any static assignment based on MAC >> >>addresses. >> >> >> >>Kind regards >> >>Philipp Kern From Ted.Lemon@nominum.com Fri Feb 1 07:49:15 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CD71F0D05; Fri, 1 Feb 2013 07:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.511 X-Spam-Level: X-Spam-Status: No, score=-106.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPz+jw41-kpM; Fri, 1 Feb 2013 07:49:08 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id CC7801F0CF8; Fri, 1 Feb 2013 07:49:03 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUQvj74WmNcpxHh+Vi/qCBUvU7DP0yCQf@postini.com; Fri, 01 Feb 2013 07:49:03 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6D715128008; Fri, 1 Feb 2013 07:49:03 -0800 (PST) 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 646CD190043; Fri, 1 Feb 2013 07:49:03 -0800 (PST) (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.0318.004; Fri, 1 Feb 2013 07:49:03 -0800 From: Ted Lemon To: Chuck Anderson Thread-Topic: [dhcwg] MAC Address Tracking via DHCP6 Thread-Index: AQHN/9giM3WALPSOxEqXmVcvCQGGwZhkq+IggAB9qoCAAIJYAIAAAdgA Date: Fri, 1 Feb 2013 15:49:03 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747479218@mbx-01.win.nominum.com> References: <282BBE8A501E1F4DA9C775F964BB21FE519D1A74F3@GRFMBX704BA020.griffon.local> <20130201154226.GJ22295@angus.ind.WPI.EDU> In-Reply-To: <20130201154226.GJ22295@angus.ind.WPI.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: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Brian Hamacher , "ipv6@ietf.org" , Philipp Kern , "Rajiv Asati \(rajiva\)" Subject: Re: [dhcwg] MAC Address Tracking via DHCP6 X-BeenThere: dhcwg@ietf.org 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, 01 Feb 2013 15:49:15 -0000 On Feb 1, 2013, at 10:42 AM, Chuck Anderson wrote: > There is also draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04 > which handles the case for DHCPv6 clients. That also requires no > changes to clients--only the DHCPv6 Relay Agent. This document doesn't apply to SLAAC or CGA addresses, though=97just statef= ul addresses acquired through DHCPv6. Admittedly, we could also snoop DHC= PINFORM traffic, but there's no guarantee that all devices on the network w= ill do a DHCPINFORM, even if the O bit is set. From tomasz.mrugalski@gmail.com Fri Feb 1 07:54:39 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E281F0D05 for ; Fri, 1 Feb 2013 07:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1pMVLZpbdfN for ; Fri, 1 Feb 2013 07:54:38 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 451D21F0CF7 for ; Fri, 1 Feb 2013 07:54:38 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id ez12so739804wid.11 for ; Fri, 01 Feb 2013 07:54:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=hPtlflLYbt67dQErcavfhylDxbG0aHVDKhTQ1FwsjpY=; b=iABMFMxcWXIUAf43Q99TEcNjFpfWxfO20EIxqPc+XeROcJkBa9Tqn7UvCXjg36Lvqo jL9avyP9U4piO5Pzs4h32Pjyi9Tt3tLaZ1TrWCvqOYvgFE3Hl5xNSvvxcTJ6Y7Qbb9PF lHzLRP2BIP9oG/9DcfIKFwRv9nYiGxkWfKRAxjk60DsXMLcjUQrLbPRfNxD0SMF0uEI6 QjF8RGElpoRC15E3YdOIySstGJHWdrl52Lcb+jUao1ddCk3duuzKdPvIhv+M3sXzG99W hE8IcPrWiVyFltUblpVP0mt/DNcIqSavItLm8xE8wCDX7f8wncqV+mvcbepXsXpvtnr+ 9o+A== X-Received: by 10.194.57.231 with SMTP id l7mr3560103wjq.9.1359734077335; Fri, 01 Feb 2013 07:54:37 -0800 (PST) Received: from ?IPv6:2001:470:6061:1:88c4:35da:ce2c:16ef? ([2001:470:6061:1:88c4:35da:ce2c:16ef]) by mx.google.com with ESMTPS id ec3sm4122135wib.1.2013.02.01.07.54.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Feb 2013 07:54:36 -0800 (PST) Message-ID: <510BE537.6050302@gmail.com> Date: Fri, 01 Feb 2013 16:54:31 +0100 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: dhcwg@ietf.org References: <282BBE8A501E1F4DA9C775F964BB21FE519D1A74F3@GRFMBX704BA020.griffon.local> <20130201154226.GJ22295@angus.ind.WPI.EDU> <8D23D4052ABE7A4490E77B1A012B630747479218@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747479218@mbx-01.win.nominum.com> X-TagToolbar-Keys: D20130201165431815 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] MAC Address Tracking via DHCP6 X-BeenThere: dhcwg@ietf.org 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, 01 Feb 2013 15:54:39 -0000 On 01.02.2013 16:49, Ted Lemon wrote: > On Feb 1, 2013, at 10:42 AM, Chuck Anderson wrote: >> There is also draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04 >> which handles the case for DHCPv6 clients. That also requires no >> changes to clients--only the DHCPv6 Relay Agent. > > This document doesn't apply to SLAAC or CGA addresses, though—just > stateful addresses acquired through DHCPv6. Admittedly, we could > also snoop DHCPINFORM traffic, but there's no guarantee that all > devices on the network will do a DHCPINFORM, even if the O bit is > set. That's INFORMATION-REQUEST, right? Or do we talk here about some not obvious matching strategy between v4 and v6? And I think there's no O bit for v4... Tomek From rajiva@cisco.com Fri Feb 1 07:57:40 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E533321F8D29; Fri, 1 Feb 2013 07:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2KEtOYRzvnh; Fri, 1 Feb 2013 07:57:40 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 25DB321F8461; Fri, 1 Feb 2013 07:57:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=946; q=dns/txt; s=iport; t=1359734260; x=1360943860; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=W8VyQmLR2o5IGgC+IXxgS58wZ0KrP3o85PUeaBJ+kCI=; b=go0B9QILDm52YNh5wQaQTAOOO0Mba1UdSQ2dp2R91eQEAQ2W2IIx+8m+ 3CagF0ycXxBJJUnri6F0G4l7mOQ6Rg/W6q0WNM5VnwdAtQvN6v4fnXUFj mrqP0j5ywAs2imX752LQIo25xsi0QEU+Jygv16OjVU1IXcL8wfw0pJENU A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFALfkC1GtJV2b/2dsb2JhbABFDoVzuSsWc4IeAQEBBHkMBgEIEQMBAgEKVh0IAgQBDQUIiAnDGpBtYQOmZ4I+PoIk X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="scan'208";a="168804226" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 01 Feb 2013 15:57:39 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r11FvdSr003141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Feb 2013 15:57:39 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Fri, 1 Feb 2013 09:57:39 -0600 From: "Rajiv Asati (rajiva)" To: Ted Lemon , Chuck Anderson Thread-Topic: [dhcwg] MAC Address Tracking via DHCP6 Thread-Index: AQHN/9giM3WALPSOxEqXmVcvCQGGwZhkq+IggAB9qoCAAGDQAIAAAdqA//+ujIA= Date: Fri, 1 Feb 2013 15:57:38 +0000 Message-ID: In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747479218@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.86.115.198] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Brian Hamacher , "ipv6@ietf.org" , Philipp Kern Subject: Re: [dhcwg] MAC Address Tracking via DHCP6 X-BeenThere: dhcwg@ietf.org 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, 01 Feb 2013 15:57:41 -0000 I agree, Ted.=20 -----Original Message----- From: Ted Lemon Date: Friday, February 1, 2013 10:49 AM To: Chuck Anderson Cc: Rajiv Asati , "dhcwg@ietf.org" , Brian Hamacher , Philipp Kern , "ipv6@ietf.org" Subject: Re: [dhcwg] MAC Address Tracking via DHCP6 >On Feb 1, 2013, at 10:42 AM, Chuck Anderson wrote: >> There is also draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04 >> which handles the case for DHCPv6 clients. That also requires no >> changes to clients--only the DHCPv6 Relay Agent. > >This document doesn't apply to SLAAC or CGA addresses, though=8Bjust >stateful addresses acquired through DHCPv6. Admittedly, we could also >snoop DHCPINFORM traffic, but there's no guarantee that all devices on >the network will do a DHCPINFORM, even if the O bit is set. > From Ted.Lemon@nominum.com Fri Feb 1 08:19:05 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A913B21E8044 for ; Fri, 1 Feb 2013 08:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.517 X-Spam-Level: X-Spam-Status: No, score=-106.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8vEqYLJh6-w for ; Fri, 1 Feb 2013 08:19:04 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9A05A21E8039 for ; Fri, 1 Feb 2013 08:19:04 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUQvq+JsnoW6MfTfE2tG6tOoe3eGrKVMT@postini.com; Fri, 01 Feb 2013 08:19:04 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 419D41B8364 for ; Fri, 1 Feb 2013 08:19:04 -0800 (PST) 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 35E7D190043; Fri, 1 Feb 2013 08:19:04 -0800 (PST) (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.0318.004; Fri, 1 Feb 2013 08:18:59 -0800 From: Ted Lemon To: Tomek Mrugalski Thread-Topic: [dhcwg] MAC Address Tracking via DHCP6 Thread-Index: AQHN/9giM3WALPSOxEqXmVcvCQGGwZhkq+IggAB9qoCAAIJYAIAAAdgAgAABiICAAAbVAA== Date: Fri, 1 Feb 2013 16:18:59 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474793AD@mbx-01.win.nominum.com> References: <282BBE8A501E1F4DA9C775F964BB21FE519D1A74F3@GRFMBX704BA020.griffon.local> <20130201154226.GJ22295@angus.ind.WPI.EDU> <8D23D4052ABE7A4490E77B1A012B630747479218@mbx-01.win.nominum.com> <510BE537.6050302@gmail.com> In-Reply-To: <510BE537.6050302@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] MAC Address Tracking via DHCP6 X-BeenThere: dhcwg@ietf.org 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, 01 Feb 2013 16:19:05 -0000 On Feb 1, 2013, at 10:54 AM, Tomek Mrugalski w= rote: > That's INFORMATION-REQUEST, right? Or do we talk here about some not > obvious matching strategy between v4 and v6? And I think there's no O > bit for v4... You can just start calling me gramps and get it over with, Tomek. :) Yes, you are quite correct=97I meant Information Request, not DHCPINFORM. From volz@cisco.com Fri Feb 1 08:20:06 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF8C21E8090 for ; Fri, 1 Feb 2013 08:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8LedoN-WjWO for ; Fri, 1 Feb 2013 08:20:05 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1205F21E8039 for ; Fri, 1 Feb 2013 08:20:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=990; q=dns/txt; s=iport; t=1359735605; x=1360945205; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=z2S4aGufOrz9Gi1Wr1HUaZwCfiSgLLn9VFXNMPyl2gc=; b=CdFcyHGdVIoB3CTfvUaCZC6WJstkTTXbuLnV2iBzBU1hRDLDB0DP5gjd yyI4HQGRcCdf5k7XWlofxVAK/G4/cGXX8FSR1/ospysq7ntdWc4OHntZf TnFlcvUwaVtUxlB8vcW8i2b/caMTGzo0ELVTTA3+Md0dxP+TtKLVpGqlq 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAEHqC1GtJV2b/2dsb2JhbABFhgG5KxZzgh4BAQEEAQEBGh00FwQCAQgRBAEBCxQJBycLFAkIAgQBEgiICQzDDASQbWEDpmeCfIIk X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="scan'208";a="171792164" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 01 Feb 2013 16:20:04 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r11GK4jq028466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Feb 2013 16:20:04 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.79]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Fri, 1 Feb 2013 10:20:04 -0600 From: "Bernie Volz (volz)" To: Ted Lemon , " WG" Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-load-balancing-00 Thread-Index: AQHOAC9e6WOKq1UT9UyI5dVQpbv8HphlL5Zg Date: Fri, 1 Feb 2013 16:20:03 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1844B1F8@xmb-rcd-x04.cisco.com> References: <8D23D4052ABE7A4490E77B1A012B6307474782A7@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474782A7@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-load-balancing-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, 01 Feb 2013 16:20:06 -0000 +1 in favor. -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Thursday, January 31, 2013 10:51 PM To: WG Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-load-balancing-00 This document got significant attention during the call for adoption. The= author feels it is ready to publish and have asked for a last call. The = document describes a load balancing algorithm for DHCPv6, similar to the on= e described in RFC3074 for DHCPv4. Please review the document if you haven't already. If you are in favor of= publishing the document, please say so on the mailing list. If you oppos= e publication of the document, please also say so. If you have comments, = please raise them on the mailing list. We will evaluate consensus on February 14. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Fri Feb 1 08:33:02 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD6521F8ECD for ; Fri, 1 Feb 2013 08:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3loyZ0COZ-7R for ; Fri, 1 Feb 2013 08:33:01 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id F405821F8ECC for ; Fri, 1 Feb 2013 08:33:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6775; q=dns/txt; s=iport; t=1359736381; x=1360945981; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2lNGdgLWLr1e37IXseJJT8L8zw11NxGocnkL9wgU8Qg=; b=DRQ8xO6GF4p2LgLR5sIPBGuBRXIhlztWMarZNRcrh1nFSMh/Wjij9ydN lebjt1hirEjx1ICiyWfmSHWXvs2EQRSujVwgqDeCXk4liuAKN89/4ULdW U2M66QpsWS8M4RXarj4h2jvJP+WKHbVbyN50RKEb4Odb2u2mBxI9nicGM o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAO7sC1GtJV2Z/2dsb2JhbABCA78tFnOCHgEBAQQBAQFrCwwEAgEIEQQBAQEKChMHIQYLFAkHAQIBAwENBQgTh2QDDwy5Mg2JUgSMGXcRBgpvgk1hA4gwijOBXY0VhRKCLFCBZz0 X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="scan'208";a="171800163" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 01 Feb 2013 16:33:00 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r11GX0jG002255 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Feb 2013 16:33:00 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.79]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Fri, 1 Feb 2013 10:33:00 -0600 From: "Bernie Volz (volz)" To: Dmitry Anipko , Bud Millwood , Sten Carlsen Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt Thread-Index: AQHN2aLtf97Q/V2yEUWdCx2wJ5mS4phWkuiAgAPtq4CAAAO7AIAEG3nDgANu8ACAAHd7gIAADdqAgABaxPCAAA4bAIAAAv0AgACPRYCAABelAIAAAoeAgAAf1ACAAFAk8IABY85g Date: Fri, 1 Feb 2013 16:32:59 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1844B249@xmb-rcd-x04.cisco.com> References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> <8D23D4052ABE7A4490E77B1A012B63074747458F@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474754C3@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630747475B92@mbx-01.win.nominum.com> <510A6327.6050506@s-carlsen.dk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.250] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Andre Kostur , Ted Lemon Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-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, 01 Feb 2013 16:33:02 -0000 Good catch about INF_MAX_RT ... it should be the same as SOL_MAX_RT (by def= ault). Also, regarding the timeout and "receive" issue ... while waiting an hour f= or an Advertise (or Reply if Rapid-Commit is enabled) is unlikely to yield = anything different than waiting a "reasonable" short time (a few minutes). = There may be cases were a packet is held up at several places during a rout= ing issue or while ND occurs, but this would be unlike to be very long. I think how long the client leaves the "receive" active is more of an imple= mentation issue. I would think it broken to not wait at least about a minut= e (probably this should be tied to the default hop limit (3x) -- not for th= e client's link-local packet but for the relay/server and server and server= /relay/client path and some small number of seconds for server processing l= atency) . But beyond that, it likely doesn't matter. If the default hop lim= it is still 64, that argues for a value from 128 - 196 seconds at most. For clients where leaving the receive (and socket?) active has negative imp= lications, they may want to shut it down when waiting long for the next ret= ransmission. The important detail here is that the retransmissions are reduced. It is le= ss critical how long the client waits for packets between retransmissions a= fter some reasonable interval. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of D= mitry Anipko Sent: Thursday, January 31, 2013 2:23 PM To: Bud Millwood; Sten Carlsen Cc: dhcwg@ietf.org; Andre Kostur; Ted Lemon Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.t= xt To Bud's question: I meant the type of energy cost Andre & Sten referred to= . From my observations, network adapters which require significantly more e= nergy when they listen, are not uncommon. So if there is a "low hanging fruit", which is to simply add one phrase to = the solmaxrt-update that in reality doesn't require behavior change of any = servers today, but allows some client devices to save energy, why not take = it. Are there any objections? Along the same lines, I'd suggest changing default for INF_MAX_RT similarly= to SOL_MAX_RT (or at least say the host MAY choose to do so), with the sam= e rationale - DHCP server is not replying after several frequent retransmis= sions, so what's the point of trying as frequently.=20 To Ted's point, I think a larger overhaul of DHCP to make it more power fri= endly is an interesting idea to explore, though it will probably take notic= eably more time and ignite passionate debates (which are good, but again, t= ake more time to reach consensus :)). -----Original Message----- From: budmillwood@gmail.com [mailto:budmillwood@gmail.com] On Behalf Of Bud= Millwood Sent: Thursday, January 31, 2013 6:21 AM To: Sten Carlsen Cc: Andre Kostur; dhcwg@ietf.org; Dmitry Anipko; Ted Lemon Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.t= xt Sten, thanks for that real-world example, I've learned something. - Bud On Thu, Jan 31, 2013 at 1:27 PM, Sten Carlsen wrote: > > On 31/01/13 13:18, Andre Kostur wrote: > > A second consideration is whether the energy-constrained device needs=20 > to keep a radio alive in order to listen for the incoming UDP? > > Usually there will be a strict timing so the power for the radio is=20 > minimized by only listening at specific times. The master example is=20 > GSM that can sleep for 2.12 seconds and then listen for 300=B5s. Other=20 > energy restricted devices must be designed likewise or burn far too much = energy. > > Generally from this perspective fixed/predictable windows makes sense,=20 > synchronize events and save more energy. > > > On Thu, Jan 31, 2013 at 2:53 AM, Bud Millwood=20 > > wrote: > > On Thu, Jan 31, 2013 at 3:20 AM, Andre Kostur wro= te: > > Not directly related to this draft (as this is a consideration after=20 > the device obtains some addresses), but if one of these=20 > restricted-power devices wished to be able to do Reconfigure, how=20 > would that work? > > For that matter, what about any other scenario where we could adjust=20 > the time spent using a socket in order to reduce energy? > > My question for Dmitry is: if you're not waiting on a socket, aren't=20 > you waiting on something? And is it actually likely that it costs more=20 > energy (CPU cycles) to wait on an unconnected socket than any other=20 > wait mechanism? > > I just want to make sure we don't go off solving a problem that=20 > doesn't actually exist. My understanding is that for long-term TCP=20 > socket use on a mobile device, the correct way to do it is to adjust=20 > the socket properties to minimize keepalive traffic. I believe that=20 > Google provides Push Notification for Android using TCP, with the=20 > socket settings tweaked to use almost no battery at all. And that's a=20 > connected socket. > > For UDP, I can't see how a wait on the socket would use any extra CPU=20 > cycles at all. But if you have some data, or even theoretical=20 > references to such a problem, I'd be interested in reading about it. > > - Bud > > On Wed, Jan 30, 2013 at 6:10 PM, Ted Lemon wrote: > > On Jan 30, 2013, at 8:24 PM, Dmitry Anipko=20 > > wrote: > > So, if practically all servers reply with responses (if they reply at > all) within seconds/minutes (e.g. current max RT fixed in the original > 3315 - 120s + random deviation), and given the client will eventually=20 > retry anyway, I'm trying to understand whether there is indeed a=20 > strong reason for a client to wait for an hour. > > I suspected this was the issue you had in mind. I think it would make > sense to add something to the draft that addresses this issue. > > > > -- > Andre Kostur > Distinguished Software Architect & Engineer > P: 604-678-2864 > E: akostur@incognito.com > Toll-Free: 1-800-877-1856 > > > F: 604-678-2864 > VoIP: sip:864@sip.incognito.com > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > > > -- > Best regards > > Sten Carlsen > > No improvements come from shouting: > "MALE BOVINE MANURE!!!" > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From tjc@ecs.soton.ac.uk Fri Feb 1 08:51:10 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510C621E808F; Fri, 1 Feb 2013 08:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMwZu2fhc8xx; Fri, 1 Feb 2013 08:51:09 -0800 (PST) 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 5EF9E21E8049; Fri, 1 Feb 2013 08:51:08 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r11Gp3ac021892; Fri, 1 Feb 2013 16:51:03 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r11Gp3ac021892 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1359737464; bh=kD9BO7Do7eydvlfYD04jx1hpBfo=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=s0ucs6hgnx4nLthR6+mtUclT9uq8cumftJazkHK4FEAP2370n7PW/HOAzwjpSotDs Mvv92YEp4bF+vFRYBlGdxU62wWXR9+TjmWjiW443X6p6QMVedGkikClBEHdcjBtDmb mvFbSAkB/LSqovTJfP1KrReK3y2YU+ll/94Qexs0= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id p10Gp30430611135OE ret-id none; Fri, 01 Feb 2013 16:51:03 +0000 Received: from ip-162-143.eduroam.soton.ac.uk (ip-162-143.eduroam.soton.ac.uk [152.78.162.143]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r11Gox9L032635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Feb 2013 16:51:01 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: Date: Fri, 1 Feb 2013 16:50:52 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: "ipv6@ietf.org List" , dhcwg@ietf.org X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p10Gp3043061113500; tid=p10Gp30430611135OE; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r11Gp3ac021892 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [dhcwg] MAC Address Tracking via DHCP6 X-BeenThere: dhcwg@ietf.org 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, 01 Feb 2013 16:51:10 -0000 On 1 Feb 2013, at 15:47, Rajiv Asati (rajiva) wrote: >=20 > Yah, but draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt is for = DHCPv6 > clients, as you rightly pointed out, and not for SLAAC/static hosts. You can also of course just use tools that harvest data from = network/switch/router devices, and build the info from that. There's a = number of open source options in that space, from bespoke tools for = address tracking through to full-on monitoring platforms. Then you don't = need changes in hosts or routers. Regardless, I hope draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt = progresses. Tim= From tjc@ecs.soton.ac.uk Fri Feb 1 08:59:49 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883B721E80A3 for ; Fri, 1 Feb 2013 08:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNYMNfq31YjQ for ; Fri, 1 Feb 2013 08:59:48 -0800 (PST) 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 EE01E21E8030 for ; Fri, 1 Feb 2013 08:59:44 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r11Gxd5t024571 for ; Fri, 1 Feb 2013 16:59:39 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r11Gxd5t024571 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1359737979; bh=zy3Sil6zn1w5JI6KgJBYco+Ih90=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=0cP+WSwK0wbx9yUH/ORyPwJ9gBIVY9pkA4p0gh6YubkvyrbMZm9WEsZJU3sw+9YO0 idsj7nHU6H1hbFzQSJ6WqZ3+rxebIRaOm1wEkCQuaiFiU6WNlosnwMbZrDOT08yASo ezrW/xr9IAZ/Rg8QaozGU+ltbQUrv/FM3tRyXxng= 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 p10Gxd0430611283QN ret-id none; Fri, 01 Feb 2013 16:59:39 +0000 Received: from ip-162-143.eduroam.soton.ac.uk (ip-162-143.eduroam.soton.ac.uk [152.78.162.143]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r11GxYAs004721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 1 Feb 2013 16:59:34 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130239E3D@GAALPA1MSGUSR9L.ITServices.sbc.com> Date: Fri, 1 Feb 2013 16:59:33 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474782DB@mbx-01.win.nominum.com> <5BBAAB88-1770-42F3-AF0A-28D6F904D847@employees.org> <2D09D61DDFA73D4C884805CC7865E61130239E3D@GAALPA1MSGUSR9L.ITServices.sbc.com> <258E6063-D563-4359-B668-2714E0F971D6@ecs.soton.ac.uk> To: dhc WG X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p10Gxd043061128300; tid=p10Gxd0430611283QN; 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: r11Gxd5t024571 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-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, 01 Feb 2013 16:59:49 -0000 I support publication. On 1 Feb 2013, at 14:16, "STARK, BARBARA H" wrote: > +1 > I would like to see this draft published. > Barbara >=20 >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On = Behalf >> Of Ole Troan >> Sent: Friday, February 01, 2013 4:35 AM >> To: Ted Lemon >> Cc: dhc WG >> Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >>=20 >> Ted, >>=20 >>>> Folks, the authors of this draft feel it's ready for a WGLC. = There's been >> substantial discussion and comment already. This is pretty = important IPv6 >> deployment work, so more eyes are better. Please review the draft = and >> indicate whether or not you feel it is ready to be published. We = have been >> getting very anemic responses to working group messages recently. = Your >> response matters, so please do respond. >>>>=20 >>>> We will evaluate consensus after January 28. Thanks! >>>=20 >>> Bud offered some comment. Aside from that, nobody said they wanted >> the draft to advance, and nobody objected. By default this means it = fails the >> last call and will not advance. Is that really the outcome that = people want, or >> was everybody just asleep when the WGLC went out? >>=20 >> if I didn't say so, my apologies. I'm biased as one of the authors = though. >>=20 >> the combination of RFC3315 and RFC3633 is broken. this document fixes = that. >> I really think we should advance this. >>=20 >> cheers, >> Ole >> _______________________________________________ >> 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 Dmitry.Anipko@microsoft.com Fri Feb 1 15:00:16 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727C921E8063 for ; Fri, 1 Feb 2013 15:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlvnLnWJfLyX for ; Fri, 1 Feb 2013 15:00:15 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.29]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCED21E8041 for ; Fri, 1 Feb 2013 15:00:15 -0800 (PST) Received: from BY2FFO11FD001.protection.gbl (10.1.15.201) by BY2FFO11HUB036.protection.gbl (10.1.14.179) with Microsoft SMTP Server (TLS) id 15.0.596.13; Fri, 1 Feb 2013 23:00:11 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD001.mail.protection.outlook.com (10.1.14.123) with Microsoft SMTP Server (TLS) id 15.0.609.9 via Frontend Transport; Fri, 1 Feb 2013 23:00:11 +0000 Received: from TK5EX14MBXC253.redmond.corp.microsoft.com ([169.254.3.95]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Fri, 1 Feb 2013 22:59:41 +0000 From: Dmitry Anipko To: "Bernie Volz (volz)" , Bud Millwood , Sten Carlsen Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt Thread-Index: AQHN2aLtf97Q/V2yEUWdCx2wJ5mS4phWkuiAgAPtq4CAAAO7AIAEG3nDgANu8ACAAHd7gIAADdqAgABaxPCAAA4bAIAAAv0AgACPRYCAABelAIAAAoeAgAAf1ACAAFAk8IABY85ggABtj4A= Date: Fri, 1 Feb 2013 22:59:40 +0000 Message-ID: References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> <8D23D4052ABE7A4490E77B1A012B63074747458F@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474754C3@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630747475B92@mbx-01.win.nominum.com> <510A6327.6050506@s-carlsen.dk> <489D13FBFA9B3E41812EA89F188F018E1844B249@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1844B249@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.22] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(24454001)(13464002)(189002)(479174001)(199002)(51704002)(52314002)(77982001)(47736001)(49866001)(4396001)(59766001)(50466001)(63696002)(79102001)(54356001)(56776001)(54316002)(53806001)(44976002)(76482001)(47446002)(74502001)(74662001)(51856001)(23756002)(20776003)(31966008)(50986001)(47776003)(16406001)(33656001)(5343635001)(46102001)(5343655001)(56816002)(47976001)(55846006); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB036; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0744CFB5E8 Cc: "dhcwg@ietf.org" , "rdroms@cisco.com" , Andre Kostur , Ted Lemon Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-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, 01 Feb 2013 23:00:16 -0000 Agree with everything you wrote. I think several minutes waiting would be f= ine, and I understand there may be good reasons for such waiting interval (= as opposed to hour). If there is a general agreement on these 2 adjustments (allowed waiting per= iod cap and INF_MAX_RT default), how do we move forward - Ralph, can these = be included in the next revision of the draft? Thank you. -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 Sent: Friday, February 01, 2013 8:33 AM To: Dmitry Anipko; Bud Millwood; Sten Carlsen Cc: dhcwg@ietf.org; Andre Kostur; Ted Lemon Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.t= xt Good catch about INF_MAX_RT ... it should be the same as SOL_MAX_RT (by def= ault). Also, regarding the timeout and "receive" issue ... while waiting an hour f= or an Advertise (or Reply if Rapid-Commit is enabled) is unlikely to yield = anything different than waiting a "reasonable" short time (a few minutes). = There may be cases were a packet is held up at several places during a rout= ing issue or while ND occurs, but this would be unlike to be very long. I think how long the client leaves the "receive" active is more of an imple= mentation issue. I would think it broken to not wait at least about a minut= e (probably this should be tied to the default hop limit (3x) -- not for th= e client's link-local packet but for the relay/server and server and server= /relay/client path and some small number of seconds for server processing l= atency) . But beyond that, it likely doesn't matter. If the default hop lim= it is still 64, that argues for a value from 128 - 196 seconds at most. For clients where leaving the receive (and socket?) active has negative imp= lications, they may want to shut it down when waiting long for the next ret= ransmission. The important detail here is that the retransmissions are reduced. It is le= ss critical how long the client waits for packets between retransmissions a= fter some reasonable interval. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of D= mitry Anipko Sent: Thursday, January 31, 2013 2:23 PM To: Bud Millwood; Sten Carlsen Cc: dhcwg@ietf.org; Andre Kostur; Ted Lemon Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.t= xt To Bud's question: I meant the type of energy cost Andre & Sten referred to= . From my observations, network adapters which require significantly more e= nergy when they listen, are not uncommon. So if there is a "low hanging fruit", which is to simply add one phrase to = the solmaxrt-update that in reality doesn't require behavior change of any = servers today, but allows some client devices to save energy, why not take = it. Are there any objections? Along the same lines, I'd suggest changing default for INF_MAX_RT similarly= to SOL_MAX_RT (or at least say the host MAY choose to do so), with the sam= e rationale - DHCP server is not replying after several frequent retransmis= sions, so what's the point of trying as frequently.=20 To Ted's point, I think a larger overhaul of DHCP to make it more power fri= endly is an interesting idea to explore, though it will probably take notic= eably more time and ignite passionate debates (which are good, but again, t= ake more time to reach consensus :)). -----Original Message----- From: budmillwood@gmail.com [mailto:budmillwood@gmail.com] On Behalf Of Bud= Millwood Sent: Thursday, January 31, 2013 6:21 AM To: Sten Carlsen Cc: Andre Kostur; dhcwg@ietf.org; Dmitry Anipko; Ted Lemon Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.t= xt Sten, thanks for that real-world example, I've learned something. - Bud On Thu, Jan 31, 2013 at 1:27 PM, Sten Carlsen wrote: > > On 31/01/13 13:18, Andre Kostur wrote: > > A second consideration is whether the energy-constrained device needs=20 > to keep a radio alive in order to listen for the incoming UDP? > > Usually there will be a strict timing so the power for the radio is=20 > minimized by only listening at specific times. The master example is=20 > GSM that can sleep for 2.12 seconds and then listen for 300=B5s. Other=20 > energy restricted devices must be designed likewise or burn far too much = energy. > > Generally from this perspective fixed/predictable windows makes sense,=20 > synchronize events and save more energy. > > > On Thu, Jan 31, 2013 at 2:53 AM, Bud Millwood=20 > > wrote: > > On Thu, Jan 31, 2013 at 3:20 AM, Andre Kostur wro= te: > > Not directly related to this draft (as this is a consideration after=20 > the device obtains some addresses), but if one of these=20 > restricted-power devices wished to be able to do Reconfigure, how=20 > would that work? > > For that matter, what about any other scenario where we could adjust=20 > the time spent using a socket in order to reduce energy? > > My question for Dmitry is: if you're not waiting on a socket, aren't=20 > you waiting on something? And is it actually likely that it costs more=20 > energy (CPU cycles) to wait on an unconnected socket than any other=20 > wait mechanism? > > I just want to make sure we don't go off solving a problem that=20 > doesn't actually exist. My understanding is that for long-term TCP=20 > socket use on a mobile device, the correct way to do it is to adjust=20 > the socket properties to minimize keepalive traffic. I believe that=20 > Google provides Push Notification for Android using TCP, with the=20 > socket settings tweaked to use almost no battery at all. And that's a=20 > connected socket. > > For UDP, I can't see how a wait on the socket would use any extra CPU=20 > cycles at all. But if you have some data, or even theoretical=20 > references to such a problem, I'd be interested in reading about it. > > - Bud > > On Wed, Jan 30, 2013 at 6:10 PM, Ted Lemon wrote: > > On Jan 30, 2013, at 8:24 PM, Dmitry Anipko=20 > > wrote: > > So, if practically all servers reply with responses (if they reply at > all) within seconds/minutes (e.g. current max RT fixed in the original > 3315 - 120s + random deviation), and given the client will eventually=20 > retry anyway, I'm trying to understand whether there is indeed a=20 > strong reason for a client to wait for an hour. > > I suspected this was the issue you had in mind. I think it would make > sense to add something to the draft that addresses this issue. > > > > -- > Andre Kostur > Distinguished Software Architect & Engineer > P: 604-678-2864 > E: akostur@incognito.com > Toll-Free: 1-800-877-1856 > > > F: 604-678-2864 > VoIP: sip:864@sip.incognito.com > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > > > -- > Best regards > > Sten Carlsen > > No improvements come from shouting: > "MALE BOVINE MANURE!!!" > > > _______________________________________________ > 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 stenc@s-carlsen.dk Fri Feb 1 17:05:06 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860D31F0D00 for ; Fri, 1 Feb 2013 17:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwHalCOiBYq1 for ; Fri, 1 Feb 2013 17:05:05 -0800 (PST) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id 502381F0CF8 for ; Fri, 1 Feb 2013 17:05:05 -0800 (PST) Received: from silver3airport.s-carlsen.dk (silver3AirPort.s-carlsen.dk [192.168.16.117]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 05620DAE6; Sat, 2 Feb 2013 02:04:57 +0100 (CET) Message-ID: <510C663A.60403@s-carlsen.dk> Date: Sat, 02 Feb 2013 02:04:58 +0100 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Bud Millwood References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> <8D23D4052ABE7A4490E77B1A012B63074747458F@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474754C3@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630747475B92@mbx-01.win.nominum.com> <510A6327.6050506@s-carlsen.dk> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: multipart/alternative; boundary="------------020505010006050800010403" Cc: "dhcwg@ietf.org" , Ted Lemon , Andre Kostur , Dmitry Anipko Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-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: Sat, 02 Feb 2013 01:05:06 -0000 This is a multi-part message in MIME format. --------------020505010006050800010403 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Bud, you're welcome. I have given this a bit more thought, in GSM (as an example) the window for beginning to listen for paging/traffic is about 600ns wide, so this must be handled by the base station buffering those messages until the next time it knows the device will listen for paging. That will also make it possible to collect other messages for the same transmission. Between pagings only the 32kHz clock is on, everything else including the main clock is shut down to conserve energy and must be turned on and fired up to look for pagings/receiving stuff, you don't do that if it can be avoided, way too costly in energy. Precision like a few hundred nanoseconds will never be possible in normal network equipment so don't try. Ensuring that there is slack in the timing to allow for the delay of a few seconds would be good though. On 31/01/13 15:21, Bud Millwood wrote: > Sten, thanks for that real-world example, I've learned something. > > - Bud > > On Thu, Jan 31, 2013 at 1:27 PM, Sten Carlsen wrote: >> On 31/01/13 13:18, Andre Kostur wrote: >> >> A second consideration is whether the energy-constrained device needs >> to keep a radio alive in order to listen for the incoming UDP? >> >> Usually there will be a strict timing so the power for the radio is >> minimized by only listening at specific times. The master example is GSM >> that can sleep for 2.12 seconds and then listen for 300µs. Other energy >> restricted devices must be designed likewise or burn far too much energy. >> >> Generally from this perspective fixed/predictable windows makes sense, >> synchronize events and save more energy. >> >> >> On Thu, Jan 31, 2013 at 2:53 AM, Bud Millwood >> wrote: >> >> On Thu, Jan 31, 2013 at 3:20 AM, Andre Kostur wrote: >> >> Not directly related to this draft (as this is a consideration after >> the device obtains some addresses), but if one of these >> restricted-power devices wished to be able to do Reconfigure, how >> would that work? >> >> For that matter, what about any other scenario where we could adjust >> the time spent using a socket in order to reduce energy? >> >> My question for Dmitry is: if you're not waiting on a socket, aren't >> you waiting on something? And is it actually likely that it costs more >> energy (CPU cycles) to wait on an unconnected socket than any other >> wait mechanism? >> >> I just want to make sure we don't go off solving a problem that >> doesn't actually exist. My understanding is that for long-term TCP >> socket use on a mobile device, the correct way to do it is to adjust >> the socket properties to minimize keepalive traffic. I believe that >> Google provides Push Notification for Android using TCP, with the >> socket settings tweaked to use almost no battery at all. And that's a >> connected socket. >> >> For UDP, I can't see how a wait on the socket would use any extra CPU >> cycles at all. But if you have some data, or even theoretical >> references to such a problem, I'd be interested in reading about it. >> >> - Bud >> >> On Wed, Jan 30, 2013 at 6:10 PM, Ted Lemon wrote: >> >> On Jan 30, 2013, at 8:24 PM, Dmitry Anipko >> wrote: >> >> So, if practically all servers reply with responses (if they reply at all) >> within seconds/minutes (e.g. current max RT fixed in the original 3315 - >> 120s + random deviation), and given the client will eventually retry anyway, >> I'm trying to understand whether there is indeed a strong reason for a >> client to wait for an hour. >> >> I suspected this was the issue you had in mind. I think it would make >> sense to add something to the draft that addresses this issue. >> >> >> >> -- >> Andre Kostur >> Distinguished Software Architect & Engineer >> P: 604-678-2864 >> E: akostur@incognito.com >> Toll-Free: 1-800-877-1856 >> >> >> F: 604-678-2864 >> VoIP: sip:864@sip.incognito.com >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> >> >> >> -- >> Best regards >> >> Sten Carlsen >> >> No improvements come from shouting: >> "MALE BOVINE MANURE!!!" >> >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------020505010006050800010403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bud, you're welcome.

I have given this a bit more thought, in GSM (as an example) the window for beginning to listen for paging/traffic is about 600ns wide, so this must be handled by the base station buffering those messages until the next time it knows the device will listen for paging. That will also make it possible to collect other messages for the same transmission. Between pagings only the 32kHz clock is on, everything else including the main clock is shut down to conserve energy and must be turned on and fired up to look for pagings/receiving stuff, you don't do that if it can be avoided, way too costly in energy.

Precision like a few hundred nanoseconds will never be possible in normal network equipment so don't try.

Ensuring that there is slack in the timing to allow for the delay of a few seconds would be good though.


On 31/01/13 15:21, Bud Millwood wrote:
Sten, thanks for that real-world example, I've learned something.

- Bud

On Thu, Jan 31, 2013 at 1:27 PM, Sten Carlsen <stenc@s-carlsen.dk> wrote:

On 31/01/13 13:18, Andre Kostur wrote:

A second consideration is whether the energy-constrained device needs
to keep a radio alive in order to listen for the incoming UDP?

Usually there will be a strict timing so the power for the radio is
minimized by only listening at specific times. The master example is GSM
that can sleep for 2.12 seconds and then listen for 300µs. Other energy
restricted devices must be designed likewise or burn far too much energy.

Generally from this perspective fixed/predictable windows makes sense,
synchronize events and save more energy.


On Thu, Jan 31, 2013 at 2:53 AM, Bud Millwood <budm@weird-solutions.com>
wrote:

On Thu, Jan 31, 2013 at 3:20 AM, Andre Kostur <akostur@incognito.com> wrote:

Not directly related to this draft (as this is a consideration after
the device obtains some addresses), but if one of these
restricted-power devices wished to be able to do Reconfigure, how
would that work?

For that matter, what about any other scenario where we could adjust
the time spent using a socket in order to reduce energy?

My question for Dmitry is: if you're not waiting on a socket, aren't
you waiting on something? And is it actually likely that it costs more
energy (CPU cycles) to wait on an unconnected socket than any other
wait mechanism?

I just want to make sure we don't go off solving a problem that
doesn't actually exist. My understanding is that for long-term TCP
socket use on a mobile device, the correct way to do it is to adjust
the socket properties to minimize keepalive traffic. I believe that
Google provides Push Notification for Android using TCP, with the
socket settings tweaked to use almost no battery at all. And that's a
connected socket.

For UDP, I can't see how a wait on the socket would use any extra CPU
cycles at all. But if you have some data, or even theoretical
references to such a problem, I'd be interested in reading about it.

- Bud

On Wed, Jan 30, 2013 at 6:10 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

On Jan 30, 2013, at 8:24 PM, Dmitry Anipko <Dmitry.Anipko@microsoft.com>
wrote:

So, if practically all servers reply with responses (if they reply at all)
within seconds/minutes (e.g. current max RT fixed in the original 3315 -
120s + random deviation), and given the client will eventually retry anyway,
I'm trying to understand whether there is indeed a strong reason for a
client to wait for an hour.

I suspected this was the issue you had in mind.   I think it would make
sense to add something to the draft that addresses this issue.



--
Andre Kostur
Distinguished Software Architect & Engineer
P: 604-678-2864
E: akostur@incognito.com
Toll-Free: 1-800-877-1856


F: 604-678-2864
VoIP: sip:864@sip.incognito.com
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg



--
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"


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



-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"
--------------020505010006050800010403-- From rdroms.ietf@gmail.com Fri Feb 1 18:07:48 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F0621E808B for ; Fri, 1 Feb 2013 18:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qxu2IWf0kY26 for ; Fri, 1 Feb 2013 18:07:48 -0800 (PST) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id 550D221E8089 for ; Fri, 1 Feb 2013 18:07:48 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id hg5so601830qab.6 for ; Fri, 01 Feb 2013 18:07:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=K+vNiFrh2k0+LmZMjsu85d7UjxMWYB+y0uO+t7wAd6k=; b=xvvPz0sDI0FR1IbLRoGJwgUI0wSRtsTrwFaTYnStRXsb1ivuWCzu/m/q6gQ26mglgr l+sP8uJrBAVegISwlwNSOPQ87oYHN9sFZNsGoHLtg3kp3ahwovm+RK0ecI+4qVxl94iQ xGiyvwRSsKeT2+heV1cwBZ28kVa2cSwNvq9y002/MaFteWIYFrQNyVAnvBaZx5k8q2uY XMzm8OhMO+kG+aA42ZX2NAHiosIo9yeJHvGZUq+eBsv0NiXH+v3atgRsOVybWFwInznL FsRQh4P3LusTKiOK3LI8BJW9UuaD8zi4ZE0raHFlwaKUkarnpxVDTU204Z2zhW7frvB+ ceVA== X-Received: by 10.224.96.17 with SMTP id f17mr3390608qan.67.1359770867623; Fri, 01 Feb 2013 18:07:47 -0800 (PST) Received: from rtp-rdroms-89113.cisco.com (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPS id dt10sm8823762qab.0.2013.02.01.18.07.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Feb 2013 18:07:46 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ralph Droms In-Reply-To: Date: Fri, 1 Feb 2013 21:07:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1FF595DD-C7F5-475D-93BB-EC7E64428EBD@gmail.com> References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> <8D23D4052ABE7A4490E77B1A012B63074747458F@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474754C3@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630747475B92@mbx-01.win.nominum.com> <510A6327.6050506@s-carlsen.dk> <489D13FBFA9B3E41812EA89F188F018E1844B249@xmb-rcd-x04.cisco.com> To: Dmitry Anipko X-Mailer: Apple Mail (2.1499) Cc: "Bernie Volz \(volz\)" , Bud Millwood , Lemon Ted , dhcwg@ietf.org, Andre Kostur Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-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: Sat, 02 Feb 2013 02:07:49 -0000 (resending to dhcwg mailing list) On Feb 1, 2013, at 5:59 PM 2/1/13, Dmitry Anipko = wrote: > Agree with everything you wrote. I think several minutes waiting would = be fine, and I understand there may be good reasons for such waiting = interval (as opposed to hour). >=20 > If there is a general agreement on these 2 adjustments (allowed = waiting period cap and INF_MAX_RT default), how do we move forward - = Ralph, can these be included in the next revision of the draft? >=20 > Thank you. Adding INF_MAX_RT makes sense. In my opinion, the right thing to say about waiting for a response is = something vague, to the effect of "A client is not expected to listen = for a response during the entire period between transmission of Solicit = or Information-Request messages." - Ralph From Dmitry.Anipko@microsoft.com Fri Feb 1 18:52:39 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE64B21F8D1F for ; Fri, 1 Feb 2013 18:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RGS6zceGHu5 for ; Fri, 1 Feb 2013 18:52:39 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.29]) by ietfa.amsl.com (Postfix) with ESMTP id 2586821F8D1E for ; Fri, 1 Feb 2013 18:52:38 -0800 (PST) Received: from BL2FFO11FD002.protection.gbl (10.173.161.201) by BL2FFO11HUB018.protection.gbl (10.173.160.110) with Microsoft SMTP Server (TLS) id 15.0.596.13; Sat, 2 Feb 2013 02:52:36 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD002.mail.protection.outlook.com (10.173.160.102) with Microsoft SMTP Server (TLS) id 15.0.609.9 via Frontend Transport; Sat, 2 Feb 2013 02:52:35 +0000 Received: from TK5EX14MBXC253.redmond.corp.microsoft.com ([169.254.3.95]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Sat, 2 Feb 2013 02:52:11 +0000 From: Dmitry Anipko To: Ralph Droms Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt Thread-Index: AQHN2aLtf97Q/V2yEUWdCx2wJ5mS4phWkuiAgAPtq4CAAAO7AIAEG3nDgANu8ACAAHd7gIAADdqAgABaxPCAAA4bAIAAAv0AgACPRYCAABelAIAAAoeAgAAf1ACAAFAk8IABY85ggABtj4CAADY2AIAADETQ Date: Sat, 2 Feb 2013 02:52:11 +0000 Message-ID: References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> <8D23D4052ABE7A4490E77B1A012B63074747458F@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474754C3@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630747475B92@mbx-01.win.nominum.com> <510A6327.6050506@s-carlsen.dk> <489D13FBFA9B3E41812EA89F188F018E1844B249@xmb-rcd-x04.cisco.com> <1FF595DD-C7F5-475D-93BB-EC7E64428EBD@gmail.com> In-Reply-To: <1FF595DD-C7F5-475D-93BB-EC7E64428EBD@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.22] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(199002)(479174001)(189002)(13464002)(51704002)(24454001)(44976002)(4396001)(46406002)(50986001)(74662001)(47736001)(49866001)(23726001)(54356001)(77982001)(59766001)(56776001)(47976001)(51856001)(33656001)(47446002)(50466001)(74502001)(16406001)(54316002)(53806001)(56816002)(46102001)(47776003)(79102001)(76482001)(5343635001)(20776003)(63696002)(55846006)(31966008); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB018; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07459438AA Cc: "Bernie Volz \(volz\)" , Bud Millwood , Lemon Ted , "dhcwg@ietf.org" , Andre Kostur Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-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: Sat, 02 Feb 2013 02:52:39 -0000 >> A client is not expected to listen for a response during the entire peri= od between transmission of Solicit or Information-Request messages Looks good to me.=20 Thanks. -----Original Message----- From: Ralph Droms [mailto:rdroms.ietf@gmail.com]=20 Sent: Friday, February 01, 2013 6:08 PM To: Dmitry Anipko Cc: Bernie Volz (volz); Bud Millwood; Sten Carlsen; dhcwg@ietf.org; Andre K= ostur; Lemon Ted Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.t= xt (resending to dhcwg mailing list) On Feb 1, 2013, at 5:59 PM 2/1/13, Dmitry Anipko wrote: > Agree with everything you wrote. I think several minutes waiting would be= fine, and I understand there may be good reasons for such waiting interval= (as opposed to hour). >=20 > If there is a general agreement on these 2 adjustments (allowed waiting p= eriod cap and INF_MAX_RT default), how do we move forward - Ralph, can thes= e be included in the next revision of the draft? >=20 > Thank you. Adding INF_MAX_RT makes sense. In my opinion, the right thing to say about waiting for a response is somet= hing vague, to the effect of "A client is not expected to listen for a resp= onse during the entire period between transmission of Solicit or Informatio= n-Request messages." - Ralph From volz@cisco.com Fri Feb 1 20:10:48 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04CF421F8B64 for ; Fri, 1 Feb 2013 20:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U+FZ3tekQ6v for ; Fri, 1 Feb 2013 20:10:47 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 128B621F8B63 for ; Fri, 1 Feb 2013 20:10:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1543; q=dns/txt; s=iport; t=1359778247; x=1360987847; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HSeQ7BfskN9YdHeNkB3N5PyKgRXNOjE2Dti9YZMrobc=; b=Rp6JU62bMC+IN5B1knaz+bvyH4Cbb0doFxdCytAkfw8yeg5PxVy5Sypc wQ2bC5L2Qd0Sw9LILtXY3nzBddm5c/Bt78FcNlcrmKuXMeVbclJeXuzYx Xg0HIe1/TBYNR1SBpE6Ti3GM2fPVmgo9WTuPhUbFqBnITWXRz9hQnRRLb I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJSQDFGtJXG//2dsb2JhbABFvzIWc4IeAQEBAwE6NAsMBAIBCBEEAQEBHQEJByERFAkIAgQOBYd/AwkGuH8NiVaMGYRUYQOUQIFXiz6FEoJ8 X-IronPort-AV: E=Sophos;i="4.84,589,1355097600"; d="scan'208";a="172104639" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 02 Feb 2013 04:10:46 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r124AkCY017813 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 2 Feb 2013 04:10:46 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.79]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Fri, 1 Feb 2013 22:10:46 -0600 From: "Bernie Volz (volz)" To: Dmitry Anipko Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt Thread-Index: AQHN2aLtf97Q/V2yEUWdCx2wJ5mS4phWkuiAgAPtq4CAAAO7AIAEG3nDgANu8ACAAHd7gIAADdqAgABaxPCAAA4bAIAAAv0AgACPRYCAABelAIAAAoeAgAAf1ACAAFAk8IABY85ggABtj4CAAJrLAIAADG6A//+xX5o= Date: Sat, 2 Feb 2013 04:10:46 +0000 Message-ID: <93B6C36C-3E9F-4D11-8C08-3BB482C4A470@cisco.com> References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> <8D23D4052ABE7A4490E77B1A012B63074747458F@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474754C3@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630747475B92@mbx-01.win.nominum.com> <510A6327.6050506@s-carlsen.dk> <489D13FBFA9B3E41812EA89F188F018E1844B249@xmb-rcd-x04.cisco.com> <1FF595DD-C7F5-475D-93BB-EC7E64428EBD@gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Bud Millwood , Lemon Ted , "dhcwg@ietf.org" , Andre Kostur , Ralph Droms Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-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: Sat, 02 Feb 2013 04:10:48 -0000 Fine by me too. - Bernie On Feb 1, 2013, at 9:52 PM, "Dmitry Anipko" w= rote: >>> A client is not expected to listen for a response during the entire per= iod between transmission of Solicit or Information-Request messages >=20 > Looks good to me.=20 >=20 > Thanks. >=20 > -----Original Message----- > From: Ralph Droms [mailto:rdroms.ietf@gmail.com]=20 > Sent: Friday, February 01, 2013 6:08 PM > To: Dmitry Anipko > Cc: Bernie Volz (volz); Bud Millwood; Sten Carlsen; dhcwg@ietf.org; Andre= Kostur; Lemon Ted > Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00= .txt >=20 > (resending to dhcwg mailing list) >=20 > On Feb 1, 2013, at 5:59 PM 2/1/13, Dmitry Anipko > wrote: >=20 >> Agree with everything you wrote. I think several minutes waiting would b= e fine, and I understand there may be good reasons for such waiting interva= l (as opposed to hour). >>=20 >> If there is a general agreement on these 2 adjustments (allowed waiting = period cap and INF_MAX_RT default), how do we move forward - Ralph, can the= se be included in the next revision of the draft? >>=20 >> Thank you. >=20 > Adding INF_MAX_RT makes sense. >=20 > In my opinion, the right thing to say about waiting for a response is som= ething vague, to the effect of "A client is not expected to listen for a re= sponse during the entire period between transmission of Solicit or Informat= ion-Request messages." >=20 > - Ralph >=20 From wwwrun@rfc-editor.org Sat Feb 2 04:28:04 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E66021F8ED3 for ; Sat, 2 Feb 2013 04:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.383 X-Spam-Level: X-Spam-Status: No, score=-102.383 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iy5Q0DCRkO0a for ; Sat, 2 Feb 2013 04:28:03 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 8147921F8ED1 for ; Sat, 2 Feb 2013 04:28:03 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 142E9B1E002; Sat, 2 Feb 2013 04:27:05 -0800 (PST) To: rdroms.ietf@gmail.com, brian@innovationslab.net, ted.lemon@nominum.com, john_brzozowski@cable.comcast.com From: RFC Errata System Message-Id: <20130202122705.142E9B1E002@rfc-editor.org> Date: Sat, 2 Feb 2013 04:27:05 -0800 (PST) Cc: dhcwg@ietf.org, lonvick.ietf@gmail.com, rfc-editor@rfc-editor.org Subject: [dhcwg] [Technical Errata Reported] RFC3118 (3474) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 12:28:04 -0000 The following errata report has been submitted for RFC3118, "Authentication for DHCP Messages". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3118&eid=3474 -------------------------------------- Type: Technical Reported by: Chris Lonvick Section: 2 Original Text ------------- If the RDM field contains 0x00, the replay detection field MUST be set to the value of a monotonically increasing counter. Using a counter value such as the current time of day (e.g., an NTP-format timestamp [4]) can reduce the danger of replay attacks. This method MUST be supported by all protocols. Corrected Text -------------- If the RDM field contains 0x00, the replay detection field MUST be set to the value of a strictly increasing counter. Using a counter value such as the time since the epoch (e.g., an NTP-format timestamp [4]) can reduce the danger of replay attacks. This method MUST be supported by all protocols. Notes ----- The term "monotonically increasing" does not actually mean what the authors and editors hope it means. :-) An example of a monotonically increasing sequence is: 1, 2, 2, 2, 2, 2, 2... Strictly following that definition in the current section 2 would allow replays of captured packets. Changing the term to "strictly increasing" requires that subsequent values are greater than previous values. This would mean that a captured packet replayed with the same Authentication Information value would not meet the criteria described in my proposed corrected text, and should consequently be detected as a replay attack by a recipient. The term monotonically increasing is also used at the end of Section 6 and should also be replaced with strictly increasing. Also, the use of the term "time of day" could be problematic. If the first packet were sent just before midnight, and the second sent just after midnight, then the value of the second would be much lower than the value of the first. To align with the NTP example, I'm suggesting a change in text to be something that is actually increasing. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3118 (draft-ietf-dhc-authentication-16) -------------------------------------- Title : Authentication for DHCP Messages Publication Date : June 2001 Author(s) : R. Droms, W. Arbaugh, Eds. Category : PROPOSED STANDARD Source : Dynamic Host Configuration Area : Internet Stream : IETF Verifying Party : IESG From Ted.Lemon@nominum.com Sat Feb 2 05:19:59 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433AB21F9059 for ; Sat, 2 Feb 2013 05:19:59 -0800 (PST) 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.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1sX-8KiPeWJ for ; Sat, 2 Feb 2013 05:19:58 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id B6BBB21F9056 for ; Sat, 2 Feb 2013 05:19:58 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUQ0Sfory2XVCKRuwCdyP2MO/g5TKAYLr@postini.com; Sat, 02 Feb 2013 05:19:58 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6492D10807B for ; Sat, 2 Feb 2013 05:19:58 -0800 (PST) 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 5CC4E190043 for ; Sat, 2 Feb 2013 05:19:58 -0800 (PST) (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.0318.004; Sat, 2 Feb 2013 05:19:58 -0800 From: Ted Lemon To: "dhcwg@ietf.org" Thread-Topic: [Technical Errata Reported] RFC3118 (3474) Thread-Index: AQHOAUC/ToF+Ryt4rUOvtZM+fkxiTJhnE5iA Date: Sat, 2 Feb 2013 13:19:57 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074747A6DA@mbx-01.win.nominum.com> References: <20130202122705.142E9B1E002@rfc-editor.org> In-Reply-To: <20130202122705.142E9B1E002@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] [Technical Errata Reported] RFC3118 (3474) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 13:19:59 -0000 On Feb 2, 2013, at 7:27 AM, RFC Errata System w= rote: > The term "monotonically increasing" does not actually mean what the autho= rs and editors hope it means. :-) An example of a monotonically increasin= g sequence is:=20 > 1, 2, 2, 2, 2, 2, 2... =20 This is a fairly serious error, which also appears in RFC3315. :( From d3e3e3@gmail.com Sat Feb 2 06:33:54 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F047F21F84BA for ; Sat, 2 Feb 2013 06:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.267 X-Spam-Level: X-Spam-Status: No, score=-103.267 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EI8f3sdyO4Nv for ; Sat, 2 Feb 2013 06:33:54 -0800 (PST) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2E721F86CC for ; Sat, 2 Feb 2013 06:33:54 -0800 (PST) Received: by mail-oa0-f47.google.com with SMTP id o17so3592050oag.20 for ; Sat, 02 Feb 2013 06:33:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=RSNh5/Zdw1R24ncWN05r3usqSRzIwP8T7Cnt3u7SqW4=; b=FCU0iTJzLO6G+yR3zBJMtpi7+jTyiV5dxr/zgZoQOdT9DbqLTmCslPQRckPJEDrcDh ncvAdaiP9iAydH6JdaQTqpxl5pdAYNniOwMuJdxvyJqC4CnvZUNvX3Zby7NkgBPCrh85 jK2ed87TGcHGOmqe8qVRGHw++wnjReLeSBnYDTrSDURjqj/b7CwyTBqNmnSAyAgiVOoT h4MemtX8zGT9gkoLctL19hBG2XtOH5tx2lpEFWziiEOApIJIvOiBSNmiMhSq1illhcLx 7TtVcz2tJKKc+VbnCv4ZV3NEqouZFB6XprkItTHzg7aFFDu0y+jrCoP/ocmXXt8PpMrl dKZQ== X-Received: by 10.60.32.147 with SMTP id j19mr12588864oei.68.1359815633704; Sat, 02 Feb 2013 06:33:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.98.168 with HTTP; Sat, 2 Feb 2013 06:33:33 -0800 (PST) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074747A6DA@mbx-01.win.nominum.com> References: <20130202122705.142E9B1E002@rfc-editor.org> <8D23D4052ABE7A4490E77B1A012B63074747A6DA@mbx-01.win.nominum.com> From: Donald Eastlake Date: Sat, 2 Feb 2013 09:33:33 -0500 Message-ID: To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] [Technical Errata Reported] RFC3118 (3474) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 14:33:55 -0000 I am not sure it was an "error" at all. Monotone means constant. Monotonically increasing means constantly increasing. However, see http://planetmath.org/MonotonicallyIncreasing.html (a site I have noting to do with but just found at the top of a web search. That does indicate that "strictly increasing" is more precise... Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Sat, Feb 2, 2013 at 8:19 AM, Ted Lemon wrote: > On Feb 2, 2013, at 7:27 AM, RFC Errata System wrote: >> The term "monotonically increasing" does not actually mean what the authors and editors hope it means. :-) An example of a monotonically increasing sequence is: >> 1, 2, 2, 2, 2, 2, 2... > > This is a fairly serious error, which also appears in RFC3315. :( > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Sat Feb 2 07:28:18 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A271521F8536 for ; Sat, 2 Feb 2013 07:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.547 X-Spam-Level: X-Spam-Status: No, score=-106.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgyLhvvbAk6i for ; Sat, 2 Feb 2013 07:28:17 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id CA27321F8530 for ; Sat, 2 Feb 2013 07:28:17 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUQ0wkMlh/CJO+REFth6fQeopkIfCtlPd@postini.com; Sat, 02 Feb 2013 07:28:17 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 35DAB108074 for ; Sat, 2 Feb 2013 07:28:16 -0800 (PST) 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 29F1B190043; Sat, 2 Feb 2013 07:28:16 -0800 (PST) (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.0318.004; Sat, 2 Feb 2013 07:28:10 -0800 From: Ted Lemon To: Donald Eastlake Thread-Topic: [dhcwg] [Technical Errata Reported] RFC3118 (3474) Thread-Index: AQHOAUC/ToF+Ryt4rUOvtZM+fkxiTJhnE5iAgAAUkICAAA9CgA== Date: Sat, 2 Feb 2013 15:28:09 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074747A929@mbx-01.win.nominum.com> References: <20130202122705.142E9B1E002@rfc-editor.org> <8D23D4052ABE7A4490E77B1A012B63074747A6DA@mbx-01.win.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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] [Technical Errata Reported] RFC3118 (3474) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 15:28:18 -0000 On Feb 2, 2013, at 9:33 AM, Donald Eastlake wrote: > I am not sure it was an "error" at all. Monotone means constant. > Monotonically increasing means constantly increasing. Wikipedia has a pretty good explanation, complete with graphs of various mo= notonic and non-monotonic functions: http://en.wikipedia.org/wiki/Monotonic_function= From internet-drafts@ietf.org Sun Feb 3 07:48:38 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC9C21F84B6; Sun, 3 Feb 2013 07:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2S-FptsRWxG; Sun, 3 Feb 2013 07:48:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416C121F83EF; Sun, 3 Feb 2013 07:48:22 -0800 (PST) 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.37 Message-ID: <20130203154822.20020.82067.idtracker@ietfa.amsl.com> Date: Sun, 03 Feb 2013 07:48:22 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-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: Sun, 03 Feb 2013 15:48:39 -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-07.txt Pages : 11 Date : 2013-02-03 Abstract: The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between the DHCPv6 relay agent and the DHCPv6 server. This mechanism is meant for the centralized DHCPv6 server to select the right configuration for the requesting DHCPv6 client based on the authorization information received from the RADIUS server, which is not co-located with the DHCPv6 server. The Network Access Server (NAS) acts as DHCPv6 relay agent and RADIUS client simultaneously in this document. 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-radius-opt-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From leaf.yeh.sdo@gmail.com Sun Feb 3 07:58:14 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3BA21F84DA for ; Sun, 3 Feb 2013 07:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.777 X-Spam-Level: X-Spam-Status: No, score=-2.777 tagged_above=-999 required=5 tests=[AWL=0.822, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPyiStfJy3pR for ; Sun, 3 Feb 2013 07:58:13 -0800 (PST) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id A0FB821F84C6 for ; Sun, 3 Feb 2013 07:58:13 -0800 (PST) Received: by mail-pb0-f41.google.com with SMTP id ro12so2799288pbb.14 for ; Sun, 03 Feb 2013 07:58:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=9MiHlPzR36vUmsqwGeIvM0W/ocDhhrhyPpdk/R/QOo0=; b=PpBmar0C8pLXpvCZqOw3fQN75hqj93EYX8LKYuurApZLkZzP4YgZxfryPIkNL3vOtI 2DvoMqlinUb0Xpw1IT07MWsB71z5pcZPfBhe72MBPH9JQBEzgT9+8xORTaqKOyjpcz0O 6R4NMnMynQNYxrtZ+mOK3Y7vUEfH9LcIOiudoWLPdjX8R4bZth+yIyUBGslHrmd4n88m 6hNnEIF5Zg/GB55B4F40NKa8yP6C3poPlCxYi3Z3D7Sw9iOCPCBx3Ptv2JqtYf6dZtNa ozZBxZwnWOonH98AwdAU5m/Ivj/Z8331Tc69Yk9Hsn2AH+kTbZMc8sc1bRlt5co7nVgf CpnQ== X-Received: by 10.68.135.98 with SMTP id pr2mr48189877pbb.101.1359907093376; Sun, 03 Feb 2013 07:58:13 -0800 (PST) Received: from PC ([218.18.196.86]) by mx.google.com with ESMTPS id mn4sm15038153pbc.12.2013.02.03.07.58.09 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 03 Feb 2013 07:58:12 -0800 (PST) From: "Leaf Yeh" To: "'Tomek Mrugalski'" References: <20121129121314.23806.75684.idtracker@ietfa.amsl.com> <50B8EC72.9050509@gmail.com> <50C5F756.8070006@gmail.com> <50CB1E72.6030600@gmail.com> In-Reply-To: <50CB1E72.6030600@gmail.com> Date: Sun, 3 Feb 2013 23:57:57 +0800 Message-ID: <510e8914.a4d1440a.7061.52d9@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3Z+F2nz8ni/+TLSKKkxRvEndWbMwoKo5ZA Content-Language: zh-cn Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-radius-opt-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 15:58:14 -0000 >> Appreciate your carefulness. I tend not to touch the word of >> 'stateful', but could make the clarification after Fig. 2 in section >> 3 as follows: 'If the authentication or the authorization through >> RADIUS passes, the NAS MUST store the RADIUS attributes received in >> the Access-Accept message from the RADIUS server during the whole >> session.' I regard this is the part of the RADIUS protocol. Tomek - Ok. You may add that radius state and exact retention policy is > outside of this document and just reference whatever document governs > NAS behavior. > Section 1.2 of RFC2865 has the definition of 'session', but it seems > difficult to find the exact words on 'radius state' or 'retention > policy' in this RFC. Tomek - Ok. So I think just saying that "how NAS manages the state is outside of scope of this document" would be ok. I will change the above text in section 3 to be: ' If the authentication or the authorization through RADIUS passes, the NAS MUST store the information indicated in the RADIUS attributes received in the Access-Accept message from the RADIUS server during the whole session. How the NAS manages these information during the RADIUS session is out of the scope of this document. ' Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski Sent: Friday, December 14, 2012 8:41 PM To: Leaf yeh Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-radius-opt-05.txt On 14.12.2012 08:59, Leaf yeh wrote: >> Appreciate your carefulness. I tend not to touch the word of >> 'stateful', but could make the clarification after Fig. 2 in section >> 3 as follows: 'If the authentication or the authorization through >> RADIUS passes, the NAS MUST store the RADIUS attributes received in >> the Access-Accept message from the RADIUS server during the whole >> session.' I regard this is the part of the RADIUS protocol. > Ok. You may add that radius state and exact retention policy is > outside of this document and just reference whatever document governs > NAS behavior. > > Section 1.2 of RFC2865 has the definition of 'session', but it seems > difficult to find the exact words on 'radius state' or 'retention > policy' in this RFC. Ok. So I think just saying that "how NAS manages the state is outside of scope of this document" would be ok. >> In your example, the NAS gets the 'special prefix' in the attribute >> of Delegated-IPv6-Prefix (123) from the RADIUS server. >> Then the relay only need to convey the Delegated-IPv6-Prefix (123) to >> the server. I meant the relay don't need to convey 'User-Name (1)' >> through this option to the server, if it is regarded only for the >> RADIUS server. > Tomek - You are thinking about your use cases. It's not about prefixes > and addresses only. What if I want someone with special Radius > user-name to get a different set of other DHCP options, special > personal dns server for my boss, dedicated NTP server for engineers in > lab etc? I'd like it to be a generic Radius option that happens to > solve your cases, but is flexible enough to cover others as well. > > I tend to keep the scope of the draft for the use cases defined, and > still can't get the border of your question on the real use case yet. Since nobody else joined the discussion, I suppose there's not much desire for other cases. Keep the text as it is then. > As the appearance of the OPTION_RADIUS, how about the following text: > ' According to the network scenarios described in section 3, the > OPTION_RADIUS SHOULD appear in the RELAY-FORW (12) message relaying > SOLICIT (1), REQUEST (3) and REBIND (6) from the DHCPv6 client, and > MAY appear in the RELAY-FORW (12) relaying any other message from the > DHCPv6 client. ' ? Sounds good. I'm not sure if you meant REBIND or RENEW, but I'm fine with both. > Tomek - Existing text is ok, but it is not sufficient and it talks > about different circumstances (what to do when someone tries to add a > new option to the registry). I'm talking about potential security > problems once the protocol is deployed. How about this one: "Networks > that deploy this mechanism may allow new attack vector against DHCPv6 > servers in case DHCPv6 relay is compromised. By forging Radius options > in relayed messages, the attacker can influence DHCPv6 server > assignment policy.". In simple words, if your Radius authentication is > completely secure and bullet proof, someone still can hijack your > relay and just include options that say "yeah, this user has > authentication, honest!" and the server will happily provision an > unathenticated device. > > I would adopt the above text for 'Security Consideration' if you > insist. How about the text to be: 'The mechanism described in this > document may introduce new attack vector against the DHCPv6 server in > case the DHCPv6 relay agent is compromised. By forging the RADIUS > attributes contained in the OPTION_RADIUS of the RELAY-FORW (12) > messages, the attacker may influence the parameter assignment on the > DHCPv6 server for the DHCPv6 clients. But in the network scenarios > described in the section 3, NAS could always be regarded as a trusted > network component in the real deployment. ' ? I don't have any experience with NAS, but my understanding is that if someone manages to hijack your NAS you have bigger problems than just influencing your DHCP server. But since this draft is about DHCP, it is useful to mention that. Your proposed text is ok. Ok, this addresses all my comments. Thank you. Cheers, Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From internet-drafts@ietf.org Sun Feb 3 08:37:19 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0743921F8445; Sun, 3 Feb 2013 08:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2bb-dH61qes; Sun, 3 Feb 2013 08:37:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521AA21F8499; Sun, 3 Feb 2013 08:37:18 -0800 (PST) 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.37 Message-ID: <20130203163718.27270.10340.idtracker@ietfa.amsl.com> Date: Sun, 03 Feb 2013 08:37:18 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-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: Sun, 03 Feb 2013 16:37:19 -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 Filename : draft-ietf-dhc-dhcpv6-radius-opt-08.txt Pages : 11 Date : 2013-02-03 Abstract: The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between the DHCPv6 relay agent and the DHCPv6 server. This mechanism is meant for the centralized DHCPv6 server to select the right configuration for the requesting DHCPv6 client based on the authorization information received from the RADIUS server, which is not co-located with the DHCPv6 server. The Network Access Server (NAS) acts as DHCPv6 relay agent and RADIUS client simultaneously in this document. 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-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-radius-opt-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Ted.Lemon@nominum.com Sun Feb 3 08:54:20 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCBA21F8506 for ; Sun, 3 Feb 2013 08:54:20 -0800 (PST) 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.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xynCXQGDhyWW for ; Sun, 3 Feb 2013 08:54:19 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id AC7DF21F8622 for ; Sun, 3 Feb 2013 08:54:19 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUQ6WO06Bx4Jv/ZsZtQpP0nxx+3Ct6f87@postini.com; Sun, 03 Feb 2013 08:54:19 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 50CC71080A3 for ; Sun, 3 Feb 2013 08:54:19 -0800 (PST) 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 476CF190043 for ; Sun, 3 Feb 2013 08:54:19 -0800 (PST) (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.0318.004; Sun, 3 Feb 2013 08:54:14 -0800 From: Ted Lemon To: "dhcwg@ietf.org WG" Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-08 Thread-Index: AQHOAi8Y6L/mEtMT5UW0fdfJAZ+WqA== Date: Sun, 3 Feb 2013 16:54:13 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074747BF6B@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 16:54:20 -0000 The authors of this draft have asked for a new working group last call. We= had a WGLC in November, and there were substantial and constructive commen= ts, which are incorporated in the new version. The changes can be seen he= re:=20 http://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-dhc-dhcpv6-radius-opt-05.tx= t&url2=3Ddraft-ietf-dhc-dhcpv6-radius-opt-08.txt This diff includes a number of changes that have occurred since the most re= cent last call=97there have been several revisions of the draft. If you haven't read the draft, now would be a good time to do so: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-08 If you think the draft is ready to advance, please indicate your support on= the mailing list. If you think it is not ready, please say so as well. = And of course, additional comments are solicited and welcome. We will ev= aluate consensus on or after February 19. P.S. I asked Leaf to remove me as an author of the draft, because I haven't= actually contributed anything substantial to it, and working group chairs = authoring drafts create various procedural problems. If anybody feels tha= t this is inappropriate, please say so. As a working group participant, I= think the draft is a reasonably good idea, but I have no personal stake in= the advancement or non-advancement of the draft=97it doesn't actually rela= te to work I do outside of IETF, nor does my IETF work depend on it. From iesg-secretary@ietf.org Mon Feb 4 06:39:20 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB2B21F8740; Mon, 4 Feb 2013 06:39:20 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wByskK6Pkoxn; Mon, 4 Feb 2013 06:39:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4481521F874B; Mon, 4 Feb 2013 06:39:15 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130204143915.20823.30449.idtracker@ietfa.amsl.com> Date: Mon, 04 Feb 2013 06:39:15 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] Last Call: (Client Link-layer Address Option in DHCPv6) to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 14:39:21 -0000 The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Client Link-layer Address Option in DHCPv6' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-02-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the format and mechanism that is to be used for encoding client link-layer address in DHCPv6 Relay-Forward messages by defining a new DHCPv6 Client Link-layer Address option. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt/ballot/ No IPR declarations have been submitted directly on this I-D. From Ted.Lemon@nominum.com Thu Feb 7 10:54:49 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D2621F86AA for ; Thu, 7 Feb 2013 10:54:49 -0800 (PST) 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.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtLQmn7UEF-a for ; Thu, 7 Feb 2013 10:54:48 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id EB9AD21F867E for ; Thu, 7 Feb 2013 10:54:47 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKURP4dzknhtjyjEGCQv6ASuazkxL4pftW@postini.com; Thu, 07 Feb 2013 10:54:48 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id EE57A108080 for ; Thu, 7 Feb 2013 10:54:46 -0800 (PST) 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 E5F0D190043 for ; Thu, 7 Feb 2013 10:54:46 -0800 (PST) (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.0318.004; Thu, 7 Feb 2013 10:54:46 -0800 From: Ted Lemon To: "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-08 Thread-Index: AQHOAi8Y6L/mEtMT5UW0fdfJAZ+WqJhvSu6A Date: Thu, 7 Feb 2013 18:54:47 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747483272@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B63074747BF6B@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074747BF6B@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <3A2D8515DC25084EA0E2E8D0D43CC382@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 18:54:49 -0000 On Feb 3, 2013, at 11:54 AM, Ted Lemon wrote: > If you think the draft is ready to advance, please indicate your support = on the mailing list. If you think it is not ready, please say so as well.= And of course, additional comments are solicited and welcome. We will = evaluate consensus on or after February 19. Reminder: we have seen zero responses to this WGLC. Does nobody want RADI= US support for DHCPv6? From tomasz.mrugalski@gmail.com Fri Feb 8 02:45:55 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207E121F876E for ; Fri, 8 Feb 2013 02:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQQ7NRWB6M18 for ; Fri, 8 Feb 2013 02:45:54 -0800 (PST) Received: from mail-we0-x229.google.com (we-in-x0229.1e100.net [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6E96A21F8700 for ; Fri, 8 Feb 2013 02:45:54 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id t11so2958458wey.0 for ; Fri, 08 Feb 2013 02:45:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=Lulj2r9zAH6k4+gvVAahWW034EsNURhmFSVR2MNLAtY=; b=atLkqLoRwQE03JRWo8NavHKsYuctjAItnFt6ObmSrvalGWZqCus3zkC4yTvN4wXfrP Rg95HSaWyqmtFNa4ecuQ7nHrKzhtAOJWaFwggtP5SdDyOKtuc9L9t229VfCj25RQ7VJF s8LhoY52HAARAKB/WJ1w4Ymr5Db7855AD0IMkz527HjGF9xhqTQbdsanDZBwrBEgqEoE DAuJ2/SdXuT5hgd9O1G9FoDeiFHAlTc3StW4oEEiloM0hLgOrHW0y0DaGFlu0RL5550z CI+xAw199OVlcf5pigvT7rWsV32p9dCpbYoUhRsvROaT/QYk3D0HmHU0YapdRCYH3X50 DaJQ== X-Received: by 10.180.108.3 with SMTP id hg3mr1474151wib.33.1360320353569; Fri, 08 Feb 2013 02:45:53 -0800 (PST) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id m6sm14636079wic.2.2013.02.08.02.45.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Feb 2013 02:45:51 -0800 (PST) Message-ID: <5114D757.3010008@gmail.com> Date: Fri, 08 Feb 2013 11:45:43 +0100 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: dhcwg@ietf.org References: <8D23D4052ABE7A4490E77B1A012B63074747BF6B@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630747483272@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747483272@mbx-01.win.nominum.com> X-TagToolbar-Keys: D20130208114543971 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 10:45:55 -0000 On 07.02.2013 19:54, Ted Lemon wrote: > On Feb 3, 2013, at 11:54 AM, Ted Lemon > wrote: >> If you think the draft is ready to advance, please indicate your >> support on the mailing list. If you think it is not ready, please >> say so as well. And of course, additional comments are solicited >> and welcome. We will evaluate consensus on or after February 19. > > Reminder: we have seen zero responses to this WGLC. Does nobody > want RADIUS support for DHCPv6? I did review previous version and the changes between -07 and -08. They look good and the document is in good shape. I have no further comments on it. I support this work and think it is ready to go. Tomek From internet-drafts@ietf.org Sun Feb 10 07:32:16 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA18F21F881A; Sun, 10 Feb 2013 07:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvBLBiD0vijT; Sun, 10 Feb 2013 07:32:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64C621F8472; Sun, 10 Feb 2013 07:32:12 -0800 (PST) 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.37 Message-ID: <20130210153212.24757.55988.idtracker@ietfa.amsl.com> Date: Sun, 10 Feb 2013 07:32:12 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-prefix-pool-opt-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 15:32:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : Prefix Pool Option for DHCPv6 Relay Agent on the Provide= r Edge Routers Author(s) : Leaf Y. Yeh Ted Lemon Mohamed Boucadair Filename : draft-ietf-dhc-dhcpv6-prefix-pool-opt-02.txt Pages : 13 Date : 2013-02-10 Abstract: The DHCPv6 Prefix Pool option provides a mechanism for DHCPv6 Prefix Delegation (DHCPv6-PD), allowing the DHCPv6 server to notify a DHCPv6 relay agent implemented on a Provider Edge (PE) router about active prefix pools allocated by the DHCPv6 server to the PE router. The information of active prefix pools can be used to enforce IPv6 route aggregation on the PE router through adding or removing aggregation routes according to the status of the prefix pools. The advertising of the aggregation routes in the routing protocol enabled on the network-facing interface of PE routers will dramatically decreases the number of the routing table entries in the ISP network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-prefix-pool-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-prefix-pool-opt-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ghalwasi@cisco.com Sun Feb 10 08:44:50 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D8F21F8689 for ; Sun, 10 Feb 2013 08:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wc0ODR-vWOzb for ; Sun, 10 Feb 2013 08:44:50 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id DBC2E21F8630 for ; Sun, 10 Feb 2013 08:44:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1922; q=dns/txt; s=iport; t=1360514690; x=1361724290; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=9jRZyBZ6+eQL16JZVD7DDEWe5kdFGsoyb3GY7N+G1Aw=; b=U10En0h8jaj98SpDtwkvn7QMTkTfAHzx7KEYI2jz5kQOCUdIpdszXn3h rglVSO/IjgEFEDrC6qO/jsQ0ujHGrjhNfaCxszUF1Dco0XBpgcbrbtrvv a0EjdEFAgp14uYaWjagFffyrI7Jv0D0jdzQ5juU1jtzuo0XO9mHRuL0pJ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKbNF1GtJXG9/2dsb2JhbABFwRIWc4IfAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAkIAgQBEgiICgy/G5EpYQOXQY82gwaCJA X-IronPort-AV: E=Sophos;i="4.84,639,1355097600"; d="scan'208";a="175446299" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 10 Feb 2013 16:44:49 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1AGin5b026045 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 10 Feb 2013 16:44:49 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.248]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0328.009; Sun, 10 Feb 2013 10:44:49 -0600 From: "Gaurav Halwasia (ghalwasi)" To: Ted Lemon , "dhcwg@ietf.org WG" Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-08 Thread-Index: AQHOAi8Y6L/mEtMT5UW0fdfJAZ+WqJhzV0SA Date: Sun, 10 Feb 2013 16:44:48 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB22E48FE5@xmb-aln-x06.cisco.com> References: <8D23D4052ABE7A4490E77B1A012B63074747BF6B@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074747BF6B@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.66.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 16:44:50 -0000 I support the advancement of this draft. It should move forward. -Gaurav -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Sunday, February 03, 2013 10:24 PM To: dhcwg@ietf.org WG Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-08 The authors of this draft have asked for a new working group last call. We= had a WGLC in November, and there were substantial and constructive commen= ts, which are incorporated in the new version. The changes can be seen he= re:=20 http://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-dhc-dhcpv6-radius-opt-05.tx= t&url2=3Ddraft-ietf-dhc-dhcpv6-radius-opt-08.txt This diff includes a number of changes that have occurred since the most re= cent last call-there have been several revisions of the draft. If you haven't read the draft, now would be a good time to do so: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-08 If you think the draft is ready to advance, please indicate your support on= the mailing list. If you think it is not ready, please say so as well. = And of course, additional comments are solicited and welcome. We will ev= aluate consensus on or after February 19. P.S. I asked Leaf to remove me as an author of the draft, because I haven't= actually contributed anything substantial to it, and working group chairs = authoring drafts create various procedural problems. If anybody feels tha= t this is inappropriate, please say so. As a working group participant, I= think the draft is a reasonably good idea, but I have no personal stake in= the advancement or non-advancement of the draft-it doesn't actually relate= to work I do outside of IETF, nor does my IETF work depend on it. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From leaf.yeh.sdo@gmail.com Sun Feb 10 09:21:28 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A9B21F871D for ; Sun, 10 Feb 2013 09:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.29 X-Spam-Level: X-Spam-Status: No, score=-0.29 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_NJABL_PROXY=1.643, SARE_RECV_IP_219128=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEOwfy3RtyQB for ; Sun, 10 Feb 2013 09:21:27 -0800 (PST) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id DE54121F871C for ; Sun, 10 Feb 2013 09:21:27 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id fa10so2809088pad.27 for ; Sun, 10 Feb 2013 09:21:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=9jP1Ybd4x/V99Sjvm2F/2slv3gIQtDMo9inhv3wHVOc=; b=yGkwaz7NyZuvIeAyJptf9ma+TXkQ++P9RWf0H2reBydmnnFLkeKrKZiiFFRjU69cOw WRCvqmMTCanVj+oWwbxDh8sbE0Hvlu/EvCUf/bjHhwnn5KqhxATomzsCMFjaAwSM625c 2Et9P7q15hsZIQePBfuhUDOB1mXxAk7g7DEye5a5/XzDZJeO+yTW6pn8T3exz5975Om3 08fmgElzioMT9EwXBfKJS6mcrY9UrzKBdYR0QXs39bNucWNt17NVaJmAh9uYyAor/Z4h IVgIWdsFxf1IkApCyg1GpJha+l0JZDPBELUhSD6eOPQHaXT1HWjvB/j3N5NBc3lwFhTd s+XA== X-Received: by 10.66.79.97 with SMTP id i1mr35391874pax.47.1360516887670; Sun, 10 Feb 2013 09:21:27 -0800 (PST) Received: from PC ([219.133.130.183]) by mx.google.com with ESMTPS id kr9sm4969430pbc.2.2013.02.10.09.21.25 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 10 Feb 2013 09:21:27 -0800 (PST) From: "Leaf Yeh" To: References: <20130210153212.24757.55988.idtracker@ietfa.amsl.com> In-Reply-To: <20130210153212.24757.55988.idtracker@ietfa.amsl.com> Date: Mon, 11 Feb 2013 01:21:18 +0800 Message-ID: <5117d717.a9cb440a.768e.2188@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4Ho+0k5lPwidVpSKKFmCXedQ2JYgAC4f7Q Content-Language: zh-cn Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-prefix-pool-opt-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 17:21:28 -0000 Dear DHC folks, I polished the draft (OPTION_PREFIX_POOL) to be ver.-02, which solicits your kind comments again. The changes of the text in it can be reviewed at https://www.ietf.org/rfcdiff?url1=draft-ietf-dhc-dhcpv6-prefix-pool-opt-00&d ifftype=--html&submit=Go%21&url2=draft-ietf-dhc-dhcpv6-prefix-pool-opt-02. I hope we could make WGLC on it before IETF86. Best Regards, Leaf PS. Merry Spring Festival from far-east and happy Chinese new year! -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Sunday, February 10, 2013 11:32 PM To: i-d-announce@ietf.org Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-prefix-pool-opt-02.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 : Prefix Pool Option for DHCPv6 Relay Agent on the Provider Edge Routers Author(s) : Leaf Y. Yeh Ted Lemon Mohamed Boucadair Filename : draft-ietf-dhc-dhcpv6-prefix-pool-opt-02.txt Pages : 13 Date : 2013-02-10 Abstract: The DHCPv6 Prefix Pool option provides a mechanism for DHCPv6 Prefix Delegation (DHCPv6-PD), allowing the DHCPv6 server to notify a DHCPv6 relay agent implemented on a Provider Edge (PE) router about active prefix pools allocated by the DHCPv6 server to the PE router. The information of active prefix pools can be used to enforce IPv6 route aggregation on the PE router through adding or removing aggregation routes according to the status of the prefix pools. The advertising of the aggregation routes in the routing protocol enabled on the network-facing interface of PE routers will dramatically decreases the number of the routing table entries in the ISP network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-prefix-pool-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From iesg-secretary@ietf.org Mon Feb 11 13:02:27 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C4D21F8886; Mon, 11 Feb 2013 13:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5W6oChzonkm; Mon, 11 Feb 2013 13:02:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC9921F8878; Mon, 11 Feb 2013 13:02:26 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130211210226.20754.12091.idtracker@ietfa.amsl.com> Date: Mon, 11 Feb 2013 13:02:26 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] Last Call: (Secure DHCPv6 Using CGAs) to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 21:02:27 -0000 The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Secure DHCPv6 Using CGAs' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-02-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCPv6 servers to pass configuration parameters. It offers configuration flexibility. If not secured, DHCPv6 is vulnerable to various attacks, particularly spoofing attacks. This document analyzes the security issues of DHCPv6 and specifies a Secure DHCPv6 mechanism based on using CGAs. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-secure-dhcpv6/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-secure-dhcpv6/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1343/ From Ted.Lemon@nominum.com Mon Feb 11 16:24:15 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AF621F8671 for ; Mon, 11 Feb 2013 16:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.575 X-Spam-Level: X-Spam-Status: No, score=-106.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wpzz7oRQnAV0 for ; Mon, 11 Feb 2013 16:24:14 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id C93CC21F85EA for ; Mon, 11 Feb 2013 16:24:14 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKURmLrgiQpI6FNmk2hWaFzh6Z3zNahPxu@postini.com; Mon, 11 Feb 2013 16:24:14 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 48F8110801F for ; Mon, 11 Feb 2013 16:24:14 -0800 (PST) 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 3DDB2190043 for ; Mon, 11 Feb 2013 16:24:14 -0800 (PST) (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.0318.004; Mon, 11 Feb 2013 16:24:14 -0800 From: Ted Lemon To: "dhcwg@ietf.org WG" Thread-Topic: Call for adoption: draft-rajtar-dhc-v4configuration Thread-Index: AQHOCLdJAJANwYon10iWTDBlj58gmA== Date: Tue, 12 Feb 2013 00:24:13 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <8F52E04960DE1F4B92BA0127D3AE834D@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 12 Feb 2013 00:24:15 -0000 At the IETF meeting in Atlanta, we ended the session with a long discussion= about how to solve the problem of configuring MAP-E and lw4over6 IPv4 stac= ks; several possibilities were presented, and we decided that we would writ= e a draft summarizing these possibilities so that the working group could s= tate a preference. Time went on, and none of the people who volunteered actually did anything,= so a couple of weeks ago Branimir Rajtar and Ian Farrer offered to write i= t up based on the notes from the last meeting. They have done so, and sub= mitted a -00 draft: https://datatracker.ietf.org/doc/draft-rajtar-dhc-v4con= figuration/ The purpose of this draft is to enumerate all the potential solutions to th= is problem, describe their pros and cons, and make a recommendation. The = current state of the draft is the recommendation that most people seemed to= be leaning toward at the end of the meeting in Atlanta, but it's not bindi= ng; if during discussion the working group decides to recommend something e= lse, the document will be updated to reflect that. If you think the working group should in fact produce this document, please= say so on the mailing list. If you think we shouldn't produce such a doc= ument, please also say so. If you have comments on the content of the doc= ument, please hold off on that until it's been adopted, or not adopted. I= f it's not adopted, the comments are moot; if it is adopted, the job of the= working group will be to finish it according to the input of working group= participants, which is where your comments would come in. We will evaluate consensus on February 25. Thanks! From cas@trans-nt.com Tue Feb 12 12:25:46 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50EF521F8B54 for ; Tue, 12 Feb 2013 12:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.781 X-Spam-Level: X-Spam-Status: No, score=-0.781 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_EQ_JP=1.265] 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 3t8cyOfJrfEa for ; Tue, 12 Feb 2013 12:25:45 -0800 (PST) Received: from dump.fs.trans-nt.com (smtp.trans-nt.co.jp [202.10.98.251]) by ietfa.amsl.com (Postfix) with SMTP id 3DB8A21F8B51 for ; Tue, 12 Feb 2013 12:25:44 -0800 (PST) Received: (qmail 64711 invoked from network); 13 Feb 2013 05:25:28 +0900 Received: from red.fs.trans-nt.co.jp (HELO dhcp142.gion.lh.trans-nt.com) (202.10.98.240) by smtp.trans-nt.co.jp with SMTP; 13 Feb 2013 05:25:28 +0900 Message-ID: <511AA538.2000902@trans-nt.com> Date: Wed, 13 Feb 2013 05:25:28 +0900 From: Hiroki Nakano Organization: cas authorized 53a6c6e30f1471298320e605c741e412 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: dhcwg@ietf.org References: <4F5EA754.50403@trans-nt.com> <56269277-D110-4052-A388-E56CD23DD8B5@nominum.com> <4F5EE6B9.4050704@trans-nt.com> <44C2AE51-D4AD-49CA-BA84-B4B6447823D4@nominum.com> <4F5F953C.5000504@trans-nt.com> <5115BCAB.9050104@trans-nt.com> <8D23D4052ABE7A4490E77B1A012B63074748554A@mbx-01.win.nominum.com> <5116E9A7.2010304@trans-nt.com> In-Reply-To: <5116E9A7.2010304@trans-nt.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: "" , Ted Lemon , "cas.nakano@gmail.com" Subject: [dhcwg] IEEE 802.11ai and DHCP X-BeenThere: dhcwg@ietf.org 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, 12 Feb 2013 20:25:46 -0000 Dear all, I'm participating in IEEE 802.11 WG TGai task group which is for FILS (Fast Initiali Link Setup). They are working for speeding up of 802.11 process and trying to provide a new framework for higher layer protocols. I'd like to introduce the overview of prospective 802.11ai specification and discuss usages of DHCP on it with DHC WG people in March. The followings are a brief introduction. TGai supposes Wireless LAN is used in very crowded envirionment such as railway stations in a giant metropolis. TGai also supposes moving hosts through the front of Access Points. In these cases, it is effective to reduce management frames of 802.11, especially frames for probing APs, authentication and association. The current framework takes a few seconds to set up network connectivity before starting to communicate. The target of TGai is under one second. TGai is trying to reduce management frames of 802.11 itself, and in addition provide framework for higher layers such as IP to send and receive packets during 802.11 association process. The currently proposed framework provides "ONE round-trip packet exchange" by piggybacking on 802.11 Association Request/Response frames. My interest is how to fit DHCP to this framework. In case of DHCPv4, this is achieved by using Rapid Commit Option (RFC4039) and making some additional and trivial rules. In case of DHCPv6, we have to use both RA and DHCPv6. In addition, DAD and randomly generated addresses have to be considered. Share your idea, please. 802.11 TGai is still going on and its specification is subject to change, but I'd like to discuss in IETF DHCP issues related to 802.11ai and arrange I-D according to the progress of TGai task group. Regards, Hiroki Nakano Trans New Technology, Inc. From Ted.Lemon@nominum.com Tue Feb 12 12:39:17 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C0221F8B0E for ; Tue, 12 Feb 2013 12:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 iiKfkwzOxXOC for ; Tue, 12 Feb 2013 12:39:17 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 489FE21F8B0C for ; Tue, 12 Feb 2013 12:39:17 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKURqocJ3cBcZQ6sOD/TJW/gCQFkCecOlp@postini.com; Tue, 12 Feb 2013 12:39:17 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 796C3108082 for ; Tue, 12 Feb 2013 12:39:12 -0800 (PST) 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 6A1C2190043; Tue, 12 Feb 2013 12:39:12 -0800 (PST) (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.0318.004; Tue, 12 Feb 2013 12:39:12 -0800 From: Ted Lemon To: Hiroki Nakano Thread-Topic: IEEE 802.11ai and DHCP Thread-Index: AQHOCV8l67TaS/hjlkqOnzgfAu5xSph3NWMA Date: Tue, 12 Feb 2013 20:39:11 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074748923B@mbx-01.win.nominum.com> References: <4F5EA754.50403@trans-nt.com> <56269277-D110-4052-A388-E56CD23DD8B5@nominum.com> <4F5EE6B9.4050704@trans-nt.com> <44C2AE51-D4AD-49CA-BA84-B4B6447823D4@nominum.com> <4F5F953C.5000504@trans-nt.com> <5115BCAB.9050104@trans-nt.com> <8D23D4052ABE7A4490E77B1A012B63074748554A@mbx-01.win.nominum.com> <5116E9A7.2010304@trans-nt.com> <511AA538.2000902@trans-nt.com> In-Reply-To: <511AA538.2000902@trans-nt.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-2022-jp" Content-ID: <6D5B0D0F42D7B442A843119F67C5B44D@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "cas.nakano@gmail.com" Subject: Re: [dhcwg] IEEE 802.11ai and DHCP X-BeenThere: dhcwg@ietf.org 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, 12 Feb 2013 20:39:18 -0000 Interesting. Is the situation that you are switching from one access poin= t to another within a single wifi fabric, or are you just trying to get rap= id acquisition of the wifi network when you arrive for the first time? From cas@trans-nt.com Tue Feb 12 19:50:17 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2D121F8A06 for ; Tue, 12 Feb 2013 19:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.781 X-Spam-Level: X-Spam-Status: No, score=-0.781 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_EQ_JP=1.265] 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 WB7yM+SghSB7 for ; Tue, 12 Feb 2013 19:50:17 -0800 (PST) Received: from dump.fs.trans-nt.com (smtp.trans-nt.co.jp [202.10.98.251]) by ietfa.amsl.com (Postfix) with SMTP id A781121F8925 for ; Tue, 12 Feb 2013 19:50:15 -0800 (PST) Received: (qmail 76198 invoked from network); 13 Feb 2013 12:49:52 +0900 Received: from red.fs.trans-nt.co.jp (HELO platinum.local) (202.10.98.240) by smtp.trans-nt.co.jp with SMTP; 13 Feb 2013 12:49:52 +0900 Message-ID: <511B0D5F.4020809@trans-nt.com> Date: Wed, 13 Feb 2013 12:49:51 +0900 From: Hiroki Nakano Organization: cas authorized 53a6c6e30f1471298320e605c741e412 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Ted Lemon References: <4F5EA754.50403@trans-nt.com> <56269277-D110-4052-A388-E56CD23DD8B5@nominum.com> <4F5EE6B9.4050704@trans-nt.com> <44C2AE51-D4AD-49CA-BA84-B4B6447823D4@nominum.com> <4F5F953C.5000504@trans-nt.com> <5115BCAB.9050104@trans-nt.com> <8D23D4052ABE7A4490E77B1A012B63074748554A@mbx-01.win.nominum.com> <5116E9A7.2010304@trans-nt.com> <511AA538.2000902@trans-nt.com> <8D23D4052ABE7A4490E77B1A012B63074748923B@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074748923B@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, "" , cas@gmail4.trans-nt.com Subject: Re: [dhcwg] IEEE 802.11ai and DHCP X-BeenThere: dhcwg@ietf.org 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, 13 Feb 2013 03:50:17 -0000 13/02/13 5:39), Ted Lemon wrote: > Interesting. Is the situation that you are switching from one > access point to another within a single wifi fabric, or are you > just trying to get rapid acquisition of the wifi network when > you arrive for the first time? Thank you for your attention. Officially, the later one is the target of TGai. TGai is called FILS (Fast Initial Link Setup.) The 802.11 has 11r for quick roaming within a single 802 network. In case of APs not configuring for 802 roaming, all stations arrived are treated as 'the first time', that is, 'initial link setup.' In the viewpoint of clients, the former case is possible and you may need more supports from higher layers like MobileIP, SCTP, HTTP cookies, etc in order to survive your session. I hope we also talk together about this topic somewhere in IETF:) Regards, Hiroki Nakano Trans New Technology, Inc. From roberta.maglione@telecomitalia.it Wed Feb 13 03:18:00 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86DF321F87D2 for ; Wed, 13 Feb 2013 03:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 9+2Sck90GxJq for ; Wed, 13 Feb 2013 03:18:00 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id B1DE321F8681 for ; Wed, 13 Feb 2013 03:17:59 -0800 (PST) Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 13 Feb 2013 12:17:58 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Wed, 13 Feb 2013 12:17:58 +0100 From: Maglione Roberta To: 'Ted Lemon' , "dhcwg@ietf.org WG" Date: Wed, 13 Feb 2013 12:17:57 +0100 Thread-Topic: Call for adoption: draft-rajtar-dhc-v4configuration Thread-Index: AQHOCLdJAJANwYon10iWTDBlj58gmJh3pPhg Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE519D1A750C@GRFMBX704BA020.griffon.local> References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Capello Alessandro Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 13 Feb 2013 11:18:00 -0000 Hello, I do not support the adoption of this draft. There are scenarios (like IPv6 with PPP) where DHCPv4 is not used at all, w= hile DHCPv6 is required and already in place for IPv6 connectivity. Adding = DHCPv4 would require changing the current architecture, while re-using DHCP= v6 in my opinion appears a simpler approach. Best regards, Roberta -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Tuesday, February 12, 2013 1:24 AM To: dhcwg@ietf.org WG Subject: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration At the IETF meeting in Atlanta, we ended the session with a long discussion= about how to solve the problem of configuring MAP-E and lw4over6 IPv4 stac= ks; several possibilities were presented, and we decided that we would writ= e a draft summarizing these possibilities so that the working group could s= tate a preference. Time went on, and none of the people who volunteered actually did anything,= so a couple of weeks ago Branimir Rajtar and Ian Farrer offered to write i= t up based on the notes from the last meeting. They have done so, and sub= mitted a -00 draft: https://datatracker.ietf.org/doc/draft-rajtar-dhc-v4con= figuration/ The purpose of this draft is to enumerate all the potential solutions to th= is problem, describe their pros and cons, and make a recommendation. The = current state of the draft is the recommendation that most people seemed to= be leaning toward at the end of the meeting in Atlanta, but it's not bindi= ng; if during discussion the working group decides to recommend something e= lse, the document will be updated to reflect that. If you think the working group should in fact produce this document, please= say so on the mailing list. If you think we shouldn't produce such a doc= ument, please also say so. If you have comments on the content of the doc= ument, please hold off on that until it's been adopted, or not adopted. I= f it's not adopted, the comments are moot; if it is adopted, the job of the= working group will be to finish it according to the input of working group= participants, which is where your comments would come in. We will evaluate consensus on February 25. Thanks! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg 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 wdec.ietf@gmail.com Wed Feb 13 03:24:25 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47B921F88CC for ; Wed, 13 Feb 2013 03:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.32 X-Spam-Level: X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, 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 zqFm4eATieu0 for ; Wed, 13 Feb 2013 03:24:25 -0800 (PST) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) by ietfa.amsl.com (Postfix) with ESMTP id E800621F88CA for ; Wed, 13 Feb 2013 03:24:24 -0800 (PST) Received: by mail-qc0-f175.google.com with SMTP id j3so402721qcs.34 for ; Wed, 13 Feb 2013 03:24:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=dNOXyrFdcLW6h8BwtiPHVu1mVhSS4/puip43vqvqNWo=; b=WOeShFZ8tVUiEXyE/LSjHOnx+yfp1nV9JEVohLQ7VQqnnqH+NGHrN3Fvi+bzY0ZRdU UAHyJLjGmp+V1YTxgk1xIe6OAErvzC94df23HNlil+RZFLsZR9n5UOsb5DTP8Uv4gvwD dSVROiUgCu5NfVO5TBQeIoeJtJpblJ7qlhOACYIwSs0y65zrQUjEShLl2ViHeDa/2e/v yLdyEvLgfQSw/caZRioLFjtM/uyIxfkq/c0usnxmFuRqJjPNODJuXya7nMJV5lFGE/jR IwOUGy45WTkhEpAoughg3oC8MwNRl6nB5lDTPNd3D+ZYe39oz/+Cg/i0b3s1jHFGxiYx HamA== MIME-Version: 1.0 X-Received: by 10.49.133.68 with SMTP id pa4mr9643836qeb.50.1360754664335; Wed, 13 Feb 2013 03:24:24 -0800 (PST) Received: by 10.49.75.33 with HTTP; Wed, 13 Feb 2013 03:24:24 -0800 (PST) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> Date: Wed, 13 Feb 2013 12:24:24 +0100 Message-ID: From: Wojciech Dec To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7bd6b99c64e86b04d5996280 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 13 Feb 2013 11:24:25 -0000 --047d7bd6b99c64e86b04d5996280 Content-Type: text/plain; charset=ISO-8859-1 Hi Ted, think that to do a fair evaluation we'd need to go with a set of requirements, which currently this document does not include. Eg It's assumed that legacy DHCPv4 options are to be supported, but this is definitely not a universal requirement and in fact a total non requirement for several operators. Thus it either needs to scope also set of requirements or those requirements need to come in from Softwire. Without this, it's hard to see how a pro/con analysis will prove to be useful. Regards, Woj. On 12 February 2013 01:24, Ted Lemon wrote: > At the IETF meeting in Atlanta, we ended the session with a long > discussion about how to solve the problem of configuring MAP-E and lw4over6 > IPv4 stacks; several possibilities were presented, and we decided that we > would write a draft summarizing these possibilities so that the working > group could state a preference. > > Time went on, and none of the people who volunteered actually did > anything, so a couple of weeks ago Branimir Rajtar and Ian Farrer offered > to write it up based on the notes from the last meeting. They have done > so, and submitted a -00 draft: > https://datatracker.ietf.org/doc/draft-rajtar-dhc-v4configuration/ > > The purpose of this draft is to enumerate all the potential solutions to > this problem, describe their pros and cons, and make a recommendation. > The current state of the draft is the recommendation that most people > seemed to be leaning toward at the end of the meeting in Atlanta, but it's > not binding; if during discussion the working group decides to recommend > something else, the document will be updated to reflect that. > > If you think the working group should in fact produce this document, > please say so on the mailing list. If you think we shouldn't produce such > a document, please also say so. If you have comments on the content of > the document, please hold off on that until it's been adopted, or not > adopted. If it's not adopted, the comments are moot; if it is adopted, > the job of the working group will be to finish it according to the input of > working group participants, which is where your comments would come in. > > We will evaluate consensus on February 25. > > Thanks! > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --047d7bd6b99c64e86b04d5996280 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ted,

think that to do a fair evaluation we'd need to go with = a set of requirements, which currently this document does not include. Eg I= t's assumed that legacy DHCPv4 options are to be supported, but this is= definitely not a universal requirement and in fact a total non requirement= for several operators.

Thus it either needs to scope also set of requirements or those require= ments need to come in from Softwire. Without this, it's hard to see how= a pro/con analysis will prove to be useful.

Regards,
Woj.

On 12 February 2013 01:24, Ted Lemon <T= ed.Lemon@nominum.com> wrote:
https://datatracker.ietf.org/do= c/draft-rajtar-dhc-v4configuration/

The purpose of this draft is to enumerate all the potential solutions to th= is problem, describe their pros and cons, and make a recommendation. =A0 Th= e current state of the draft is the recommendation that most people seemed = to be leaning toward at the end of the meeting in Atlanta, but it's not= binding; if during discussion the working group decides to recommend somet= hing else, the document will be updated to reflect that.

If you think the working group should in fact produce this document, please= say so on the mailing list. =A0 If you think we shouldn't produce such= a document, please also say so. =A0 If you have comments on the content of= the document, please hold off on that until it's been adopted, or not = adopted. =A0 If it's not adopted, the comments are moot; if it is adopt= ed, the job of the working group will be to finish it according to the inpu= t of working group participants, which is where your comments would come in= .

We will evaluate consensus on February 25.

Thanks!

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

--047d7bd6b99c64e86b04d5996280-- From alexandru.petrescu@gmail.com Wed Feb 13 04:23:28 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0DA21F87F5 for ; Wed, 13 Feb 2013 04:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.313 X-Spam-Level: X-Spam-Status: No, score=-10.313 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 5I2r73yGLg1M for ; Wed, 13 Feb 2013 04:23:27 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 138EA21F87F3 for ; Wed, 13 Feb 2013 04:23:26 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r1DCNPYS000449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 13 Feb 2013 13:23:26 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r1DCNPIC013664 for ; Wed, 13 Feb 2013 13:23:25 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r1DCNF7t021508 for ; Wed, 13 Feb 2013 13:23:25 +0100 Message-ID: <511B85B3.8030705@gmail.com> Date: Wed, 13 Feb 2013 13:23:15 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: dhcwg@ietf.org References: <4F5EA754.50403@trans-nt.com> <56269277-D110-4052-A388-E56CD23DD8B5@nominum.com> <4F5EE6B9.4050704@trans-nt.com> <44C2AE51-D4AD-49CA-BA84-B4B6447823D4@nominum.com> <4F5F953C.5000504@trans-nt.com> <5115BCAB.9050104@trans-nt.com> <8D23D4052ABE7A4490E77B1A012B63074748554A@mbx-01.win.nominum.com> <5116E9A7.2010304@trans-nt.com> <511AA538.2000902@trans-nt.com> In-Reply-To: <511AA538.2000902@trans-nt.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] IEEE 802.11ai and DHCP X-BeenThere: dhcwg@ietf.org 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, 13 Feb 2013 12:23:28 -0000 Le 12/02/2013 21:25, Hiroki Nakano a écrit : > Dear all, > > I'm participating in IEEE 802.11 WG TGai task group which is for > FILS (Fast Initiali Link Setup). They are working for speeding up of > 802.11 process and trying to provide a new framework for higher > layer protocols. > > I'd like to introduce the overview of prospective 802.11ai > specification and discuss usages of DHCP on it with DHC WG people in > March. The followings are a brief introduction. > > TGai supposes Wireless LAN is used in very crowded envirionment such > as railway stations in a giant metropolis. TGai also supposes moving > hosts through the front of Access Points. In these cases, it is > effective to reduce management frames of 802.11, especially frames > for probing APs, authentication and association. The current > framework takes a few seconds to set up network connectivity before > starting to communicate. The target of TGai is under one second. > > TGai is trying to reduce management frames of 802.11 itself, and in > addition provide framework for higher layers such as IP to send and > receive packets during 802.11 association process. The currently > proposed framework provides "ONE round-trip packet exchange" by > piggybacking on 802.11 Association Request/Response frames. > > My interest is how to fit DHCP to this framework. In case of DHCPv4, > this is achieved by using Rapid Commit Option (RFC4039) and making > some additional and trivial rules. In case of DHCPv6, we have to use > both RA and DHCPv6. In addition, DAD and randomly generated > addresses have to be considered. Share your idea, please. For DHCPv6 - it is possible to use a DHCPv6 single roundtrip to realize complete configuration to the Client (IPv6 address, default route, DNS resolver address). The straightforward means to achieve complete configuration is to use RA _and_ DHCP (because only RA provides the default route), for a total of 6 messages . But the better means (single DHCPv6 roundtrip - 2 messages) is to use DHCPv6 to configure the default route as well, and not use RA: draft-ietf-mif-dhcpv6-route-option-05 "DHCPv6 Route Options" and draft-mouton-mif-dhcpv6-drlo-02.txt "Default Router List Option for DHCPv6 (DRLO)" Alternatively, use RS/RA single exchange (and not DHCPv6), with DNS resolver address: RFC6106 "IPv6 Router Advertisement Options for DNS Configuration" DAD and MLD are two other protocols which may get in the way to fast exchanges. They could be avoided with proper tweaking of specification and implementation. > 802.11 TGai is still going on and its specification is subject to > change, but I'd like to discuss in IETF DHCP issues related to > 802.11ai and arrange I-D according to the progress of TGai task > group. I think it is indeed a good point to discuss such an I-D. Alex > > Regards, > > Hiroki Nakano Trans New Technology, Inc. > > _______________________________________________ dhcwg mailing list > dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg > > From Ted.Lemon@nominum.com Wed Feb 13 05:53:45 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7946E21F86F8 for ; Wed, 13 Feb 2013 05:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 yRvre285Nkeu for ; Wed, 13 Feb 2013 05:53:45 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id E974821F86EF for ; Wed, 13 Feb 2013 05:53:44 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKURua6CUEiSA0AGx5mAAx1HTmzaR8HK45@postini.com; Wed, 13 Feb 2013 05:53:44 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 5B788108002 for ; Wed, 13 Feb 2013 05:53:44 -0800 (PST) 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 4FE8A190043; Wed, 13 Feb 2013 05:53:44 -0800 (PST) (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.0318.004; Wed, 13 Feb 2013 05:53:44 -0800 From: Ted Lemon To: Maglione Roberta Thread-Topic: Call for adoption: draft-rajtar-dhc-v4configuration Thread-Index: AQHOCLdJAJANwYon10iWTDBlj58gmJh3pPhggACyx4A= Date: Wed, 13 Feb 2013 13:53:43 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074748A45A@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE519D1A750C@GRFMBX704BA020.griffon.local> In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE519D1A750C@GRFMBX704BA020.griffon.local> 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: <0F3E58D2514B5340968B3E8729EFCDEF@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" , Capello Alessandro Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 13 Feb 2013 13:53:45 -0000 On Feb 13, 2013, at 6:17 AM, Maglione Roberta wrote: > I do not support the adoption of this draft. > There are scenarios (like IPv6 with PPP) where DHCPv4 is not used at all,= while DHCPv6 is required and already in place for IPv6 connectivity. Addin= g DHCPv4 would require changing the current architecture, while re-using DH= CPv6 in my opinion appears a simpler approach. Using DHCPv6 is one of the three options described in the draft. If you d= isagree with the current stated conclusions of the draft, that's a separate= issue; the call for adoption is to address the question of whether the DHC= working group should summarize the issues here and attempt to state a pref= erred solution. Are you saying that the DHC working group should not make= any decision at all about this? From otroan@employees.org Wed Feb 13 05:58:41 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F116321F86FF for ; Wed, 13 Feb 2013 05:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.507 X-Spam-Level: X-Spam-Status: No, score=-10.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 jons+SCZ5Vq4 for ; Wed, 13 Feb 2013 05:58:41 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id BA92521F86EF for ; Wed, 13 Feb 2013 05:58:41 -0800 (PST) Received: from dhcp-lys02-vla252-10-147-116-66.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 3BE375ECB; Wed, 13 Feb 2013 05:58:40 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074748A45A@mbx-01.win.nominum.com> Date: Wed, 13 Feb 2013 14:58:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE519D1A750C@GRFMBX704BA020.griffon.local> <8D23D4052ABE7A4490E77B1A012B63074748A45A@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1499) Cc: "dhcwg@ietf.org WG" , Capello Alessandro Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 13 Feb 2013 13:58:42 -0000 Ted, >> I do not support the adoption of this draft. >> There are scenarios (like IPv6 with PPP) where DHCPv4 is not used at = all, while DHCPv6 is required and already in place for IPv6 = connectivity. Adding DHCPv4 would require changing the current = architecture, while re-using DHCPv6 in my opinion appears a simpler = approach. >=20 > Using DHCPv6 is one of the three options described in the draft. If = you disagree with the current stated conclusions of the draft, that's a = separate issue; the call for adoption is to address the question of = whether the DHC working group should summarize the issues here and = attempt to state a preferred solution. Are you saying that the DHC = working group should not make any decision at all about this? the draft is useful for discussion, although I disagree with the = conclusion. I'm not sure if we ever want to publish this as an RFC, so = I'm happy with keeping it as an individual contribution that we can use = as basis for discussion and choices for the documents that we do = publish. cheers, Ole= From Ted.Lemon@nominum.com Wed Feb 13 06:21:49 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB0B21F86FF for ; Wed, 13 Feb 2013 06:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.577 X-Spam-Level: X-Spam-Status: No, score=-106.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 Bx4v05ce0vYv for ; Wed, 13 Feb 2013 06:21:46 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id DC09321F86FC for ; Wed, 13 Feb 2013 06:21:45 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKURuhebC+g6OmmWp7/cNy++cLqQZU/GvV@postini.com; Wed, 13 Feb 2013 06:21:45 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 83A5D108096 for ; Wed, 13 Feb 2013 06:21:45 -0800 (PST) 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 7BE0A190043; Wed, 13 Feb 2013 06:21:45 -0800 (PST) (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.0318.004; Wed, 13 Feb 2013 06:21:45 -0800 From: Ted Lemon To: Ole Troan Thread-Topic: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration Thread-Index: AQHOCLdJAJANwYon10iWTDBlj58gmJh3pPhggACyx4CAAAFgAIAABnQA Date: Wed, 13 Feb 2013 14:21:44 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074748A6BA@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE519D1A750C@GRFMBX704BA020.griffon.local> <8D23D4052ABE7A4490E77B1A012B63074748A45A@mbx-01.win.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="us-ascii" Content-ID: <57B9080695BA1D4BBCA7D5149CEF491C@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" , Capello Alessandro Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 13 Feb 2013 14:21:49 -0000 On Feb 13, 2013, at 8:58 AM, Ole Troan wrote: > the draft is useful for discussion, although I disagree with the conclusi= on. I'm not sure if we ever want to publish this as an RFC, so I'm happy wi= th keeping it as an individual contribution that we can use as basis for di= scussion and choices for the documents that we do publish. Okay, fair enough. However, the purpose of doing the document _is_ to pub= lish it as an RFC, so that the working group can have stated an opinion on = how we would like to see this problem solved. Right now we have a problem= moving forward with any proposal because the working group's preferences o= n the question of how to configure IPv4 on an IPv6 network are not known or= clearly stated, even though the working group has on several occasions com= municated to other working groups, e.g. softwires, what we think the right = thing is. So until we adopt a draft like this and advance it to RFC, we are going to = continue having to deal with this question over and over again. This is w= hy I want to see it adopted, and support adopting it. From mellon@fugue.com Wed Feb 13 06:37:03 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E88B21F870E for ; Wed, 13 Feb 2013 06:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4MzwGIEJKdb for ; Wed, 13 Feb 2013 06:37:01 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id A21DD21F8778 for ; Wed, 13 Feb 2013 06:37:01 -0800 (PST) Received: from kali-9.home.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id BD2A92380867; Wed, 13 Feb 2013 09:36:30 -0500 (EST) From: Ted Lemon Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Feb 2013 09:36:28 -0500 Message-Id: <7C16858B-EEC2-422A-A46F-692788948204@fugue.com> To: "dhcwg@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: " Chairs" Subject: [dhcwg] Call for agenda items for DHC working group meeting in Orlando X-BeenThere: dhcwg@ietf.org 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, 13 Feb 2013 14:37:03 -0000 Folks, it's that time again. If you have anything you'd like to = present in Orlando, please send agenda requests to dhc-chairs@ietf.org. = The meeting is Thursday afternoon, and we have a two-hour slot. Does anybody want us to set up Meetecho? This would allow some degree = of online participation for working group members who cannot get to = Orlando. From roberta.maglione@telecomitalia.it Wed Feb 13 06:37:40 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C7521F8790 for ; Wed, 13 Feb 2013 06:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 Tjw1-TLmhp+7 for ; Wed, 13 Feb 2013 06:37:39 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 87E6B21F8786 for ; Wed, 13 Feb 2013 06:37:39 -0800 (PST) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 13 Feb 2013 15:37:38 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Wed, 13 Feb 2013 15:37:37 +0100 From: Maglione Roberta To: 'Ted Lemon' Date: Wed, 13 Feb 2013 15:37:37 +0100 Thread-Topic: Call for adoption: draft-rajtar-dhc-v4configuration Thread-Index: AQHOCLdJAJANwYon10iWTDBlj58gmJh3pPhggACyx4D//4LzsA== Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE519D1A7513@GRFMBX704BA020.griffon.local> References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE519D1A750C@GRFMBX704BA020.griffon.local> <8D23D4052ABE7A4490E77B1A012B63074748A45A@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074748A45A@mbx-01.win.nominum.com> 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 Cc: "dhcwg@ietf.org WG" , Capello Alessandro Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 13 Feb 2013 14:37:40 -0000 Hi Ted, I understand that DHCPv6 is one of the options, but I disagree with curre= nt stated conclusions of the draft. I agree with Ole that this draft could be useful for summarizing the discus= sion, but in my opinion the dhc working group should not work alone to solv= e this problem, softwire WG should be involved in this discussion. Regards, Roberta -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Wednesday, February 13, 2013 2:54 PM To: Maglione Roberta Cc: dhcwg@ietf.org WG; Capello Alessandro Subject: Re: Call for adoption: draft-rajtar-dhc-v4configuration On Feb 13, 2013, at 6:17 AM, Maglione Roberta wrote: > I do not support the adoption of this draft. > There are scenarios (like IPv6 with PPP) where DHCPv4 is not used at all,= while DHCPv6 is required and already in place for IPv6 connectivity. Addin= g DHCPv4 would require changing the current architecture, while re-using DH= CPv6 in my opinion appears a simpler approach. Using DHCPv6 is one of the three options described in the draft. If you d= isagree with the current stated conclusions of the draft, that's a separate= issue; the call for adoption is to address the question of whether the DHC= working group should summarize the issues here and attempt to state a pref= erred solution. Are you saying that the DHC working group should not make= any decision at all about this? 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 Ted.Lemon@nominum.com Wed Feb 13 06:47:57 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2F421F875C for ; Wed, 13 Feb 2013 06:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.577 X-Spam-Level: X-Spam-Status: No, score=-106.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 bfn3lP8RZjAX for ; Wed, 13 Feb 2013 06:47:56 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id DAF7021F871D for ; Wed, 13 Feb 2013 06:47:55 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKURunmzDHnbx3mOFiPc6+zI/IS8esmctR@postini.com; Wed, 13 Feb 2013 06:47:55 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 741CE1B8436 for ; Wed, 13 Feb 2013 06:47:55 -0800 (PST) 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 6B1C0190043; Wed, 13 Feb 2013 06:47:55 -0800 (PST) (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.0318.004; Wed, 13 Feb 2013 06:47:49 -0800 From: Ted Lemon To: Maglione Roberta Thread-Topic: Call for adoption: draft-rajtar-dhc-v4configuration Thread-Index: AQHOCLdJAJANwYon10iWTDBlj58gmJh3pPhggACyx4D//4LzsIAAjCkA Date: Wed, 13 Feb 2013 14:47:49 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074748A84D@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE519D1A750C@GRFMBX704BA020.griffon.local> <8D23D4052ABE7A4490E77B1A012B63074748A45A@mbx-01.win.nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE519D1A7513@GRFMBX704BA020.griffon.local> In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE519D1A7513@GRFMBX704BA020.griffon.local> 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: <2728B9630D253C4DA99F1E7C603CCD17@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 13 Feb 2013 14:47:57 -0000 On Feb 13, 2013, at 9:37 AM, Maglione Roberta wrote: > I understand that DHCPv6 is one of the options, but I disagree with curr= ent stated conclusions of the draft. > I agree with Ole that this draft could be useful for summarizing the disc= ussion, but in my opinion the dhc working group should not work alone to so= lve this problem, softwire WG should be involved in this discussion. Softwire isn't chartered to define DHCP protocol extensions, so they can't = do this work. If softwire participants are interested in directing the di= scussion, they need to come to the DHC working group to do it. We will in= fact be discussing this document in the softwire meeting on Monday, but th= e work has to happen here, and has to be discussed here. This document happens to be motivated by the softwires question at the mome= nt, but the overall question of how to configure IPv4 hosts on an IPv6-only= or dual-stack network is general=97the working group has considered the qu= estion with respect to the work of a number of different working groups in = the past. If you think that DHCPv6 should be used to configure IPv4 hosts, you should= support adopting this document and make your case in the working group. = The document is not cast in concrete, and as I said in the call for adoptio= n, supporting adoption does not mean that you agree with the current conclu= sions of the document. The current document simply concludes with what seemed to be the consensus = at the end of the in-person meeting in Atlanta. If that is not the real c= onsensus of the working group, which is quite possible, that fact will emer= ge as a result of the working group working on the document. From otroan@employees.org Wed Feb 13 06:58:17 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA7221F873B for ; Wed, 13 Feb 2013 06:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.511 X-Spam-Level: X-Spam-Status: No, score=-10.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 m6tbM7NCwpgi for ; Wed, 13 Feb 2013 06:58:17 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE7021F85DF for ; Wed, 13 Feb 2013 06:58:17 -0800 (PST) Received: from dhcp-lys02-vla252-10-147-116-66.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 71E045E5C; Wed, 13 Feb 2013 06:58:16 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074748A84D@mbx-01.win.nominum.com> Date: Wed, 13 Feb 2013 15:58:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE519D1A750C@GRFMBX704BA020.griffon.local> <8D23D4052ABE7A4490E77B1A012B63074748A45A@mbx-01.win.nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE519D1A7513@GRFMBX704BA020.griffon.local> <8D23D4052ABE7A4490E77B1A012B63074748A84D@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1499) Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 13 Feb 2013 14:58:18 -0000 Ted, >> I understand that DHCPv6 is one of the options, but I disagree with = current stated conclusions of the draft. >> I agree with Ole that this draft could be useful for summarizing the = discussion, but in my opinion the dhc working group should not work = alone to solve this problem, softwire WG should be involved in this = discussion. >=20 > Softwire isn't chartered to define DHCP protocol extensions, so they = can't do this work. If softwire participants are interested in = directing the discussion, they need to come to the DHC working group to = do it. We will in fact be discussing this document in the softwire = meeting on Monday, but the work has to happen here, and has to be = discussed here. >=20 > This document happens to be motivated by the softwires question at the = moment, but the overall question of how to configure IPv4 hosts on an = IPv6-only or dual-stack network is general=97the working group has = considered the question with respect to the work of a number of = different working groups in the past. >=20 > If you think that DHCPv6 should be used to configure IPv4 hosts, you = should support adopting this document and make your case in the working = group. The document is not cast in concrete, and as I said in the call = for adoption, supporting adoption does not mean that you agree with the = current conclusions of the document. the softwire solutions are largely concerned about configuring routers, = not hosts. > The current document simply concludes with what seemed to be the = consensus at the end of the in-person meeting in Atlanta. If that is = not the real consensus of the working group, which is quite possible, = that fact will emerge as a result of the working group working on the = document. that wasn't my impression when I left the meeting. unless you don't = include MAP provisioning in that statement? my recollection was that MAP used the combination of meta information to = deduce its IPv4 address from the IPv6 address was perfectly fine in = DHCPv6. provisioning a normal IPv4 address on top of a vanilla point to = point tunnel I agree with is DHCPv4. problem comes when you want to provision A+P. do you want to replicate = very similar options between DHCPv6 and DHCPv4. the unified CPE draft tried to come up with a single provisioning = scheme. that draft uses DHCPv6 I thought. (http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-02) cheers, Ole= From wdec.ietf@gmail.com Wed Feb 13 07:38:55 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA9D21F8888 for ; Wed, 13 Feb 2013 07:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.366 X-Spam-Level: X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, 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 wliePZYAuU4v for ; Wed, 13 Feb 2013 07:38:54 -0800 (PST) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBA221F887F for ; Wed, 13 Feb 2013 07:38:54 -0800 (PST) Received: by mail-qa0-f43.google.com with SMTP id dx4so2200925qab.9 for ; Wed, 13 Feb 2013 07:38:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=qHONGJ+x2lPUHo6TWf+rmGXDy8qcHCaLneDjO8iYQwQ=; b=rJTIwiLhvWEeMRkvbpqXEBosrXbkCthW/hSLaai6RO2KIz+UPs8ket0Tq9zpZmAdIZ lSrQEnzR+NH4wLBft1svc4/73PPzUagTslWdMKIK4MysH7YSOAG2wYcG2LUItnX3JNMm WB/f1re3gZbSIQPtcnvsExGZh64sKmRXgDa/57uBShDk/nbjy5GhrhnZg3CUx1CD4mzs yNSSVaNruHg/UjGS/cbTt+P8fxijT9Gmqfr4/wz+8G91OeuMwweURwZkVQ5JdhAbXwAr As1w64e0Sx7dbaIriqg7xSMKIbNM1Oq/VOjwtuckpIDfkpuox/hARy2w3UlN5N8N6+a1 3QXg== MIME-Version: 1.0 X-Received: by 10.224.58.147 with SMTP id g19mr8697087qah.22.1360769933666; Wed, 13 Feb 2013 07:38:53 -0800 (PST) Received: by 10.49.75.33 with HTTP; Wed, 13 Feb 2013 07:38:53 -0800 (PST) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074748A6BA@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE519D1A750C@GRFMBX704BA020.griffon.local> <8D23D4052ABE7A4490E77B1A012B63074748A45A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748A6BA@mbx-01.win.nominum.com> Date: Wed, 13 Feb 2013 16:38:53 +0100 Message-ID: From: Wojciech Dec To: Ted Lemon Content-Type: multipart/alternative; boundary=20cf3074d248846a3104d59cf0fc Cc: "dhcwg@ietf.org WG" , Capello Alessandro Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 13 Feb 2013 15:38:55 -0000 --20cf3074d248846a3104d59cf0fc Content-Type: text/plain; charset=ISO-8859-1 Ted, I am in favour of the DHCP WG working with softwires to capture/define the requirements and performing a subsequent DHCP analysis - so yes to adopting that kind of draft. The scope of the proposed draft currently misses out on that, or rather assumes an implicit set of requirements. One of the points just expressed on this thread by Roberta is that for some operators NOT having to use/deploy DHCPv4 is an actual requirement. For others it may well be so. An analysis draft needs to capture these points and their rationale, before the anlaysis. Regards, Woj. On 13 February 2013 15:21, Ted Lemon wrote: > On Feb 13, 2013, at 8:58 AM, Ole Troan > wrote: > > the draft is useful for discussion, although I disagree with the > conclusion. I'm not sure if we ever want to publish this as an RFC, so I'm > happy with keeping it as an individual contribution that we can use as > basis for discussion and choices for the documents that we do publish. > > Okay, fair enough. However, the purpose of doing the document _is_ to > publish it as an RFC, so that the working group can have stated an opinion > on how we would like to see this problem solved. Right now we have a > problem moving forward with any proposal because the working group's > preferences on the question of how to configure IPv4 on an IPv6 network are > not known or clearly stated, even though the working group has on several > occasions communicated to other working groups, e.g. softwires, what we > think the right thing is. > > So until we adopt a draft like this and advance it to RFC, we are going to > continue having to deal with this question over and over again. This is > why I want to see it adopted, and support adopting it. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --20cf3074d248846a3104d59cf0fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ted,

I am in favour of the DHCP WG working with softwires to capture= /define the requirements and performing a subsequent DHCP analysis - so yes= to adopting that kind of draft. The scope of the proposed draft currently = misses out on that, or rather assumes an implicit set of requirements.

One of the points just expressed on this thread by Roberta is that for = some operators NOT having to use/deploy DHCPv4 is an actual requirement. Fo= r others it may well be so. An analysis draft needs to capture these points= and their rationale, before the anlaysis.

Regards,
Woj.


On 13 February 2= 013 15:21, 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 Feb 13, 2013, at 8:58 AM, Ole Troan <otroan@employees.org>
=A0wrote:
> the draft is useful for discussion, although I disagree with the concl= usion. I'm not sure if we ever want to publish this as an RFC, so I'= ;m happy with keeping it as an individual contribution that we can use as b= asis for discussion and choices for the documents that we do publish.

Okay, fair enough. =A0 However, the purpose of doing the document _is= _ to publish it as an RFC, so that the working group can have stated an opi= nion on how we would like to see this problem solved. =A0 Right now we have= a problem moving forward with any proposal because the working group's= preferences on the question of how to configure IPv4 on an IPv6 network ar= e not known or clearly stated, even though the working group has on several= occasions communicated to other working groups, e.g. softwires, what we th= ink the right thing is.

So until we adopt a draft like this and advance it to RFC, we are going to = continue having to deal with this question over and over again. =A0 This is= why I want to see it adopted, and support adopting it.

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

--20cf3074d248846a3104d59cf0fc-- From Ted.Lemon@nominum.com Wed Feb 13 08:29:51 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC04621F891C for ; Wed, 13 Feb 2013 08:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1Djqa0sF-if for ; Wed, 13 Feb 2013 08:29:51 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6B98121F88E5 for ; Wed, 13 Feb 2013 08:29:48 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKURu/fBsYiDwcyJ/1vu1r3bxAarGbfjM6@postini.com; Wed, 13 Feb 2013 08:29:51 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1E8141080A1 for ; Wed, 13 Feb 2013 08:29:48 -0800 (PST) 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 12BC8190043; Wed, 13 Feb 2013 08:29:48 -0800 (PST) (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.0318.004; Wed, 13 Feb 2013 08:29:42 -0800 From: Ted Lemon To: Wojciech Dec Thread-Topic: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration Thread-Index: AQHOCLdJAJANwYon10iWTDBlj58gmJh3pPhggACyx4CAAAFgAIAABnQAgAAVjoCAAA4xAA== Date: Wed, 13 Feb 2013 16:29:41 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074748ACB3@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE519D1A750C@GRFMBX704BA020.griffon.local> <8D23D4052ABE7A4490E77B1A012B63074748A45A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748A6BA@mbx-01.win.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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" , Capello Alessandro Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 13 Feb 2013 16:29:52 -0000 On Feb 13, 2013, at 10:38 AM, Wojciech Dec wrote: > One of the points just expressed on this thread by Roberta is that for so= me operators NOT having to use/deploy DHCPv4 is an actual requirement. For = others it may well be so. An analysis draft needs to capture these points a= nd their rationale, before the anlaysis. Not having to deploy a protocol can't be a requirement. It can certainly = be a stated preference, and that preference can influence the determination= of consensus, but it's a preference, not a requirement, because there is n= o technical reason for it. From sunqi.thu@gmail.com Wed Feb 13 08:31:57 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E56221F8A64 for ; Wed, 13 Feb 2013 08:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aMZKuEQu-ro for ; Wed, 13 Feb 2013 08:31:56 -0800 (PST) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id C351821F895B for ; Wed, 13 Feb 2013 08:31:49 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id fa10so794657pad.27 for ; Wed, 13 Feb 2013 08:31:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=1EWNzt1JK+zNWzvZNdyNzA+k5d+5ng9L/jXfEdkGMCc=; b=bm3Vbv9xTuYuwCBkNGHbl7SzDlEz/6ISGffChhE2mDkujMGZh41tC1bIWkUjlnXmBz 4/i/Q5WBmsc/epGIHW9gLJ8ApU2t3va+stzYJAgmJ0Md4ISAp+486uQOd5bnNaORSUOT lMNuLuhgJu4yNRHohSZxOG014NAKyOMLIJldNKcZSWWESX79BfpnxNkhk3GXCHk2ckqR gk3QIRnCNY9zv5A6EUx6FhmAvo5wkkwuu+5IRdGutQL82KLhzbP78Pxo/zQWC3vFq0VE dzRXGRyp7kY2m5tI/jW4FZOi/7u5Anayx7mAPt0ZvzPqikJD9M29xDBGPdGmLTFKpFK+ wLQw== X-Received: by 10.66.75.136 with SMTP id c8mr65699953paw.25.1360773109119; Wed, 13 Feb 2013 08:31:49 -0800 (PST) Received: from [192.168.0.102] ([27.194.229.3]) by mx.google.com with ESMTPS id a4sm84771856paw.21.2013.02.13.08.31.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Feb 2013 08:31:47 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> Date: Thu, 14 Feb 2013 00:31:40 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0C7D871A-D673-407A-B717-C09F4945B667@gmail.com> References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 13 Feb 2013 16:31:57 -0000 Dear all, I'm in favor of adopting the doc as a WG item.=20 IMHO, it is the DHC WG's work to summarize the methods of configuring = IPv4 resources. This doc will give explanations on why/why not IPv4 = resources are configured this way over IPv6 network in transition = period. I also support the current conclusion. It does not require modification = of DHCPv6 protocol for transition by using DHCPv4o6 for IPv4 resources = assignment. Once the Internet goes through the transition period, the = modifications of DHCPv4 protocol will be abandoned with IPv4. No side = effect on the development of IPv6. Best Regards! Qi Sun On 2013-2-12, at =E4=B8=8A=E5=8D=888:24, Ted Lemon wrote: > At the IETF meeting in Atlanta, we ended the session with a long = discussion about how to solve the problem of configuring MAP-E and = lw4over6 IPv4 stacks; several possibilities were presented, and we = decided that we would write a draft summarizing these possibilities so = that the working group could state a preference. >=20 > Time went on, and none of the people who volunteered actually did = anything, so a couple of weeks ago Branimir Rajtar and Ian Farrer = offered to write it up based on the notes from the last meeting. They = have done so, and submitted a -00 draft: = https://datatracker.ietf.org/doc/draft-rajtar-dhc-v4configuration/ >=20 > The purpose of this draft is to enumerate all the potential solutions = to this problem, describe their pros and cons, and make a = recommendation. The current state of the draft is the recommendation = that most people seemed to be leaning toward at the end of the meeting = in Atlanta, but it's not binding; if during discussion the working group = decides to recommend something else, the document will be updated to = reflect that. >=20 > If you think the working group should in fact produce this document, = please say so on the mailing list. If you think we shouldn't produce = such a document, please also say so. If you have comments on the = content of the document, please hold off on that until it's been = adopted, or not adopted. If it's not adopted, the comments are moot; = if it is adopted, the job of the working group will be to finish it = according to the input of working group participants, which is where = your comments would come in. >=20 > We will evaluate consensus on February 25. >=20 > Thanks! >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From sunqi.thu@gmail.com Wed Feb 13 08:48:20 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F4321F8996 for ; Wed, 13 Feb 2013 08:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdAZUTrV44lH for ; Wed, 13 Feb 2013 08:48:20 -0800 (PST) Received: from mail-da0-f46.google.com (mail-da0-f46.google.com [209.85.210.46]) by ietfa.amsl.com (Postfix) with ESMTP id 832C321F8770 for ; Wed, 13 Feb 2013 08:48:19 -0800 (PST) Received: by mail-da0-f46.google.com with SMTP id p5so643776dak.5 for ; Wed, 13 Feb 2013 08:48:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=g4WScAIWSvvfhOUAnEcVaDyIxAEsfkzY2hqPE2qp4FE=; b=woYS/1hIq0+0OwuTJzKBnJW5Ty9uMZmA3dcvtKXSGEFAVhgzvRRxqGpGo6KVXyBqrb Uv38PAXbFw5M7VpKsQnItaVit0Jf/zZtB1SWNu3MLOO2ejsZ4lvFm+aA0xqELYsVIP2o l7o5H4FwhtQMF2tS717J0lPX5O+8uVxZF4/gwzEUmIDhk+4LQpLgKfDYD4ihcaXMetxw 3WVZCxpub4QxYtjzlXmWFXSJ47pExsHY6QIqMcgAfdQAqcFgmYcM+EAuoO7ghxZLW2xL Ef93+AN4lUNOLf8jToRWJRDlg48tiBmdFU5mYjZX96M5Lmub1GF56mTKH/AycHrCRwA8 L9nQ== X-Received: by 10.66.82.200 with SMTP id k8mr65745500pay.56.1360774098747; Wed, 13 Feb 2013 08:48:18 -0800 (PST) Received: from [192.168.0.102] ([27.194.229.3]) by mx.google.com with ESMTPS id o1sm7903401pax.2.2013.02.13.08.48.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Feb 2013 08:48:17 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: Date: Thu, 14 Feb 2013 00:48:10 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <15515E2A-ED99-470D-B6ED-41BD67B145A0@gmail.com> References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE519D1A750C@GRFMBX704BA020.griffon.local> <8D23D4052ABE7A4490E77B1A012B63074748A45A@mbx-01.win.nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE519D1A7513@GRFMBX704BA020.griffon.local> <8D23D4052ABE7A4490E77B1A012B63074748A84D@mbx-01.win.nominum.com> To: Ole Troan X-Mailer: Apple Mail (2.1084) Cc: "dhcwg@ietf.org WG" , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 13 Feb 2013 16:48:21 -0000 Hi Ole, > the unified CPE draft tried to come up with a single provisioning = scheme. that draft uses DHCPv6 I thought. > (http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-02) [Qi] This is not what I read from the unified CPE draft. There is a = DISCUSSION NOTE says that the customer side DHCP based provisioning = method (DHCPv4/v6) will be updated to reflect the consensus from DHC WG. = IMHO the draft-rajtar-* is doing the job. Best Regards! Qi Sun On 2013-2-13, at =E4=B8=8B=E5=8D=8810:58, Ole Troan wrote: > Ted, >=20 >>> I understand that DHCPv6 is one of the options, but I disagree with = current stated conclusions of the draft. >>> I agree with Ole that this draft could be useful for summarizing the = discussion, but in my opinion the dhc working group should not work = alone to solve this problem, softwire WG should be involved in this = discussion. >>=20 >> Softwire isn't chartered to define DHCP protocol extensions, so they = can't do this work. If softwire participants are interested in = directing the discussion, they need to come to the DHC working group to = do it. We will in fact be discussing this document in the softwire = meeting on Monday, but the work has to happen here, and has to be = discussed here. >>=20 >> This document happens to be motivated by the softwires question at = the moment, but the overall question of how to configure IPv4 hosts on = an IPv6-only or dual-stack network is general=E2=80=94the working group = has considered the question with respect to the work of a number of = different working groups in the past. >>=20 >> If you think that DHCPv6 should be used to configure IPv4 hosts, you = should support adopting this document and make your case in the working = group. The document is not cast in concrete, and as I said in the call = for adoption, supporting adoption does not mean that you agree with the = current conclusions of the document. >=20 > the softwire solutions are largely concerned about configuring = routers, not hosts. >=20 >> The current document simply concludes with what seemed to be the = consensus at the end of the in-person meeting in Atlanta. If that is = not the real consensus of the working group, which is quite possible, = that fact will emerge as a result of the working group working on the = document. >=20 > that wasn't my impression when I left the meeting. unless you don't = include MAP provisioning in that statement? > my recollection was that MAP used the combination of meta information = to deduce its IPv4 address from the IPv6 address was perfectly fine in = DHCPv6. provisioning a normal IPv4 address on top of a vanilla point to = point tunnel I agree with is DHCPv4. > problem comes when you want to provision A+P. do you want to replicate = very similar options between DHCPv6 and DHCPv4. > the unified CPE draft tried to come up with a single provisioning = scheme. that draft uses DHCPv6 I thought. > (http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-02) >=20 > cheers, > Ole > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From mohamed.boucadair@orange.com Wed Feb 13 09:31:48 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC09D21F8678 for ; Wed, 13 Feb 2013 09:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvkA+F9075tJ for ; Wed, 13 Feb 2013 09:31:48 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id D462621F85C0 for ; Wed, 13 Feb 2013 09:31:47 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id CC32E18C3CB; Wed, 13 Feb 2013 18:31:46 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id AD4BB35C058; Wed, 13 Feb 2013 18:31:46 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 13 Feb 2013 18:31:46 +0100 From: To: Ted Lemon , Wojciech Dec Date: Wed, 13 Feb 2013 18:31:45 +0100 Thread-Topic: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration Thread-Index: AQHOCLdJAJANwYon10iWTDBlj58gmJh3pPhggACyx4CAAAFgAIAABnQAgAAVjoCAAA4xAP//ifpQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EAFB56470@PUEXCB1B.nanterre.francetelecom.fr> References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE519D1A750C@GRFMBX704BA020.griffon.local> <8D23D4052ABE7A4490E77B1A012B63074748A45A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748A6BA@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748ACB3@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074748ACB3@mbx-01.win.nominum.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.31.121227 Cc: "dhcwg@ietf.org WG" , Capello Alessandro Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 13 Feb 2013 17:31:48 -0000 Hi Ted, I disagree. Not deploying a protocol is an operational requirement not a pr= eference. There are other organizational issues to take into account (think= about skills...).=20 Cheers, Med >-----Message d'origine----- >De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De=20 >la part de Ted Lemon >Envoy=E9 : mercredi 13 f=E9vrier 2013 17:30 >=C0 : Wojciech Dec >Cc : dhcwg@ietf.org WG; Capello Alessandro >Objet : Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration > >On Feb 13, 2013, at 10:38 AM, Wojciech Dec wrote: >> One of the points just expressed on this thread by Roberta=20 >is that for some operators NOT having to use/deploy DHCPv4 is=20 >an actual requirement. For others it may well be so. An=20 >analysis draft needs to capture these points and their=20 >rationale, before the anlaysis. > >Not having to deploy a protocol can't be a requirement. It=20 >can certainly be a stated preference, and that preference can=20 >influence the determination of consensus, but it's a=20 >preference, not a requirement, because there is no technical=20 >reason for it. > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg >= From wdec.ietf@gmail.com Wed Feb 13 10:17:59 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC4721F8AAC for ; Wed, 13 Feb 2013 10:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPxsRVn52s15 for ; Wed, 13 Feb 2013 10:17:59 -0800 (PST) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id CFF5521F8AA3 for ; Wed, 13 Feb 2013 10:17:58 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id j8so684233qah.0 for ; Wed, 13 Feb 2013 10:17:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Ui5MRolP6B+0lFUP3Rp7k90bucULVSJLBSLPXCMPpcU=; b=1JlrzJ1Y1P8fwrRLjoGPm2LtKfdWe4SXokNQpgCWrcsJ9W2d0wjhQZD4HkYFRIhg0w GMGpyfAhmUQyIoYwyIN0lQ4cDhZK3EoqCvKUW+P1GXvBXzl3ebmEmt0Bx7O7wrMy8M39 7kzAK343h0ETl8k3bAbIBFKDnaS4n7+T9roMnb2h+9B82T3UGJtvy+esZ1ykZJjDOWJE WfLtgtpQgcSBRgyG1wIX3+YxnxFvSPMSIFN8rCfyYwCIA4oH4YWMY5XBnyAqe80++p2h wtRBVkAmw97/FsOyxBvu/Uxg85iymrX3P2TNPL2pVu4K459fTUYcZHvW1T3OAWjsWfUP 3adw== MIME-Version: 1.0 X-Received: by 10.49.96.234 with SMTP id dv10mr9903874qeb.48.1360779478232; Wed, 13 Feb 2013 10:17:58 -0800 (PST) Received: by 10.49.75.33 with HTTP; Wed, 13 Feb 2013 10:17:58 -0800 (PST) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074748ACB3@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE519D1A750C@GRFMBX704BA020.griffon.local> <8D23D4052ABE7A4490E77B1A012B63074748A45A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748A6BA@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748ACB3@mbx-01.win.nominum.com> Date: Wed, 13 Feb 2013 19:17:58 +0100 Message-ID: From: Wojciech Dec To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7bb0464a6aefec04d59f29f5 Cc: "dhcwg@ietf.org WG" , Capello Alessandro Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 13 Feb 2013 18:17:59 -0000 X-List-Received-Date: Wed, 13 Feb 2013 18:17:59 -0000 --047d7bb0464a6aefec04d59f29f5 Content-Type: text/plain; charset=ISO-8859-1 On 13 February 2013 17:29, Ted Lemon wrote: > On Feb 13, 2013, at 10:38 AM, Wojciech Dec wrote: > > One of the points just expressed on this thread by Roberta is that for > some operators NOT having to use/deploy DHCPv4 is an actual requirement. > For others it may well be so. An analysis draft needs to capture these > points and their rationale, before the anlaysis. > > Not having to deploy a protocol can't be a requirement. It can certainly > be a stated preference, and that preference can influence the determination > of consensus, but it's a preference, not a requirement, because there is no > technical reason for it. > It's not having to deploy infrastructure (at cost) to support a protocol to solve a specific point problem that can be solved through other means. It's thus directly linked to the operational bottom line of operators and one would say that it's where technology requirments stem from. regards, Woj. --047d7bb0464a6aefec04d59f29f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 13 February 2013 17:29, Ted Lemon <Ted.Lemon@nominum.com> wrote:
On Feb 13, 2013, at 10:38 AM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
> One of the points just expressed on this thread by Roberta is that for= some operators NOT having to use/deploy DHCPv4 is an actual requirement. F= or others it may well be so. An analysis draft needs to capture these point= s and their rationale, before the anlaysis.

Not having to deploy a protocol can't be a requirement. =A0 It ca= n certainly be a stated preference, and that preference can influence the d= etermination of consensus, but it's a preference, not a requirement, be= cause there is no technical reason for it.

It's not having to deploy infrastructure (at cost= ) to support a protocol to solve a specific point problem that can be solve= d through other means. It's thus directly linked to the operational bot= tom line of operators and one would say that it's where technology requ= irments stem from.

regards,
Woj.

--047d7bb0464a6aefec04d59f29f5-- From Ted.Lemon@nominum.com Wed Feb 13 10:25:29 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E9D21F886E for ; Wed, 13 Feb 2013 10:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pC+Mcqr08S8a for ; Wed, 13 Feb 2013 10:25:28 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id A892621F8821 for ; Wed, 13 Feb 2013 10:25:28 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKURvamMXuE6VFt/kCvdM74XMcAFxmxLEz@postini.com; Wed, 13 Feb 2013 10:25:28 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 26E6212800D for ; Wed, 13 Feb 2013 10:25:28 -0800 (PST) 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 1CAA4190043; Wed, 13 Feb 2013 10:25:28 -0800 (PST) (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.0318.004; Wed, 13 Feb 2013 10:25:28 -0800 From: Ted Lemon To: Wojciech Dec Thread-Topic: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration Thread-Index: AQHOCLdJAJANwYon10iWTDBlj58gmJh3pPhggACyx4CAAAFgAIAABnQAgAAVjoCAAA4xAIAAHkIAgAACF4A= Date: Wed, 13 Feb 2013 18:25:27 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074748B26E@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE519D1A750C@GRFMBX704BA020.griffon.local> <8D23D4052ABE7A4490E77B1A012B63074748A45A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748A6BA@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748ACB3@mbx-01.win.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: <2F75C6B2AD1B6A4CBBFD7E674F862441@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" , Capello Alessandro Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 13 Feb 2013 18:25:29 -0000 On Feb 13, 2013, at 1:17 PM, Wojciech Dec wrote: > It's not having to deploy infrastructure (at cost) to support a protocol = to solve a specific point problem that can be solved through other means. I= t's thus directly linked to the operational bottom line of operators and on= e would say that it's where technology requirments stem from. Right, this is a preference, not a requirement. More to the point, all th= ree solutions outlined in the draft require zero additional equipment other= than the equipment that runs the DHCPv4 server. It's hard to take this s= eriously as a prohibitive operational expense. This objection was raised in the working group meeting in Atlanta, and I be= lieve it's represented in the document; if not, please send suggested text = to the authors. The working group can weigh it. Or not, if we decide no= t to do this work. But do be aware that if we decide not to do this work, it doesn't mean, de = facto, that softwires gets to make the decision. It means that the dhc wo= rking group doesn't have consensus on what to do, and likely there can be n= o softwires DHCP solution at all. From wdec.ietf@gmail.com Wed Feb 13 11:00:04 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C961F0CE7 for ; Wed, 13 Feb 2013 11:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fgazbescmXK for ; Wed, 13 Feb 2013 11:00:04 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF7D51F0D08 for ; Wed, 13 Feb 2013 11:00:03 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id bv4so2283176qab.3 for ; Wed, 13 Feb 2013 11:00:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=rxKnUcfnPp1r8TdZMRFdpWpu7W+jv8FPORnz4yS/mDg=; b=OJ0z2jXCdR4/L7oAMOZe/UI3ZpP0D6cDBu+sNsm6x2NIAIgd4y76XxhyVKKDdb4TVz 2lMMlw7gKHd/iU0jnj45yB0/tcjMwWvg7DcL+GYjIrR4R9gM/1kFpH2Z1Km1scPVObEj mq1wt1/6V3xu9TRjQ9bRxm2Rgeg4cbU0FF1ahHRdIXP7zciIFT31z/tfLgH3EeshKlnA 0NllUb8UVwog/Q5ZdwjddfjWcN+Rkka4Uq9qj1iXuNZ8KA2Xe2Z3XeevWUfSXEHeyCd/ gcf0Xh3QH38QQtb5m1M5GOnxkfQqiNzexjOlI/W0gN+dq0rCNrOHWRn79Yu0TbBkUc30 DNeQ== MIME-Version: 1.0 X-Received: by 10.229.175.140 with SMTP id ba12mr2152577qcb.13.1360782003382; Wed, 13 Feb 2013 11:00:03 -0800 (PST) Received: by 10.49.75.33 with HTTP; Wed, 13 Feb 2013 11:00:03 -0800 (PST) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074748B26E@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE519D1A750C@GRFMBX704BA020.griffon.local> <8D23D4052ABE7A4490E77B1A012B63074748A45A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748A6BA@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748ACB3@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748B26E@mbx-01.win.nominum.com> Date: Wed, 13 Feb 2013 20:00:03 +0100 Message-ID: From: Wojciech Dec To: Ted Lemon Content-Type: multipart/alternative; boundary=0016e68dce83eda83f04d59fbfbe Cc: "dhcwg@ietf.org WG" , Capello Alessandro Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 13 Feb 2013 19:00:05 -0000 --0016e68dce83eda83f04d59fbfbe Content-Type: text/plain; charset=ISO-8859-1 On 13 February 2013 19:25, Ted Lemon wrote: > On Feb 13, 2013, at 1:17 PM, Wojciech Dec > wrote: > > It's not having to deploy infrastructure (at cost) to support a protocol > to solve a specific point problem that can be solved through other means. > It's thus directly linked to the operational bottom line of operators and > one would say that it's where technology requirments stem from. > > Right, this is a preference, not a requirement. More to the point, all > three solutions outlined in the draft require zero additional equipment > other than the equipment that runs the DHCPv4 server. It's hard to take > this seriously as a prohibitive operational expense. > The server is not a major operational expense, the clients are, along with all the bits needed along the path (relays) to make things work. Put in another way, one would be very hard pressed to justify to a CTO of an existing SP, why he has to go and invest and maintain in technolgy that he can do without for the services the network is meant to offer. Side note: DS-Lite is actually a example where no DHCPv4 is needed > > This objection was raised in the working group meeting in Atlanta, and I > believe it's represented in the document; if not, please send suggested > text to the authors. The working group can weigh it. Or not, if we > decide not to do this work. > There are no requirements as far as I can tell in the document, other than the implicit ones of the authors (not listed). That's why I think its scope needs to be adjusted to cover both requirments and analysis. Before that happens I do not think it should be adopted by the WG, as we'll be churning for ever about the grounds for analysis. > > But do be aware that if we decide not to do this work, it doesn't mean, de > facto, that softwires gets to make the decision. It means that the dhc > working group doesn't have consensus on what to do, and likely there can be > no softwires DHCP solution at all. > > --0016e68dce83eda83f04d59fbfbe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 13 February 2013 19:25, Ted Lemon <Ted.Lemon@nominum.com> wrote:
On Feb 13, 2013, at 1:17 PM, Wojciech Dec <wdec.ietf@gmail.com>
=A0wrote:
> It's not having to deploy infrastructure (at cost) to support a pr= otocol to solve a specific point problem that can be solved through other m= eans. It's thus directly linked to the operational bottom line of opera= tors and one would say that it's where technology requirments stem from= .

Right, this is a preference, not a requirement. =A0 More to the point= , all three solutions outlined in the draft require zero additional equipme= nt other than the equipment that runs the DHCPv4 server. =A0 It's hard = to take this seriously as a prohibitive operational expense.

The server is not a major operational expense, the cl= ients are, along with all the bits needed along the path (relays) to make t= hings work. Put in another way, one would be very hard pressed to justify t= o a CTO of an existing SP, why he has to go and invest and maintain in tech= nolgy that he can do without for the services the network is meant to offer= .

Side note: DS-Lite is actually a example where no DHCPv4 is needed
= =A0

This objection was raised in the working group meeting in Atlanta, and I be= lieve it's represented in the document; if not, please send suggested t= ext to the authors. =A0 The working group can weigh it. =A0 Or not, if we d= ecide not to do this work.

There are no requirements as far as I can tell in the= document, other than the implicit ones of the authors (not listed). That&#= 39;s why I think its scope needs to be adjusted to cover both requirments a= nd analysis. Before that happens I do not think it should be adopted by the= WG, as we'll be churning for ever about the grounds for analysis.

But do be aware that if we decide not to do this work, it doesn't mean,= de facto, that softwires gets to make the decision. =A0 It means that the = dhc working group doesn't have consensus on what to do, and likely ther= e can be no softwires DHCP solution at all.


--0016e68dce83eda83f04d59fbfbe-- From Ted.Lemon@nominum.com Wed Feb 13 12:27:49 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58F221F870C for ; Wed, 13 Feb 2013 12:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OImNINKrKTxQ for ; Wed, 13 Feb 2013 12:27:49 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2892221F870A for ; Wed, 13 Feb 2013 12:27:49 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKURv3RECG/c9RWK/BjCOPpO07xLZLZwk6@postini.com; Wed, 13 Feb 2013 12:27:49 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B5CE9108296 for ; Wed, 13 Feb 2013 12:27:48 -0800 (PST) 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 AB73C190043; Wed, 13 Feb 2013 12:27:48 -0800 (PST) (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.0318.004; Wed, 13 Feb 2013 12:27:42 -0800 From: Ted Lemon To: Wojciech Dec Thread-Topic: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration Thread-Index: AQHOCLdJAJANwYon10iWTDBlj58gmJh3pPhggACyx4CAAAFgAIAABnQAgAAVjoCAAA4xAIAAHkIAgAACF4CAAAmrgIAAGHmA Date: Wed, 13 Feb 2013 20:27:42 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074748B5CB@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE519D1A750C@GRFMBX704BA020.griffon.local> <8D23D4052ABE7A4490E77B1A012B63074748A45A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748A6BA@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748ACB3@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748B26E@mbx-01.win.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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" , Capello Alessandro Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 13 Feb 2013 20:27:49 -0000 On Feb 13, 2013, at 2:00 PM, Wojciech Dec wrote: > The server is not a major operational expense, the clients are, along wit= h all the bits needed along the path (relays) to make things work. Put in a= nother way, one would be very hard pressed to justify to a CTO of an existi= ng SP, why he has to go and invest and maintain in technolgy that he can do= without for the services the network is meant to offer.=20 For heaven's sake, if you're going to criticize the draft, please at least = read it. There are no relays needed=97you already have an IPv6 address, s= o the packet can be unicast and routed directly to the DHCP server, in both= alternatives that use a DHCPv4 server. You have a device with a DHCPv6 c= lient; adding a DHCPv4 client doesn't mean you have to buy another device. > There are no requirements as far as I can tell in the document, other tha= n the implicit ones of the authors (not listed). That's why I think its sco= pe needs to be adjusted to cover both requirments and analysis. Before that= happens I do not think it should be adopted by the WG, as we'll be churnin= g for ever about the grounds for analysis. Woj, the question in the document is, supposing we need to configure an IPv= 4 stack on an IPv6 only network, what is the DHC working group's advice as = to how to do it? This is a DHC document, not a softwire document. What = do you need to know about requirements beyond this, which is expressed in t= he draft? From volz@cisco.com Wed Feb 13 13:21:42 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB9121E8084 for ; Wed, 13 Feb 2013 13:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmChT5VF8yNP for ; Wed, 13 Feb 2013 13:21:41 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9A721E803D for ; Wed, 13 Feb 2013 13:21:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2305; q=dns/txt; s=iport; t=1360790500; x=1362000100; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=hXQDYRGWy+GVYtSYd7s4RJAEEUYUSuLxA+JLJ7ZeQAs=; b=bP6QnYxW1ipOl6KhXRcmcBndzFcbyOaQlaiM93QmWFYWOOXp6QPGp/6G wtQAXp6stP0VRqv/DYUCaWBjyUS/E7hg/c+ErgMWsGZRhUlD0DaCYqsHS fZ/Xsf85Ob1KNJoYpPqkZq/rBWMtONiQ3dLNitCn5sFrNVCw1/hbPuCwP c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJQDHFGtJXHA/2dsb2JhbABFwG8Wc4IfAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAkIAgQBEgiICgy/SJEjYQOXQY82gwaCJw X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; d="scan'208";a="176802708" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 13 Feb 2013 21:21:29 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1DLLTdl018659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Feb 2013 21:21:29 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Wed, 13 Feb 2013 15:21:29 -0600 From: "Bernie Volz (volz)" To: Ted Lemon , "dhcwg@ietf.org WG" Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-08 Thread-Index: AQHOAi8Y6L/mEtMT5UW0fdfJAZ+WqJh4VB9A Date: Wed, 13 Feb 2013 21:21:29 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1846A61A@xmb-rcd-x04.cisco.com> References: <8D23D4052ABE7A4490E77B1A012B63074747BF6B@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074747BF6B@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.65.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 21:21:42 -0000 I support this moving forward. I think my comments were addressed. In my reading, I did notice one minor nit but that may be fixed by RFC Edit= or or in the AUTH-48 review: 4. DHCPv6 RADIUS option The OPTION_RADIUS is a DHCPv6 option used by the DHCPv6 relay agent to carry the authorization information of RADIUS attributes received in the Access-Accept message from the RADIUS serve. I think "serve" should be "server". - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Sunday, February 03, 2013 11:54 AM To: dhcwg@ietf.org WG Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-08 The authors of this draft have asked for a new working group last call. We= had a WGLC in November, and there were substantial and constructive commen= ts, which are incorporated in the new version. The changes can be seen he= re:=20 http://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-dhc-dhcpv6-radius-opt-05.tx= t&url2=3Ddraft-ietf-dhc-dhcpv6-radius-opt-08.txt This diff includes a number of changes that have occurred since the most re= cent last call-there have been several revisions of the draft. If you haven't read the draft, now would be a good time to do so: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-08 If you think the draft is ready to advance, please indicate your support on= the mailing list. If you think it is not ready, please say so as well. = And of course, additional comments are solicited and welcome. We will ev= aluate consensus on or after February 19. P.S. I asked Leaf to remove me as an author of the draft, because I haven't= actually contributed anything substantial to it, and working group chairs = authoring drafts create various procedural problems. If anybody feels tha= t this is inappropriate, please say so. As a working group participant, I= think the draft is a reasonably good idea, but I have no personal stake in= the advancement or non-advancement of the draft-it doesn't actually relate= to work I do outside of IETF, nor does my IETF work depend on it. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From sunqi.thu@gmail.com Wed Feb 13 19:21:25 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986CB21E80CA for ; Wed, 13 Feb 2013 19:21:25 -0800 (PST) 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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-Le7qGSbODN for ; Wed, 13 Feb 2013 19:21:24 -0800 (PST) Received: from mail-da0-f47.google.com (mail-da0-f47.google.com [209.85.210.47]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC4921E8047 for ; Wed, 13 Feb 2013 19:21:24 -0800 (PST) Received: by mail-da0-f47.google.com with SMTP id s35so894585dak.34 for ; Wed, 13 Feb 2013 19:21:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=KAp+opBWnXUDu2ItCdj/u1wYQWqh/v10FkuP1zYcW5w=; b=l5uakuDGaPJQQq/e5lkFHifXyWEII7lQWGuL0KxoyiXjczv84To4KE+7gLkxYMdYnS KuozJ9LLy1qJX5Vpb3Ly18zEG0CT3gPYdurEAciALFPj25g+sRMaFrdBMwTZQIsDEzlE RbEAKZ0bmYIo84j0YqR5xvy22bYsbr6W3uZp+KFvErgH9L0ScNZMqvsS0VV7OOpQg5AU caueB3IDP2A2dNfJOrURpK55sJ0v9O45OQmBg9rIwUKTaQMuBojBhg3Znbl71vhpXqY5 seoj+213XsgW9Dxe/8ABEP+3tfl+ZJzCN1pupQ/2+F1q0o4Dio0I/0qkNfYExvgV2OMH Dh3Q== X-Received: by 10.66.72.233 with SMTP id g9mr70532114pav.29.1360812083901; Wed, 13 Feb 2013 19:21:23 -0800 (PST) Received: from [192.168.0.102] ([27.194.229.3]) by mx.google.com with ESMTPS id t4sm46998913pax.0.2013.02.13.19.21.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Feb 2013 19:21:22 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-3-252781325 From: Qi Sun In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> Date: Thu, 14 Feb 2013 11:21:10 +0800 Message-Id: References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 14 Feb 2013 03:21:25 -0000 --Apple-Mail-3-252781325 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, Here is some analysis on this issue in = draft-ietf-dhc-dhcpv4-over-ipv6-05: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-ipv6-05#appendix-A IMO we can get some valuable input there.=20 Best Regards! Qi Sun On 2013-2-12, at =E4=B8=8A=E5=8D=888:24, Ted Lemon wrote: > At the IETF meeting in Atlanta, we ended the session with a long = discussion about how to solve the problem of configuring MAP-E and = lw4over6 IPv4 stacks; several possibilities were presented, and we = decided that we would write a draft summarizing these possibilities so = that the working group could state a preference. >=20 > Time went on, and none of the people who volunteered actually did = anything, so a couple of weeks ago Branimir Rajtar and Ian Farrer = offered to write it up based on the notes from the last meeting. They = have done so, and submitted a -00 draft: = https://datatracker.ietf.org/doc/draft-rajtar-dhc-v4configuration/ >=20 > The purpose of this draft is to enumerate all the potential solutions = to this problem, describe their pros and cons, and make a = recommendation. The current state of the draft is the recommendation = that most people seemed to be leaning toward at the end of the meeting = in Atlanta, but it's not binding; if during discussion the working group = decides to recommend something else, the document will be updated to = reflect that. >=20 > If you think the working group should in fact produce this document, = please say so on the mailing list. If you think we shouldn't produce = such a document, please also say so. If you have comments on the = content of the document, please hold off on that until it's been = adopted, or not adopted. If it's not adopted, the comments are moot; = if it is adopted, the job of the working group will be to finish it = according to the input of working group participants, which is where = your comments would come in. >=20 > We will evaluate consensus on February 25. >=20 > Thanks! >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --Apple-Mail-3-252781325 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear all,

Here is some analysis on this = issue in draft-ietf-dhc-dhcpv4-over-ipv6-05:

IMO we can get some valuable = input there. 

Best Regards!

Qi = Sun
On 2013-2-12, at =E4=B8=8A=E5=8D=888:24, Ted Lemon = wrote:

At the IETF meeting in Atlanta, we ended the session = with a long discussion about how to solve the problem of configuring = MAP-E and lw4over6 IPv4 stacks; several possibilities were presented, = and we decided that we would write a draft summarizing these = possibilities so that the working group could state a = preference.

Time went on, and none of the people who volunteered = actually did anything, so a couple of weeks ago Branimir Rajtar and Ian = Farrer offered to write it up based on the notes from the last meeting. =   They have done so, and submitted a -00 draft: https://datatracker.ietf.org/doc/draft-rajtar-dhc-v4configuration/
The purpose of this draft is to enumerate all the potential = solutions to this problem, describe their pros and cons, and make a = recommendation.   The current state of the draft is the = recommendation that most people seemed to be leaning toward at the end = of the meeting in Atlanta, but it's not binding; if during discussion = the working group decides to recommend something else, the document will = be updated to reflect that.

If you think the working group should = in fact produce this document, please say so on the mailing list. =   If you think we shouldn't produce such a document, please = also say so.   If you have comments on the content of the = document, please hold off on that until it's been adopted, or not = adopted.   If it's not adopted, the comments are moot; if it = is adopted, the job of the working group will be to finish it according = to the input of working group participants, which is where your comments = would come in.

We will evaluate consensus on February = 25.

Thanks!

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

= --Apple-Mail-3-252781325-- From ian.farrer@telekom.de Wed Feb 13 23:53:57 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61D021F8878 for ; Wed, 13 Feb 2013 23:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hhk-S+7CzfXB for ; Wed, 13 Feb 2013 23:53:57 -0800 (PST) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id E181A21F8877 for ; Wed, 13 Feb 2013 23:53:56 -0800 (PST) Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 14 Feb 2013 08:53:25 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 14 Feb 2013 08:53:25 +0100 From: To: , Date: Thu, 14 Feb 2013 08:53:23 +0100 Thread-Topic: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration Thread-Index: Ac4KiF3+o+9+Tf4KSWaWEbchkkDubw== Message-ID: In-Reply-To: <15515E2A-ED99-470D-B6ED-41BD67B145A0@gmail.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhcwg@ietf.org, Ted.Lemon@nominum.com Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 14 Feb 2013 07:53:57 -0000 Hi Ole/Qi, Qi's correct here. We were careful in writing the unified draft not to state a DHCP version or transport throughout. it's concerned with how the CPE should interpret the presence of configuration parameters so that it can work out which softwire 'mode' to use. Assuming that we get an outcome from this discussion in DHC, then unified-cpe will be updated with the outcome. Cheers, Ian On 13/02/2013 17:48, "Qi Sun" wrote: > >Hi Ole, > >> the unified CPE draft tried to come up with a single provisioning >>scheme. that draft uses DHCPv6 I thought. >> (http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-02) > > >[Qi] This is not what I read from the unified CPE draft. There is a >DISCUSSION NOTE says that the customer side DHCP based provisioning >method (DHCPv4/v6) will be updated to reflect the consensus from DHC WG. >IMHO the draft-rajtar-* is doing the job. > > >Best Regards! > >Qi Sun > > >On 2013-2-13, at =1B$B2<8a=1B(B10:58, Ole Troan wrote: > >> Ted, >>=20 >>>> I understand that DHCPv6 is one of the options, but I disagree with >>>>current stated conclusions of the draft. >>>> I agree with Ole that this draft could be useful for summarizing the >>>>discussion, but in my opinion the dhc working group should not work >>>>alone to solve this problem, softwire WG should be involved in this >>>>discussion. >>>=20 >>> Softwire isn't chartered to define DHCP protocol extensions, so they >>>can't do this work. If softwire participants are interested in >>>directing the discussion, they need to come to the DHC working group to >>>do it. We will in fact be discussing this document in the softwire >>>meeting on Monday, but the work has to happen here, and has to be >>>discussed here. >>>=20 >>> This document happens to be motivated by the softwires question at the >>>moment, but the overall question of how to configure IPv4 hosts on an >>>IPv6-only or dual-stack network is general=1B$B!=3D=1B(Bthe working grou= p has >>>considered the question with respect to the work of a number of >>>different working groups in the past. >>>=20 >>> If you think that DHCPv6 should be used to configure IPv4 hosts, you >>>should support adopting this document and make your case in the working >>>group. The document is not cast in concrete, and as I said in the >>>call for adoption, supporting adoption does not mean that you agree >>>with the current conclusions of the document. >>=20 >> the softwire solutions are largely concerned about configuring routers, >>not hosts. >>=20 >>> The current document simply concludes with what seemed to be the >>>consensus at the end of the in-person meeting in Atlanta. If that is >>>not the real consensus of the working group, which is quite possible, >>>that fact will emerge as a result of the working group working on the >>>document. >>=20 >> that wasn't my impression when I left the meeting. unless you don't >>include MAP provisioning in that statement? >> my recollection was that MAP used the combination of meta information >>to deduce its IPv4 address from the IPv6 address was perfectly fine in >>DHCPv6. provisioning a normal IPv4 address on top of a vanilla point to >>point tunnel I agree with is DHCPv4. >> problem comes when you want to provision A+P. do you want to replicate >>very similar options between DHCPv6 and DHCPv4. >> the unified CPE draft tried to come up with a single provisioning >>scheme. that draft uses DHCPv6 I thought. >> (http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-02) >>=20 >> cheers, >> Ole >> _______________________________________________ >> 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 Thu Feb 14 00:21:20 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A88321F8522 for ; Thu, 14 Feb 2013 00:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLQLnS84cAyw for ; Thu, 14 Feb 2013 00:21:14 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 8533321F8519 for ; Thu, 14 Feb 2013 00:21:14 -0800 (PST) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 14 Feb 2013 09:21:00 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Thu, 14 Feb 2013 09:21:00 +0100 From: Maglione Roberta To: 'Ted Lemon' , Wojciech Dec , Capello Alessandro Date: Thu, 14 Feb 2013 09:20:59 +0100 Thread-Topic: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration Thread-Index: AQHOCLdJAJANwYon10iWTDBlj58gmJh3pPhggACyx4CAAAFgAIAABnQAgAAVjoCAAA4xAIAAHkIAgAACF4CAAF+JIA== Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE519D1A751A@GRFMBX704BA020.griffon.local> References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE519D1A750C@GRFMBX704BA020.griffon.local> <8D23D4052ABE7A4490E77B1A012B63074748A45A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748A6BA@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748ACB3@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748B26E@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074748B26E@mbx-01.win.nominum.com> 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 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 14 Feb 2013 08:21:20 -0000 Hi Ted, I think there is an additional architectural point to consider here: addi= ng a DHCPv4 server just for this specific purpose, would introduce operatio= nal costs in terms of provisioning. Provisioning is a sensitive issue for a service provider, trying to reduce = the number of provisioning points is a key goal for a Service Provider and = a trigger for developing optimized architecture. Seamless MPLS (draft-ietf-= mpls-seamless-mpls) is one example of simplification of the operations achi= eved by reducing the provisioning points. Introducing a DHCPv4 Server in addition to the existing/already required DH= CPv6 Server, would require doubling the provisioning points, having to spl= it the provisioning for the same customer between two servers and having to= deal with two sets of provisioning tools. This is definitely an operationa= l issue for an operator. Best regards, Roberta -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Wednesday, February 13, 2013 7:25 PM To: Wojciech Dec Cc: dhcwg@ietf.org WG; Capello Alessandro Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration On Feb 13, 2013, at 1:17 PM, Wojciech Dec wrote: > It's not having to deploy infrastructure (at cost) to support a protocol = to solve a specific point problem that can be solved through other means. I= t's thus directly linked to the operational bottom line of operators and on= e would say that it's where technology requirments stem from. Right, this is a preference, not a requirement. More to the point, all th= ree solutions outlined in the draft require zero additional equipment other= than the equipment that runs the DHCPv4 server. It's hard to take this s= eriously as a prohibitive operational expense. This objection was raised in the working group meeting in Atlanta, and I be= lieve it's represented in the document; if not, please send suggested text = to the authors. The working group can weigh it. Or not, if we decide no= t to do this work. But do be aware that if we decide not to do this work, it doesn't mean, de = facto, that softwires gets to make the decision. It means that the dhc wo= rking group doesn't have consensus on what to do, and likely there can be n= o softwires DHCP solution at all. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg 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 mohamed.boucadair@orange.com Thu Feb 14 01:11:43 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB32021F86C1 for ; Thu, 14 Feb 2013 01:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RA8sEAjBiWBU for ; Thu, 14 Feb 2013 01:11:42 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 18AC021F86B7 for ; Thu, 14 Feb 2013 01:11:41 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id B8CBF22C23C; Thu, 14 Feb 2013 10:11:40 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 997EC238048; Thu, 14 Feb 2013 10:11:40 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Thu, 14 Feb 2013 10:11:38 +0100 From: To: Ted Lemon , Wojciech Dec Date: Thu, 14 Feb 2013 10:11:36 +0100 Thread-Topic: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration Thread-Index: AQHOCLdJAJANwYon10iWTDBlj58gmJh3pPhggACyx4CAAAFgAIAABnQAgAAVjoCAAA4xAIAAHkIAgAACF4CAAAmrgIAAGHmAgABLKRA= Message-ID: <94C682931C08B048B7A8645303FDC9F36EAFB565A8@PUEXCB1B.nanterre.francetelecom.fr> References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE519D1A750C@GRFMBX704BA020.griffon.local> <8D23D4052ABE7A4490E77B1A012B63074748A45A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748A6BA@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748ACB3@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748B26E@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748B5CB@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074748B5CB@mbx-01.win.nominum.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: "dhcwg@ietf.org WG" , Capello Alessandro Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 14 Feb 2013 09:11:43 -0000 Hi Ted, all, I agree with Woj here.=20 The analysis is meaningless in the lack of clear and precise requirements.= =20 The analysis should not ignore which ongoing specification effort(s) is see= king for a position from dhc wg. The analysis should not ignore to put this effort in the overall context of= simplifying migration of networks to IPv6 (ideally IPv6-only mode). The analysis should not ignore there are deployments which do not require a= nymore a dhcpv4 server (e.g.; DS-Lite). The analysis should not ignore MAP is seen as an exist strategy from the DS= -Lite model: it will be a no-starter for those operators to re-introduce DH= CPv4. The analysis should not ignore some fundamental design principle of some so= lutions such as MAP which assumes an algorithmic dependency between IPv4 an= d IPv6 addresses. The analysis should not ignore the complications which may raise if both DH= CPv6, DHCPv4, DHCPv4o6 relays are needed to cover legacy CPEs, IPv6-enabled= CPEs and those services with a softwire-based IPv4 service continuity solu= tion. The analysis should not ignore that for some proposed solution, other means= than DHCPvX can be used to learn an IPv4 address (and optionally a set of = ports). I really think this effort should be coordinated with softiwre wg. Cheers, Med =20 >-----Message d'origine----- >De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De=20 >la part de Ted Lemon >Envoy=E9 : mercredi 13 f=E9vrier 2013 21:28 >=C0 : Wojciech Dec >Cc : dhcwg@ietf.org WG; Capello Alessandro >Objet : Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration > >On Feb 13, 2013, at 2:00 PM, Wojciech Dec > wrote: >> The server is not a major operational expense, the clients=20 >are, along with all the bits needed along the path (relays) to=20 >make things work. Put in another way, one would be very hard=20 >pressed to justify to a CTO of an existing SP, why he has to=20 >go and invest and maintain in technolgy that he can do without=20 >for the services the network is meant to offer.=20 > >For heaven's sake, if you're going to criticize the draft,=20 >please at least read it. There are no relays needed-you=20 >already have an IPv6 address, so the packet can be unicast and=20 >routed directly to the DHCP server, in both alternatives that=20 >use a DHCPv4 server. You have a device with a DHCPv6 client;=20 >adding a DHCPv4 client doesn't mean you have to buy another device. > >> There are no requirements as far as I can tell in the=20 >document, other than the implicit ones of the authors (not=20 >listed). That's why I think its scope needs to be adjusted to=20 >cover both requirments and analysis. Before that happens I do=20 >not think it should be adopted by the WG, as we'll be churning=20 >for ever about the grounds for analysis. > >Woj, the question in the document is, supposing we need to=20 >configure an IPv4 stack on an IPv6 only network, what is the=20 >DHC working group's advice as to how to do it? This is a DHC=20 >document, not a softwire document. What do you need to know=20 >about requirements beyond this, which is expressed in the draft? > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg >= From Branimir.Rajtar@t.ht.hr Thu Feb 14 01:41:12 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1A621F867D for ; Thu, 14 Feb 2013 01:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.175 X-Spam-Level: X-Spam-Status: No, score=-1.175 tagged_above=-999 required=5 tests=[AWL=1.424, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJmoxTlLV717 for ; Thu, 14 Feb 2013 01:41:11 -0800 (PST) Received: from mx02.t.ht.hr (mx02.t.ht.hr [195.29.161.89]) by ietfa.amsl.com (Postfix) with SMTP id AEA4F21F866F for ; Thu, 14 Feb 2013 01:41:10 -0800 (PST) Received: from no.name.available by mx02.t.ht.hr via smtpd (for mail.ietf.org [64.170.98.30]) with ESMTP; Thu, 14 Feb 2013 10:09:06 +0100 Received: from (unknown [172.17.66.76]) by scmg2.t.ht.hr with smtp id 0e79_638e_a84c7f92_768a_11e2_a571_00219b931f47; Thu, 14 Feb 2013 10:41:07 +0100 Received: (private information removed) Thu, 14 Feb 2013 10:41:07 +0100 Received: (private information removed) S2010EXCHCA2.ad.local ([::1]) with mapi id 14.02.0328.009; Thu, 14 Feb 2013 10:41:07 +0100 From: Branimir Rajtar To: "Bernie Volz (volz)" , Ted Lemon , "dhcwg@ietf.org WG" Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-08 Thread-Index: AQHOAi8Y6L/mEtMT5UW0fdfJAZ+WqJh4VB9AgADUpJA= Date: Thu, 14 Feb 2013 09:41:06 +0000 Message-ID: <786F13AA11E69F4DB2CCA23F7400C2FB05BE27@S2010EXCH1.ad.local> References: <8D23D4052ABE7A4490E77B1A012B63074747BF6B@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E1846A61A@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1846A61A@xmb-rcd-x04.cisco.com> Accept-Language: en-US, hr-HR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.5.14] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 14 Feb 2013 09:41:07.0275 (UTC) FILETIME=[69DCF1B0:01CE0A97] X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 09:41:12 -0000 SGksCgpUaGFua3MgZm9yIHlvdXIgY29tbWVudCAtIHdlIHdpbGwgYW1lbmQgaXQgaW4gdGhlIG5l eHQgdmVyc2lvbi4KCkkgd291bGQgbGlrZSB0byBnaXZlIGEgc2hvcnQgb3ZlcnZpZXcgb2YgdGhl IHJlYXNvbmluZyBiZWhpbmQgdGhpcyBkcmFmdCwgYWx0aG91Z2ggVGVkIGFscmVhZHkgcHJvdmlk ZWQgaXQuIEkgYWdyZWUgd2l0aCBtb3N0IG9mIHRoZSBjb21tZW50cyB0aGF0IHRoaXMgZHJhZnQg aGFzIHRvIGJlIHdvcmtlZCBvbiwgYnV0IHRoZSB3b3JrIHNob3VsZCBzdGFydCBhcyBzb29uIGFz IHBvc3NpYmxlLiBJYW4gYW5kIEkgYXJlIGN1cnJlbnRseSB3b3JraW5nIG9uIGEgcHJvamVjdCB3 aGljaCBkZWFscyB3aXRoIHRoaXMgdG9waWMgYW5kIHdlJ3JlIHVuYWJsZSB0byBkZWZpbmUgb3Vy IG5ldHdvcmsgYXJjaGl0ZWN0dXJlIGJlY2F1c2UgdGhlcmUgaXMgbm8gcmVjb21tZW5kYXRpb24g aG93IHRvIHByb3ZpZGUgdGhlIHY0IHBhcmFtZXRlcnMgb3ZlciB2Ni4KCllvdSBtaWdodCBub3Qg YWdyZWUgd2l0aCBvdXIgY29uY2x1c2lvbiwgYnV0IGxldCdzIGdldCBhIG1vbWVudHVtIG9uIHRo aXMgaXNzdWUgYW5kIGNvbWUgdG8gYW4gYWdyZWVkIHNvbHV0aW9uIHdoYXRldmVyIGl0IG1heSBi ZS4KCkJyYW5pbWlyIFJhanRhcgoKCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCkZyb206IGRo Y3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgQmVybmllIFZvbHogKHZvbHopClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMTMs IDIwMTMgMTA6MjEgUE0KVG86IFRlZCBMZW1vbjsgZGhjd2dAaWV0Zi5vcmcgV0cKU3ViamVjdDog UmU6IFtkaGN3Z10gV0dMQzogZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LXJhZGl1cy1vcHQtMDgKCkkg c3VwcG9ydCB0aGlzIG1vdmluZyBmb3J3YXJkLiBJIHRoaW5rIG15IGNvbW1lbnRzIHdlcmUgYWRk cmVzc2VkLgoKSW4gbXkgcmVhZGluZywgSSBkaWQgbm90aWNlIG9uZSBtaW5vciBuaXQgYnV0IHRo YXQgbWF5IGJlIGZpeGVkIGJ5IFJGQyBFZGl0b3Igb3IgaW4gdGhlIEFVVEgtNDggcmV2aWV3OgoK NC4gIERIQ1B2NiBSQURJVVMgb3B0aW9uCgogICBUaGUgT1BUSU9OX1JBRElVUyBpcyBhIERIQ1B2 NiBvcHRpb24gdXNlZCBieSB0aGUgREhDUHY2IHJlbGF5IGFnZW50CiAgIHRvIGNhcnJ5IHRoZSBh dXRob3JpemF0aW9uIGluZm9ybWF0aW9uIG9mIFJBRElVUyBhdHRyaWJ1dGVzIHJlY2VpdmVkCiAg IGluIHRoZSBBY2Nlc3MtQWNjZXB0IG1lc3NhZ2UgZnJvbSB0aGUgUkFESVVTIHNlcnZlLgoKSSB0 aGluayAic2VydmUiIHNob3VsZCBiZSAic2VydmVyIi4KCi0gQmVybmllCgotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQpGcm9tOiBkaGN3Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGhjd2ct Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlZCBMZW1vbgpTZW50OiBTdW5kYXksIEZl YnJ1YXJ5IDAzLCAyMDEzIDExOjU0IEFNClRvOiBkaGN3Z0BpZXRmLm9yZyBXRwpTdWJqZWN0OiBb ZGhjd2ddIFdHTEM6IGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1yYWRpdXMtb3B0LTA4CgpUaGUgYXV0 aG9ycyBvZiB0aGlzIGRyYWZ0IGhhdmUgYXNrZWQgZm9yIGEgbmV3IHdvcmtpbmcgZ3JvdXAgbGFz dCBjYWxsLiAgV2UgaGFkIGEgV0dMQyBpbiBOb3ZlbWJlciwgYW5kIHRoZXJlIHdlcmUgc3Vic3Rh bnRpYWwgYW5kIGNvbnN0cnVjdGl2ZSBjb21tZW50cywgd2hpY2ggYXJlIGluY29ycG9yYXRlZCBp biB0aGUgbmV3IHZlcnNpb24uICAgVGhlIGNoYW5nZXMgY2FuIGJlIHNlZW4gaGVyZTogCgpodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1yYWRp dXMtb3B0LTA1LnR4dCZ1cmwyPWRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1yYWRpdXMtb3B0LTA4LnR4 dAoKVGhpcyBkaWZmIGluY2x1ZGVzIGEgbnVtYmVyIG9mIGNoYW5nZXMgdGhhdCBoYXZlIG9jY3Vy cmVkIHNpbmNlIHRoZSBtb3N0IHJlY2VudCBsYXN0IGNhbGwtdGhlcmUgaGF2ZSBiZWVuIHNldmVy YWwgcmV2aXNpb25zIG9mIHRoZSBkcmFmdC4KCklmIHlvdSBoYXZlbid0IHJlYWQgdGhlIGRyYWZ0 LCBub3cgd291bGQgYmUgYSBnb29kIHRpbWUgdG8gZG8gc286CgpodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWRoYy1kaGNwdjYtcmFkaXVzLW9wdC0wOAoKSWYgeW91IHRoaW5r IHRoZSBkcmFmdCBpcyByZWFkeSB0byBhZHZhbmNlLCBwbGVhc2UgaW5kaWNhdGUgeW91ciBzdXBw b3J0IG9uIHRoZSBtYWlsaW5nIGxpc3QuICAgSWYgeW91IHRoaW5rIGl0IGlzIG5vdCByZWFkeSwg cGxlYXNlIHNheSBzbyBhcyB3ZWxsLiAgIEFuZCBvZiBjb3Vyc2UsIGFkZGl0aW9uYWwgY29tbWVu dHMgYXJlIHNvbGljaXRlZCBhbmQgd2VsY29tZS4gICBXZSB3aWxsIGV2YWx1YXRlIGNvbnNlbnN1 cyBvbiBvciBhZnRlciBGZWJydWFyeSAxOS4KClAuUy4gSSBhc2tlZCBMZWFmIHRvIHJlbW92ZSBt ZSBhcyBhbiBhdXRob3Igb2YgdGhlIGRyYWZ0LCBiZWNhdXNlIEkgaGF2ZW4ndCBhY3R1YWxseSBj b250cmlidXRlZCBhbnl0aGluZyBzdWJzdGFudGlhbCB0byBpdCwgYW5kIHdvcmtpbmcgZ3JvdXAg Y2hhaXJzIGF1dGhvcmluZyBkcmFmdHMgY3JlYXRlIHZhcmlvdXMgcHJvY2VkdXJhbCBwcm9ibGVt cy4gICBJZiBhbnlib2R5IGZlZWxzIHRoYXQgdGhpcyBpcyBpbmFwcHJvcHJpYXRlLCBwbGVhc2Ug c2F5IHNvLiAgIEFzIGEgd29ya2luZyBncm91cCBwYXJ0aWNpcGFudCwgSSB0aGluayB0aGUgZHJh ZnQgaXMgYSByZWFzb25hYmx5IGdvb2QgaWRlYSwgYnV0IEkgaGF2ZSBubyBwZXJzb25hbCBzdGFr ZSBpbiB0aGUgYWR2YW5jZW1lbnQgb3Igbm9uLWFkdmFuY2VtZW50IG9mIHRoZSBkcmFmdC1pdCBk b2Vzbid0IGFjdHVhbGx5IHJlbGF0ZSB0byB3b3JrIEkgZG8gb3V0c2lkZSBvZiBJRVRGLCBub3Ig ZG9lcyBteSBJRVRGIHdvcmsgZGVwZW5kIG9uIGl0LgoKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KZGhjd2cgbWFpbGluZyBsaXN0CmRoY3dnQGlldGYub3Jn Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZGhjd2cgbWFpbGluZyBsaXN0CmRo Y3dnQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cK Cgo8SFRNTD48UD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSM5OTk5OTkgc2l6ZT0xPg0KDQpJWkpB VkEgTyBPRFJJQ0FOSlUgT0RHT1ZPUk5PU1RJOiBTYWRyxb5haiBvdmUgcG9ydWtlIGkgZXZlbnR1 YWxubyBwcmlsb8W+ZW5paCBkYXRvdGVrYSBqZSBwb3ZqZXJsaml2IGkgbmFtaWplbmplbiBqZSBz YW1vIG9zb2JhbWEgaWxpIHN1Ympla3RpbWEga29qaSBzdSBuYXZlZGVuaSB1IGFkcmVzaS4gVWtv bGlrbyBzdGUgcHJpbWlsaSBvdnUgcG9ydWt1IGdyZcWha29tLCBtb2xpbW8gVmFzLCBvYmF2aWpl c3RpdGUgcG/FoWlsamF0ZWxqYSwgYSBwb3J1a3UgaSBzdmUgbmplbmUgcHJpdml0a2Ugb2RtYWgs IGJleiDEjWl0YW5qYSwgdHJham5vIHVrbG9uaXRlIHMgcmHEjXVuYWxhLiBCaWxvIGtha3ZvIHBy ZW5vxaFlbmplLCBrb3BpcmFuamUgaWxpIGRpc3RyaWJ1Y2lqYSBpbmZvcm1hY2lqYSBzYWRyxb5h bmloIHUgcG9ydWNpIHRyZcSHaW0gb3NvYmFtYSBqZSB6YWJyYW5qZW5vIGkgbW/FvmUgYml0aSB6 YWtvbnNraSBrYcW+bmppdm8uIFNhZHLFvmFqLCBzdGF2b3ZpIGkgbWnFoWxqZW5qYSBpem5lc2Vu aSB1IHBvcnVjaSBzdSBhdXRvcm92aSBpIG5lIHByZWRzdGF2bGphanUgbnXFvm5vIHN0YXZvdmUg SFQgLSBIcnZhdHNraWggdGVsZWtvbXVuaWthY2lqYSBkLmQuIEhUIG5lIHByaWh2YcSHYSBuaWth a3Z1IG9kZ292b3Jub3N0IHphIGV2ZW50dWFsbnUgxaF0ZXR1IG5hc3RhbHUgcHJpbWl0a29tIG92 ZSBwb3J1a2UgaSBwcmlsb2dhIHNhZHLFvmFuaWggdSBwb3J1Y2kuDQoNCjwvRk9OVD48L1A+PFA+ PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jOTk5OTk5IHNpemU9MT4NCg0KIERJU0NMQUlNRVI6VGhl IGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYXMgd2VsbCBhcyBhbnkgZmlsZXMgYXR0YWNoZWQgdG8g aXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciBpbmRpdmlkdWFscyBv ciBlbnRpdGllcyB3aGljaCB0aGV5IGFyZSBhZGRyZXNzZWQgdG8uIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgZW1haWwgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGFuZCBwZXJtYW5lbnRseSByZW1vdmUgdGhlIG1lc3NhZ2UgYW5kIGFsbCBhdHRhY2hlZCBmaWxl cyBmcm9tIHRoZSBjb21wdXRlci4gQW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcgb3IgZGlzdHJpYnV0 aW9uIG9mIGFsbCBvciBhIHBhcnQgb2YgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiB0byBv ciBieSB0aGlyZCBwYXJ0aWVzIGlzIHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gUGxl YXNlIG5vdGUgdGhhdCBhbnkgdmlld3Mgb3Igb3BpbmlvbnMgcHJlc2VudGVkIGluIHRoaXMgbWVz c2FnZSBhcmUgc29sZWx5IHRob3NlIG9mIHRoZSBhdXRob3IgYW5kIGRvIG5vdCBuZWNlc3Nhcmls eSByZXByZXNlbnQgdGhlIHZpZXdzIGFuZCBvcGluaW9ucyBvZiBDcm9hdGlhbiBUZWxlY29tIElu Yy4gQ3JvYXRpYW4gVGVsZWNvbSBJbmMuIGFjY2VwdHMgbm8gbGlhYmlsaXR5IGZvciBhbnkgcG90 ZW50aWFsIGRhbWFnZSBjYXVzZWQgYnkgdGhpcyBtZXNzYWdlIGFuZCBmaWxlcyBhdHRhY2hlZCB0 byBpdC4NCg0KPC9GT05UPjwvUD48L0hUTUw+Cg== From wdec.ietf@gmail.com Thu Feb 14 01:52:13 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4353A21F8651 for ; Thu, 14 Feb 2013 01:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftn456anGBcZ for ; Thu, 14 Feb 2013 01:52:12 -0800 (PST) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id 809B121F855C for ; Thu, 14 Feb 2013 01:52:12 -0800 (PST) Received: by mail-qa0-f53.google.com with SMTP id z4so950401qan.5 for ; Thu, 14 Feb 2013 01:52:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=Ba1n1kByUKIFKV95Ulzp13biteEjHo0AcZAbg5ZdKNg=; b=VSlNNVqIrfElDpvs/O2ke/7PVHgeEXaurcjDNmWl3c+DVBW/+G4PTJ6FNZzTg/ehxF IzQ5NjCYvA7ScClQAog0ArfWk0haHTmxuH9/+RWNRtbmEIoNmUkruM9vFQcjm67fAZqv rCV98Y/HSbqYQZXLlp7F11ZO8z1NHEaTtSwON1+i2ZtoJvZj8BUI4QjYSId5oKubHB69 A1DG1ekfos/oTICIei5hbCUZjSUafZBJ6yPXhijaZGINvobD6fPLKTHEdGnQaBW/ygPi 7dih4RCoTr8HG7MN3Vp5wEydjk3/cb2okpKtkDllcLWu5cgniBGgD775bfHkqTlNVXkV xcbg== MIME-Version: 1.0 X-Received: by 10.224.58.147 with SMTP id g19mr347970qah.22.1360835531914; Thu, 14 Feb 2013 01:52:11 -0800 (PST) Received: by 10.49.75.33 with HTTP; Thu, 14 Feb 2013 01:52:11 -0800 (PST) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074748B5CB@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE519D1A750C@GRFMBX704BA020.griffon.local> <8D23D4052ABE7A4490E77B1A012B63074748A45A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748A6BA@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748ACB3@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748B26E@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748B5CB@mbx-01.win.nominum.com> Date: Thu, 14 Feb 2013 10:52:11 +0100 Message-ID: From: Wojciech Dec To: Ted Lemon Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "dhcwg@ietf.org WG" , Capello Alessandro Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 14 Feb 2013 09:52:13 -0000 On 13 February 2013 21:27, Ted Lemon wrote: > > On Feb 13, 2013, at 2:00 PM, Wojciech Dec > wrote: > > The server is not a major operational expense, the clients are, along w= ith all the bits needed along the path (relays) to make things work. Put in= another way, one would be very hard pressed to justify to a CTO of an exis= ting SP, why he has to go and invest and maintain in technolgy that he can = do without for the services the network is meant to offer. > > For heaven's sake, if you're going to criticize the draft, please at leas= t read it. There are no relays needed=97you already have an IPv6 address,= so the packet can be unicast and routed directly to the DHCP server, in bo= th alternatives that use a DHCPv4 server. You have a device with a DHCPv6= client; adding a DHCPv4 client doesn't mean you have to buy another device= . Adding a new and yet more a custom DHCPv4 client to *anything* (even existing devices) that don't have one, and arguably don't need one, is a cost to an operator. Re the relay and quoting the draft directly: "On receipt at the tunnel concentrator (e.g. MAP Border Router or a Lightweight 4over6 lwAFTR), the DHCPv4 message removed from the softwire and forwarded to the DHCPv4 server in the same way as any other IPv4 packet is handled." This is clearly misinformed: AFTRs require special handling for forwarding DHCPv4 traffic. Call it whatever you want, but I'll call it a relay, since no AFTR will route back DHCPv4 traffic with a destination address of 0.0.0.0 if not by acting as a DHCPv4 relay. > > > > There are no requirements as far as I can tell in the document, other t= han the implicit ones of the authors (not listed). That's why I think its s= cope needs to be adjusted to cover both requirments and analysis. Before th= at happens I do not think it should be adopted by the WG, as we'll be churn= ing for ever about the grounds for analysis. > > Woj, the question in the document is, supposing we need to configure an I= Pv4 stack on an IPv6 only network, what is the DHC working group's advice a= s to how to do it? This is a DHC document, not a softwire document. Wha= t do you need to know about requirements beyond this, which is expressed in= the draft? All I'm saying is that the requirements be laid out in the open along with their rationale. Thankfully I seem to be not the only one. I am puzzled by why you appear to be opposed to get the requirements laid down before conducting an analysis of the solutions by the DHC working group. From ian.farrer@telekom.de Thu Feb 14 04:52:06 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D314121F879E for ; Thu, 14 Feb 2013 04:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5+ozkE2nFgY for ; Thu, 14 Feb 2013 04:52:06 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id CE9AB21F8911 for ; Thu, 14 Feb 2013 04:52:05 -0800 (PST) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 14 Feb 2013 13:52:01 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 14 Feb 2013 13:52:00 +0100 From: To: , Date: Thu, 14 Feb 2013 13:52:01 +0100 Thread-Topic: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration Thread-Index: Ac4KshSExDhYJJIeSyiysifwtafK1Q== Message-ID: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhcwg@ietf.org, alessandro.capello@telecomitalia.it Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 14 Feb 2013 12:52:06 -0000 Hi Woj, Comment in line. Cheers, Ian On 14/02/2013 10:52, "Wojciech Dec" wrote: >On 13 February 2013 21:27, Ted Lemon wrote: >> >> On Feb 13, 2013, at 2:00 PM, Wojciech Dec >> wrote: >> > The server is not a major operational expense, the clients are, along >>with all the bits needed along the path (relays) to make things work. >>Put in another way, one would be very hard pressed to justify to a CTO >>of an existing SP, why he has to go and invest and maintain in technolgy >>that he can do without for the services the network is meant to offer. >> >> For heaven's sake, if you're going to criticize the draft, please at >>least read it. There are no relays needed=8Byou already have an IPv6 >>address, so the packet can be unicast and routed directly to the DHCP >>server, in both alternatives that use a DHCPv4 server. You have a >>device with a DHCPv6 client; adding a DHCPv4 client doesn't mean you >>have to buy another device. > >Adding a new and yet more a custom DHCPv4 client to *anything* (even >existing devices) that don't have one, and arguably don't need one, is >a cost to an operator. > >Re the relay and quoting the draft directly: >"On receipt at the tunnel concentrator (e.g. MAP Border Router or a >Lightweight 4over6 lwAFTR), the DHCPv4 message removed from the >softwire and forwarded to the DHCPv4 server in the same way as any >other IPv4 packet is handled." > >This is clearly misinformed: AFTRs require special handling for >forwarding DHCPv4 traffic. Call it whatever you want, but I'll call it >a relay, since no AFTR will route back DHCPv4 traffic with a >destination address of 0.0.0.0 if not by acting as a DHCPv4 relay. It would have a destination of 0.0.0.0 if it was a DHCPDISCOVER message, but it's a DHCPINFORM, which is a unicast and so can be handled the same as any other v4 packet without a relay. That's why the draft states that a mechanism to learn the unicast v4 address of the DHCPv4 server is necessary (2 paragraphs below the text you've quoted above): "For this approach to function, a mechanism for the DHCPv4 client to learn the IPv4 address of the DHCPv4 server is needed. This could be done by defining a well-known IPv4 address for the DHCPv4 server, implementing a DHCPv4 relay function within the tunnel concentrator or other configuration methods." > >> >> >> > There are no requirements as far as I can tell in the document, other >>than the implicit ones of the authors (not listed). That's why I think >>its scope needs to be adjusted to cover both requirments and analysis. >>Before that happens I do not think it should be adopted by the WG, as >>we'll be churning for ever about the grounds for analysis. >> >> Woj, the question in the document is, supposing we need to configure an >>IPv4 stack on an IPv6 only network, what is the DHC working group's >>advice as to how to do it? This is a DHC document, not a softwire >>document. What do you need to know about requirements beyond this, >>which is expressed in the draft? > > >All I'm saying is that the requirements be laid out in the open along >with their rationale. Thankfully I seem to be not the only one. >I am puzzled by why you appear to be opposed to get the requirements >laid down before conducting an analysis of the solutions by the DHC >working group. >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From Branimir.Rajtar@t.ht.hr Thu Feb 14 04:59:06 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE5721F87AC for ; Thu, 14 Feb 2013 04:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[AWL=0.949, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkVa+0g8VQIv for ; Thu, 14 Feb 2013 04:59:05 -0800 (PST) Received: from mx02.t.ht.hr (mx02.t.ht.hr [195.29.161.89]) by ietfa.amsl.com (Postfix) with SMTP id D434C21F87D6 for ; Thu, 14 Feb 2013 04:59:04 -0800 (PST) Received: from no.name.available by mx02.t.ht.hr via smtpd (for mail.ietf.org [64.170.98.30]) with ESMTP; Thu, 14 Feb 2013 13:27:00 +0100 Received: from (unknown [172.17.66.76]) by scmg2.t.ht.hr with smtp id 67cc_ff20_4edd2652_76a6_11e2_ad48_00219b931f47; Thu, 14 Feb 2013 13:59:03 +0100 Received: (private information removed) Thu, 14 Feb 2013 13:59:03 +0100 Received: (private information removed) S2010EXCHCA1.ad.local ([::1]) with mapi id 14.02.0328.009; Thu, 14 Feb 2013 13:59:02 +0100 From: Branimir Rajtar To: Branimir Rajtar , "Bernie Volz (volz)" , Ted Lemon , "dhcwg@ietf.org WG" Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-08 Thread-Index: AQHOAi8Y6L/mEtMT5UW0fdfJAZ+WqJh4VB9AgADUpJCAADjgoA== Date: Thu, 14 Feb 2013 12:59:02 +0000 Message-ID: <786F13AA11E69F4DB2CCA23F7400C2FB05C023@S2010EXCH1.ad.local> References: <8D23D4052ABE7A4490E77B1A012B63074747BF6B@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E1846A61A@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.5.14] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 14 Feb 2013 12:59:03.0300 (UTC) FILETIME=[10868C40:01CE0AB3] X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 12:59:06 -0000 U29ycnkgYWJvdXQgdGhpcywgSSByZXBsaWVkIG9uIGEgZHJhZnQgdGhhdCBpc24ndCBtaW5lIDoo CgpCcmFuaW1pcgoKCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCkZyb206IEJyYW5pbWlyIFJh anRhciAKU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDE0LCAyMDEzIDEwOjQxIEFNClRvOiAnQmVy bmllIFZvbHogKHZvbHopJzsgVGVkIExlbW9uOyBkaGN3Z0BpZXRmLm9yZyBXRwpTdWJqZWN0OiBS RTogV0dMQzogZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LXJhZGl1cy1vcHQtMDgKCkhpLAoKVGhhbmtz IGZvciB5b3VyIGNvbW1lbnQgLSB3ZSB3aWxsIGFtZW5kIGl0IGluIHRoZSBuZXh0IHZlcnNpb24u CgpJIHdvdWxkIGxpa2UgdG8gZ2l2ZSBhIHNob3J0IG92ZXJ2aWV3IG9mIHRoZSByZWFzb25pbmcg YmVoaW5kIHRoaXMgZHJhZnQsIGFsdGhvdWdoIFRlZCBhbHJlYWR5IHByb3ZpZGVkIGl0LiBJIGFn cmVlIHdpdGggbW9zdCBvZiB0aGUgY29tbWVudHMgdGhhdCB0aGlzIGRyYWZ0IGhhcyB0byBiZSB3 b3JrZWQgb24sIGJ1dCB0aGUgd29yayBzaG91bGQgc3RhcnQgYXMgc29vbiBhcyBwb3NzaWJsZS4g SWFuIGFuZCBJIGFyZSBjdXJyZW50bHkgd29ya2luZyBvbiBhIHByb2plY3Qgd2hpY2ggZGVhbHMg d2l0aCB0aGlzIHRvcGljIGFuZCB3ZSdyZSB1bmFibGUgdG8gZGVmaW5lIG91ciBuZXR3b3JrIGFy Y2hpdGVjdHVyZSBiZWNhdXNlIHRoZXJlIGlzIG5vIHJlY29tbWVuZGF0aW9uIGhvdyB0byBwcm92 aWRlIHRoZSB2NCBwYXJhbWV0ZXJzIG92ZXIgdjYuCgpZb3UgbWlnaHQgbm90IGFncmVlIHdpdGgg b3VyIGNvbmNsdXNpb24sIGJ1dCBsZXQncyBnZXQgYSBtb21lbnR1bSBvbiB0aGlzIGlzc3VlIGFu ZCBjb21lIHRvIGFuIGFncmVlZCBzb2x1dGlvbiB3aGF0ZXZlciBpdCBtYXkgYmUuCgpCcmFuaW1p ciBSYWp0YXIKCgotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQpGcm9tOiBkaGN3Zy1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJl cm5pZSBWb2x6ICh2b2x6KQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDEzLCAyMDEzIDEwOjIx IFBNClRvOiBUZWQgTGVtb247IGRoY3dnQGlldGYub3JnIFdHClN1YmplY3Q6IFJlOiBbZGhjd2dd IFdHTEM6IGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1yYWRpdXMtb3B0LTA4CgpJIHN1cHBvcnQgdGhp cyBtb3ZpbmcgZm9yd2FyZC4gSSB0aGluayBteSBjb21tZW50cyB3ZXJlIGFkZHJlc3NlZC4KCklu IG15IHJlYWRpbmcsIEkgZGlkIG5vdGljZSBvbmUgbWlub3Igbml0IGJ1dCB0aGF0IG1heSBiZSBm aXhlZCBieSBSRkMgRWRpdG9yIG9yIGluIHRoZSBBVVRILTQ4IHJldmlldzoKCjQuICBESENQdjYg UkFESVVTIG9wdGlvbgoKICAgVGhlIE9QVElPTl9SQURJVVMgaXMgYSBESENQdjYgb3B0aW9uIHVz ZWQgYnkgdGhlIERIQ1B2NiByZWxheSBhZ2VudAogICB0byBjYXJyeSB0aGUgYXV0aG9yaXphdGlv biBpbmZvcm1hdGlvbiBvZiBSQURJVVMgYXR0cmlidXRlcyByZWNlaXZlZAogICBpbiB0aGUgQWNj ZXNzLUFjY2VwdCBtZXNzYWdlIGZyb20gdGhlIFJBRElVUyBzZXJ2ZS4KCkkgdGhpbmsgInNlcnZl IiBzaG91bGQgYmUgInNlcnZlciIuCgotIEJlcm5pZQoKLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0KRnJvbTogZGhjd2ctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBUZWQgTGVtb24KU2VudDogU3VuZGF5LCBGZWJydWFyeSAwMywg MjAxMyAxMTo1NCBBTQpUbzogZGhjd2dAaWV0Zi5vcmcgV0cKU3ViamVjdDogW2RoY3dnXSBXR0xD OiBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtcmFkaXVzLW9wdC0wOAoKVGhlIGF1dGhvcnMgb2YgdGhp cyBkcmFmdCBoYXZlIGFza2VkIGZvciBhIG5ldyB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbC4gIFdl IGhhZCBhIFdHTEMgaW4gTm92ZW1iZXIsIGFuZCB0aGVyZSB3ZXJlIHN1YnN0YW50aWFsIGFuZCBj b25zdHJ1Y3RpdmUgY29tbWVudHMsIHdoaWNoIGFyZSBpbmNvcnBvcmF0ZWQgaW4gdGhlIG5ldyB2 ZXJzaW9uLiAgIFRoZSBjaGFuZ2VzIGNhbiBiZSBzZWVuIGhlcmU6IAoKaHR0cDovL3Rvb2xzLmll dGYub3JnL3JmY2RpZmY/dXJsMT1kcmFmdC1pZXRmLWRoYy1kaGNwdjYtcmFkaXVzLW9wdC0wNS50 eHQmdXJsMj1kcmFmdC1pZXRmLWRoYy1kaGNwdjYtcmFkaXVzLW9wdC0wOC50eHQKClRoaXMgZGlm ZiBpbmNsdWRlcyBhIG51bWJlciBvZiBjaGFuZ2VzIHRoYXQgaGF2ZSBvY2N1cnJlZCBzaW5jZSB0 aGUgbW9zdCByZWNlbnQgbGFzdCBjYWxsLXRoZXJlIGhhdmUgYmVlbiBzZXZlcmFsIHJldmlzaW9u cyBvZiB0aGUgZHJhZnQuCgpJZiB5b3UgaGF2ZW4ndCByZWFkIHRoZSBkcmFmdCwgbm93IHdvdWxk IGJlIGEgZ29vZCB0aW1lIHRvIGRvIHNvOgoKaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1kaGMtZGhjcHY2LXJhZGl1cy1vcHQtMDgKCklmIHlvdSB0aGluayB0aGUgZHJhZnQg aXMgcmVhZHkgdG8gYWR2YW5jZSwgcGxlYXNlIGluZGljYXRlIHlvdXIgc3VwcG9ydCBvbiB0aGUg bWFpbGluZyBsaXN0LiAgIElmIHlvdSB0aGluayBpdCBpcyBub3QgcmVhZHksIHBsZWFzZSBzYXkg c28gYXMgd2VsbC4gICBBbmQgb2YgY291cnNlLCBhZGRpdGlvbmFsIGNvbW1lbnRzIGFyZSBzb2xp Y2l0ZWQgYW5kIHdlbGNvbWUuICAgV2Ugd2lsbCBldmFsdWF0ZSBjb25zZW5zdXMgb24gb3IgYWZ0 ZXIgRmVicnVhcnkgMTkuCgpQLlMuIEkgYXNrZWQgTGVhZiB0byByZW1vdmUgbWUgYXMgYW4gYXV0 aG9yIG9mIHRoZSBkcmFmdCwgYmVjYXVzZSBJIGhhdmVuJ3QgYWN0dWFsbHkgY29udHJpYnV0ZWQg YW55dGhpbmcgc3Vic3RhbnRpYWwgdG8gaXQsIGFuZCB3b3JraW5nIGdyb3VwIGNoYWlycyBhdXRo b3JpbmcgZHJhZnRzIGNyZWF0ZSB2YXJpb3VzIHByb2NlZHVyYWwgcHJvYmxlbXMuICAgSWYgYW55 Ym9keSBmZWVscyB0aGF0IHRoaXMgaXMgaW5hcHByb3ByaWF0ZSwgcGxlYXNlIHNheSBzby4gICBB cyBhIHdvcmtpbmcgZ3JvdXAgcGFydGljaXBhbnQsIEkgdGhpbmsgdGhlIGRyYWZ0IGlzIGEgcmVh c29uYWJseSBnb29kIGlkZWEsIGJ1dCBJIGhhdmUgbm8gcGVyc29uYWwgc3Rha2UgaW4gdGhlIGFk dmFuY2VtZW50IG9yIG5vbi1hZHZhbmNlbWVudCBvZiB0aGUgZHJhZnQtaXQgZG9lc24ndCBhY3R1 YWxseSByZWxhdGUgdG8gd29yayBJIGRvIG91dHNpZGUgb2YgSUVURiwgbm9yIGRvZXMgbXkgSUVU RiB3b3JrIGRlcGVuZCBvbiBpdC4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCmRoY3dnIG1haWxpbmcgbGlzdApkaGN3Z0BpZXRmLm9yZwpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCmRoY3dnIG1haWxpbmcgbGlzdApkaGN3Z0BpZXRmLm9y ZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnCgoKPEhUTUw+PFA+ PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jOTk5OTk5IHNpemU9MT4NCg0KSVpKQVZBIE8gT0RSSUNB TkpVIE9ER09WT1JOT1NUSTogU2FkcsW+YWogb3ZlIHBvcnVrZSBpIGV2ZW50dWFsbm8gcHJpbG/F vmVuaWggZGF0b3Rla2EgamUgcG92amVybGppdiBpIG5hbWlqZW5qZW4gamUgc2FtbyBvc29iYW1h IGlsaSBzdWJqZWt0aW1hIGtvamkgc3UgbmF2ZWRlbmkgdSBhZHJlc2kuIFVrb2xpa28gc3RlIHBy aW1pbGkgb3Z1IHBvcnVrdSBncmXFoWtvbSwgbW9saW1vIFZhcywgb2JhdmlqZXN0aXRlIHBvxaFp bGphdGVsamEsIGEgcG9ydWt1IGkgc3ZlIG5qZW5lIHByaXZpdGtlIG9kbWFoLCBiZXogxI1pdGFu amEsIHRyYWpubyB1a2xvbml0ZSBzIHJhxI11bmFsYS4gQmlsbyBrYWt2byBwcmVub8WhZW5qZSwg a29waXJhbmplIGlsaSBkaXN0cmlidWNpamEgaW5mb3JtYWNpamEgc2FkcsW+YW5paCB1IHBvcnVj aSB0cmXEh2ltIG9zb2JhbWEgamUgemFicmFuamVubyBpIG1vxb5lIGJpdGkgemFrb25za2kga2HF vm5qaXZvLiBTYWRyxb5haiwgc3Rhdm92aSBpIG1pxaFsamVuamEgaXpuZXNlbmkgdSBwb3J1Y2kg c3UgYXV0b3JvdmkgaSBuZSBwcmVkc3RhdmxqYWp1IG51xb5ubyBzdGF2b3ZlIEhUIC0gSHJ2YXRz a2loIHRlbGVrb211bmlrYWNpamEgZC5kLiBIVCBuZSBwcmlodmHEh2EgbmlrYWt2dSBvZGdvdm9y bm9zdCB6YSBldmVudHVhbG51IMWhdGV0dSBuYXN0YWx1IHByaW1pdGtvbSBvdmUgcG9ydWtlIGkg cHJpbG9nYSBzYWRyxb5hbmloIHUgcG9ydWNpLg0KDQo8L0ZPTlQ+PC9QPjxQPjxGT05UIGZhY2U9 QXJpYWwgY29sb3I9Izk5OTk5OSBzaXplPTE+DQoNCiBESVNDTEFJTUVSOlRoZSBjb250ZW50cyBv ZiB0aGlzIGVtYWlsIGFzIHdlbGwgYXMgYW55IGZpbGVzIGF0dGFjaGVkIHRvIGl0IGFyZSBjb25m aWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgaW5kaXZpZHVhbHMgb3IgZW50aXRpZXMg d2hpY2ggdGhleSBhcmUgYWRkcmVzc2VkIHRvLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgcGVybWFu ZW50bHkgcmVtb3ZlIHRoZSBtZXNzYWdlIGFuZCBhbGwgYXR0YWNoZWQgZmlsZXMgZnJvbSB0aGUg Y29tcHV0ZXIuIEFueSBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGlvbiBvZiBhbGwg b3IgYSBwYXJ0IG9mIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gdG8gb3IgYnkgdGhpcmQg cGFydGllcyBpcyBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIFBsZWFzZSBub3RlIHRo YXQgYW55IHZpZXdzIG9yIG9waW5pb25zIHByZXNlbnRlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHNv bGVseSB0aG9zZSBvZiB0aGUgYXV0aG9yIGFuZCBkbyBub3QgbmVjZXNzYXJpbHkgcmVwcmVzZW50 IHRoZSB2aWV3cyBhbmQgb3BpbmlvbnMgb2YgQ3JvYXRpYW4gVGVsZWNvbSBJbmMuIENyb2F0aWFu IFRlbGVjb20gSW5jLiBhY2NlcHRzIG5vIGxpYWJpbGl0eSBmb3IgYW55IHBvdGVudGlhbCBkYW1h Z2UgY2F1c2VkIGJ5IHRoaXMgbWVzc2FnZSBhbmQgZmlsZXMgYXR0YWNoZWQgdG8gaXQuDQoNCjwv Rk9OVD48L1A+PC9IVE1MPgo= From wdec.ietf@gmail.com Thu Feb 14 05:17:19 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25DF21F86AB for ; Thu, 14 Feb 2013 05:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdZOo042lBJC for ; Thu, 14 Feb 2013 05:17:18 -0800 (PST) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2B13021F869F for ; Thu, 14 Feb 2013 05:17:18 -0800 (PST) Received: by mail-qe0-f45.google.com with SMTP id b4so1042573qen.18 for ; Thu, 14 Feb 2013 05:17:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=z9hScPvy2Nn/JMm8GHgXHK6YR/imf70mjADzuDgAlgA=; b=IdrRqxiKeF8HFHVpUXoPdvJKcAReIulPq0g80bzdyVGAiLync/3Rz0OyHfpTb5Xxdp 3LJCe9zM0TConC7wrAZprbbSiGt6kAzfZ1NuImgJ4U+nMeeBVzfBbqe6IXM099xmoid5 5FwuVVEKOCRj/r/K/mP+t9p2ouUrdiYz4ciZNsTppUhjvto9QwfHIDhbvhjZQvYWa9zP u5ax1MylWtJbeH08XoBRnbrJBYKbZ0bypsvULDvN4VrLXIbjMgkcTm/q5L33433M3XA/ qIqjBXFVhcE193pz2cGlMX2TvbbXh9kuVKx322ajD5Ws3Wy1QKZ1yikZNtm3A+97ttTr I2og== MIME-Version: 1.0 X-Received: by 10.224.26.210 with SMTP id f18mr566951qac.49.1360847837271; Thu, 14 Feb 2013 05:17:17 -0800 (PST) Received: by 10.49.75.33 with HTTP; Thu, 14 Feb 2013 05:17:17 -0800 (PST) In-Reply-To: References: Date: Thu, 14 Feb 2013 14:17:17 +0100 Message-ID: From: Wojciech Dec To: ian.farrer@telekom.de Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, Ted.Lemon@nominum.com, alessandro.capello@telecomitalia.it Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 14 Feb 2013 13:17:19 -0000 Hi Ian, On 14 February 2013 13:52, wrote: > Hi Woj, > > Comment in line. > > Cheers, > Ian > > > > On 14/02/2013 10:52, "Wojciech Dec" wrote: > >>On 13 February 2013 21:27, Ted Lemon wrote: >>> >>> On Feb 13, 2013, at 2:00 PM, Wojciech Dec >>> wrote: >>> > The server is not a major operational expense, the clients are, along >>>with all the bits needed along the path (relays) to make things work. >>>Put in another way, one would be very hard pressed to justify to a CTO >>>of an existing SP, why he has to go and invest and maintain in technolgy >>>that he can do without for the services the network is meant to offer. >>> >>> For heaven's sake, if you're going to criticize the draft, please at >>>least read it. There are no relays needed=E2=80=B9you already have an = IPv6 >>>address, so the packet can be unicast and routed directly to the DHCP >>>server, in both alternatives that use a DHCPv4 server. You have a >>>device with a DHCPv6 client; adding a DHCPv4 client doesn't mean you >>>have to buy another device. >> >>Adding a new and yet more a custom DHCPv4 client to *anything* (even >>existing devices) that don't have one, and arguably don't need one, is >>a cost to an operator. >> >>Re the relay and quoting the draft directly: >>"On receipt at the tunnel concentrator (e.g. MAP Border Router or a >>Lightweight 4over6 lwAFTR), the DHCPv4 message removed from the >>softwire and forwarded to the DHCPv4 server in the same way as any >>other IPv4 packet is handled." >> >>This is clearly misinformed: AFTRs require special handling for >>forwarding DHCPv4 traffic. Call it whatever you want, but I'll call it >>a relay, since no AFTR will route back DHCPv4 traffic with a >>destination address of 0.0.0.0 if not by acting as a DHCPv4 relay. > > It would have a destination of 0.0.0.0 if it was a DHCPDISCOVER message, > but it's a DHCPINFORM, which is a unicast and so can be handled the same > as any other v4 packet without a relay. That's why the draft states that = a > mechanism to learn the unicast v4 address of the DHCPv4 server is > necessary (2 paragraphs below the text you've quoted above): But how does the response message (ACK or OFFER) from the server get back to the client (that does not have an IPv4 address)? > > "For this approach to function, a mechanism for the DHCPv4 client to > learn the IPv4 address of the DHCPv4 server is needed. This could be > done by defining a well-known IPv4 address for the DHCPv4 server, > implementing a DHCPv4 relay function within the tunnel concentrator > or other configuration methods." I suppose that this would be fulfilled by the DHCPv6 option for specifying the IPv4 address of the DHCPv4 server. Correct? Regards, Woj. > >> >>> >>> >>> > There are no requirements as far as I can tell in the document, other >>>than the implicit ones of the authors (not listed). That's why I think >>>its scope needs to be adjusted to cover both requirments and analysis. >>>Before that happens I do not think it should be adopted by the WG, as >>>we'll be churning for ever about the grounds for analysis. >>> >>> Woj, the question in the document is, supposing we need to configure an >>>IPv4 stack on an IPv6 only network, what is the DHC working group's >>>advice as to how to do it? This is a DHC document, not a softwire >>>document. What do you need to know about requirements beyond this, >>>which is expressed in the draft? >> >> >>All I'm saying is that the requirements be laid out in the open along >>with their rationale. Thankfully I seem to be not the only one. >>I am puzzled by why you appear to be opposed to get the requirements >>laid down before conducting an analysis of the solutions by the DHC >>working group. >>_______________________________________________ >>dhcwg mailing list >>dhcwg@ietf.org >>https://www.ietf.org/mailman/listinfo/dhcwg > From mellon@fugue.com Thu Feb 14 08:16:14 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6927821F8831 for ; Thu, 14 Feb 2013 08:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Des+Uvdv7G3l for ; Thu, 14 Feb 2013 08:16:14 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0154421F882A for ; Thu, 14 Feb 2013 08:16:14 -0800 (PST) Received: from kali-9.home.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id 8034623814DB for ; Thu, 14 Feb 2013 11:16:12 -0500 (EST) From: Ted Lemon Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 14 Feb 2013 11:16:11 -0500 To: "dhcwg@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-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, 14 Feb 2013 16:16:14 -0000 Med has updated the draft to account for comments made during the = working group last call. This is a new WGLC: if you had comments on = the previous draft, please review the changes. If you are in favor of = advancing the draft, please say so. If you oppose advancing the draft, = please say so. We will determine consensus on February 28. Thanks! From christian.jacquenet@orange.com Thu Feb 14 08:43:34 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE0621F8630 for ; Thu, 14 Feb 2013 08:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0Nbkw+6Y3Lo for ; Thu, 14 Feb 2013 08:43:34 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id ED48021F88B5 for ; Thu, 14 Feb 2013 08:43:33 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id A26992646D3; Thu, 14 Feb 2013 17:43:32 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 874E527C054; Thu, 14 Feb 2013 17:43:29 +0100 (CET) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 14 Feb 2013 17:43:29 +0100 From: To: Ted Lemon , "dhcwg@ietf.org WG" Date: Thu, 14 Feb 2013 17:43:28 +0100 Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-03 Thread-Index: Ac4Kzp83EEibr08xS1q7BQx/ZwApbwAA72kw Message-ID: <640_1360860209_511D1431_640_705_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15A6E783EAE@PUEXCB1C.nanterre.francetelecom.fr> References: In-Reply-To: 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.10.24.110314 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-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, 14 Feb 2013 16:43:35 -0000 Hello WG, I'm in favor of advancing the draft. Cheers, Christian.=20 -----Message d'origine----- De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la part de T= ed Lemon Envoy=E9 : jeudi 14 f=E9vrier 2013 17:16 =C0 : dhcwg@ietf.org WG Objet : [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-03 Med has updated the draft to account for comments made during the working g= roup last call. This is a new WGLC: if you had comments on the previous d= raft, please review the changes. If you are in favor of advancing the dra= ft, please say so. If you oppose advancing the draft, please say so. We will determine consensus on February 28. Thanks! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From Ted.Lemon@nominum.com Thu Feb 14 09:44:03 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4AC21F8939 for ; Thu, 14 Feb 2013 09:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.58 X-Spam-Level: X-Spam-Status: No, score=-106.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djBC5doms0Fq for ; Thu, 14 Feb 2013 09:44:01 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id A92E221F883F for ; Thu, 14 Feb 2013 09:44:01 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUR0iYQr4xdRywwSwzmBCt1kxXhCqWlul@postini.com; Thu, 14 Feb 2013 09:44:01 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 489FA108170 for ; Thu, 14 Feb 2013 09:44:01 -0800 (PST) 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 27915190043; Thu, 14 Feb 2013 09:44:01 -0800 (PST) (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.0318.004; Thu, 14 Feb 2013 09:44:01 -0800 From: Ted Lemon To: "mohamed.boucadair@orange.com" Thread-Topic: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration Thread-Index: AQHOCLdJAJANwYon10iWTDBlj58gmJh3pPhggACyx4CAAAFgAIAABnQAgAAVjoCAAA4xAIAAHkIAgAACF4CAAAmrgIAAGHmAgABLKRCAARlygA== Date: Thu, 14 Feb 2013 17:44:00 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074748CE40@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE519D1A750C@GRFMBX704BA020.griffon.local> <8D23D4052ABE7A4490E77B1A012B63074748A45A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748A6BA@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748ACB3@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748B26E@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748B5CB@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36EAFB565A8@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EAFB565A8@PUEXCB1B.nanterre.francetelecom.fr> 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: <473D2966349B0D409E760BFB71DABF2C@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" , Capello Alessandro Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 14 Feb 2013 17:44:03 -0000 On Feb 14, 2013, at 4:11 AM, mohamed.boucadair@orange.com wrote: > The analysis is meaningless in the lack of clear and precise requirements= .=20 The requirements are: we have a node that needs an IPv4 configuration on an= IPv6 network. In the context of using DHCP-based stateful configuration,= how do we configure the IPv4 stack in the host? Do you disagree with this? For your reference, here's what the abstract of the document says: In order to provision end-user's hosts with the necessary IPv4 configuration, a number of different mechanisms have been proposed. This memo discusses the benefits and drawbacks of each and recommend a single approach to use for the basis for future work. Is there some aspect of the problem that is not described in the abstract? = Do you have proposed text? From Tina.Tsou.Zouting@huawei.com Thu Feb 14 12:08:40 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF1321F892C for ; Thu, 14 Feb 2013 12:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.368 X-Spam-Level: X-Spam-Status: No, score=-4.368 tagged_above=-999 required=5 tests=[AWL=-1.972, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qd9DGICZRHW for ; Thu, 14 Feb 2013 12:08:39 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4522221F892B for ; Thu, 14 Feb 2013 12:08:39 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOL81638; Thu, 14 Feb 2013 20:08:38 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 14 Feb 2013 20:08:19 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 15 Feb 2013 04:08:37 +0800 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.165]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.007; Thu, 14 Feb 2013 12:08:34 -0800 From: Tina TSOU To: Ted Lemon , "dhcwg@ietf.org WG" Thread-Topic: Call for adoption: draft-rajtar-dhc-v4configuration Thread-Index: AQHOCLdJAJANwYon10iWTDBlj58gmJh5y+dQ Date: Thu, 14 Feb 2013 20:08:34 +0000 Message-ID: References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.34.91] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 14 Feb 2013 20:08:41 -0000 RGVhciBhbGwsDQpJIHRoaW5rIHRoZSBXRyBzaG91bGQgcHJvZHVjZSB0aGlzIGRvY3VtZW50Lg0K QlRXLCBIYXBweSBWYWxlbnRpbmUgdG8gZXZlcnlvbmUuDQoNCg0KVGhhbmsgeW91LA0KVGluYQ0K DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZGhjd2ctYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBU ZWQgTGVtb24NCj4gU2VudDogMjAxM8TqMtTCMTHI1SAxNjoyNA0KPiBUbzogZGhjd2dAaWV0Zi5v cmcgV0cNCj4gU3ViamVjdDogW2RoY3dnXSBDYWxsIGZvciBhZG9wdGlvbjogZHJhZnQtcmFqdGFy LWRoYy12NGNvbmZpZ3VyYXRpb24NCj4gDQo+IEF0IHRoZSBJRVRGIG1lZXRpbmcgaW4gQXRsYW50 YSwgd2UgZW5kZWQgdGhlIHNlc3Npb24gd2l0aCBhIGxvbmcgZGlzY3Vzc2lvbg0KPiBhYm91dCBo b3cgdG8gc29sdmUgdGhlIHByb2JsZW0gb2YgY29uZmlndXJpbmcgTUFQLUUgYW5kIGx3NG92ZXI2 IElQdjQgc3RhY2tzOw0KPiBzZXZlcmFsIHBvc3NpYmlsaXRpZXMgd2VyZSBwcmVzZW50ZWQsIGFu ZCB3ZSBkZWNpZGVkIHRoYXQgd2Ugd291bGQgd3JpdGUgYQ0KPiBkcmFmdCBzdW1tYXJpemluZyB0 aGVzZSBwb3NzaWJpbGl0aWVzIHNvIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgY291bGQgc3RhdGUN Cj4gYSBwcmVmZXJlbmNlLg0KPiANCj4gVGltZSB3ZW50IG9uLCBhbmQgbm9uZSBvZiB0aGUgcGVv cGxlIHdobyB2b2x1bnRlZXJlZCBhY3R1YWxseSBkaWQgYW55dGhpbmcsDQo+IHNvIGEgY291cGxl IG9mIHdlZWtzIGFnbyBCcmFuaW1pciBSYWp0YXIgYW5kIElhbiBGYXJyZXIgb2ZmZXJlZCB0byB3 cml0ZSBpdA0KPiB1cCBiYXNlZCBvbiB0aGUgbm90ZXMgZnJvbSB0aGUgbGFzdCBtZWV0aW5nLiAg IFRoZXkgaGF2ZSBkb25lIHNvLCBhbmQNCj4gc3VibWl0dGVkIGEgLTAwIGRyYWZ0OiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1yYWp0YXItZGhjLQ0KPiB2NGNvbmZpZ3Vy YXRpb24vDQo+IA0KPiBUaGUgcHVycG9zZSBvZiB0aGlzIGRyYWZ0IGlzIHRvIGVudW1lcmF0ZSBh bGwgdGhlIHBvdGVudGlhbCBzb2x1dGlvbnMgdG8NCj4gdGhpcyBwcm9ibGVtLCBkZXNjcmliZSB0 aGVpciBwcm9zIGFuZCBjb25zLCBhbmQgbWFrZSBhIHJlY29tbWVuZGF0aW9uLiAgIFRoZQ0KPiBj dXJyZW50IHN0YXRlIG9mIHRoZSBkcmFmdCBpcyB0aGUgcmVjb21tZW5kYXRpb24gdGhhdCBtb3N0 IHBlb3BsZSBzZWVtZWQgdG8NCj4gYmUgbGVhbmluZyB0b3dhcmQgYXQgdGhlIGVuZCBvZiB0aGUg bWVldGluZyBpbiBBdGxhbnRhLCBidXQgaXQncyBub3QgYmluZGluZzsNCj4gaWYgZHVyaW5nIGRp c2N1c3Npb24gdGhlIHdvcmtpbmcgZ3JvdXAgZGVjaWRlcyB0byByZWNvbW1lbmQgc29tZXRoaW5n IGVsc2UsDQo+IHRoZSBkb2N1bWVudCB3aWxsIGJlIHVwZGF0ZWQgdG8gcmVmbGVjdCB0aGF0Lg0K PiANCj4gSWYgeW91IHRoaW5rIHRoZSB3b3JraW5nIGdyb3VwIHNob3VsZCBpbiBmYWN0IHByb2R1 Y2UgdGhpcyBkb2N1bWVudCwgcGxlYXNlDQo+IHNheSBzbyBvbiB0aGUgbWFpbGluZyBsaXN0LiAg IElmIHlvdSB0aGluayB3ZSBzaG91bGRuJ3QgcHJvZHVjZSBzdWNoIGENCj4gZG9jdW1lbnQsIHBs ZWFzZSBhbHNvIHNheSBzby4gICBJZiB5b3UgaGF2ZSBjb21tZW50cyBvbiB0aGUgY29udGVudCBv ZiB0aGUNCj4gZG9jdW1lbnQsIHBsZWFzZSBob2xkIG9mZiBvbiB0aGF0IHVudGlsIGl0J3MgYmVl biBhZG9wdGVkLCBvciBub3QgYWRvcHRlZC4NCj4gSWYgaXQncyBub3QgYWRvcHRlZCwgdGhlIGNv bW1lbnRzIGFyZSBtb290OyBpZiBpdCBpcyBhZG9wdGVkLCB0aGUgam9iIG9mIHRoZQ0KPiB3b3Jr aW5nIGdyb3VwIHdpbGwgYmUgdG8gZmluaXNoIGl0IGFjY29yZGluZyB0byB0aGUgaW5wdXQgb2Yg d29ya2luZyBncm91cA0KPiBwYXJ0aWNpcGFudHMsIHdoaWNoIGlzIHdoZXJlIHlvdXIgY29tbWVu dHMgd291bGQgY29tZSBpbi4NCj4gDQo+IFdlIHdpbGwgZXZhbHVhdGUgY29uc2Vuc3VzIG9uIEZl YnJ1YXJ5IDI1Lg0KPiANCj4gVGhhbmtzIQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gZGhjd2cgbWFpbGluZyBsaXN0DQo+IGRoY3dnQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCg== From rdroms.ietf@gmail.com Thu Feb 14 13:27:03 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8CE621F8464 for ; Thu, 14 Feb 2013 13:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.539 X-Spam-Level: X-Spam-Status: No, score=-103.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1OUY7hO5lji for ; Thu, 14 Feb 2013 13:27:02 -0800 (PST) Received: from mail-vb0-f47.google.com (mail-vb0-f47.google.com [209.85.212.47]) by ietfa.amsl.com (Postfix) with ESMTP id EB38621F8906 for ; Thu, 14 Feb 2013 13:27:01 -0800 (PST) Received: by mail-vb0-f47.google.com with SMTP id e21so1786590vbm.6 for ; Thu, 14 Feb 2013 13:27:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version:x-mailer; bh=s8KDkOPgckBJgePl+uKXWsKfuGMFAyShaS2kkwplUwo=; b=jantU2UEPXDCDDio9K0nH8gxGOoFuseRl1/yotz6ISBFzIQyg8bohi1Sd6CMRKmonz eD+lZVg/U2nx11sMd95TLHqGJN9KXE63/MY/3FKNDLQ1WKJH3VVIQ5SJKNhTPvuYpPRk fjUfqxf72HslOg8gKskv8nYq+jIrmbdgW0G3X+GoMFLSgHQkYqCJZwMAq1/FwYdlaFnU Nk1HaogJ0qsKkbgi8HikyNeIZlrd4R6BtdhfgoaTbCY6iUK1zjt3Z4N7oe3qzBsHbFej gG6xW7shbk8+xn7kfT7GDyo6LiCIxO/5JeKn8zKsFiwCGSdAq4qh/EMJNBHDYJUjSQVI KNwA== X-Received: by 10.52.156.41 with SMTP id wb9mr173962vdb.65.1360877221237; Thu, 14 Feb 2013 13:27:01 -0800 (PST) Received: from ?IPv6:2001:420:2c51:1311:e123:1b78:f56b:cf9c? ([2001:420:2c51:1311:e123:1b78:f56b:cf9c]) by mx.google.com with ESMTPS id a19sm77799940vdh.9.2013.02.14.13.26.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Feb 2013 13:27:00 -0800 (PST) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <41A3E423-BA72-4FBA-ACD4-892615616396@gmail.com> Date: Thu, 14 Feb 2013 16:26:57 -0500 To: dhcwg@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [dhcwg] Management changes X-BeenThere: dhcwg@ietf.org 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, 14 Feb 2013 21:27:03 -0000 As many of you know, Ted Lemon has been chosen to be the next Internet = Area Director. Congratulations, Ted and thanks for your years of = leadership in the dhc WG. Ted will be stepping aside as dhc WG co-chair. I'm very pleased to = announce that Bernie Volz has agreed to become dhc WG co-chair, serving = with John Brzozowski who will be continuing as co-chair. - Ralph From iesg-secretary@ietf.org Thu Feb 14 13:39:50 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2183721F86C0; Thu, 14 Feb 2013 13:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abJnIYEYVTOs; Thu, 14 Feb 2013 13:39:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144A021F890E; Thu, 14 Feb 2013 13:39:48 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130214213948.11955.3082.idtracker@ietfa.amsl.com> Date: Thu, 14 Feb 2013 13:39:48 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] EXTENDED Last Call: (Client Link-layer Address Option in DHCPv6) to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 21:39:50 -0000 The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Client Link-layer Address Option in DHCPv6' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-02-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Note that this is an extension of the IETF last call that was originally announced on 2013-02-04. The IETF last call has been extended because of IPR disclosure 1710, which was published in reference to draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt. Because draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt is a predecessor to draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04.txt, IPR disclosure 1710 should be considered in this IETF last call. Abstract This document specifies the format and mechanism that is to be used for encoding client link-layer address in DHCPv6 Relay-Forward messages by defining a new DHCPv6 Client Link-layer Address option. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt/ballot/ IPR disclosure 1710 may be relevant to this document. From iesg-secretary@ietf.org Thu Feb 14 13:39:51 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E8A21F8639 for ; Thu, 14 Feb 2013 13:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IE3UcUrtYX3b; Thu, 14 Feb 2013 13:39:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160E721F8629; Thu, 14 Feb 2013 13:39:50 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.40 X-IETF-Draft-string: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt X-IETF-Draft-revision: 04 Message-ID: <20130214213950.11955.16194.idtracker@ietfa.amsl.com> Date: Thu, 14 Feb 2013 13:39:50 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] EXTENDED Last Call: (Client Link-layer Address Option in DHCPv6) to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 21:39:51 -0000 The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Client Link-layer Address Option in DHCPv6' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-02-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Note that this is an extension of the IETF last call that was originally announced on 2013-02-04. The IETF last call has been extended because of IPR disclosure 1710, which was published in reference to draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt. Because draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt is a predecessor to draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04.txt, IPR disclosure 1710 should be considered in this IETF last call. Abstract This document specifies the format and mechanism that is to be used for encoding client link-layer address in DHCPv6 Relay-Forward messages by defining a new DHCPv6 Client Link-layer Address option. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt/ballot/ IPR disclosure 1710 may be relevant to this document. From gvithal@gmail.com Thu Feb 14 19:13:48 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2691821F8659 for ; Thu, 14 Feb 2013 19:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHLkQH6kycJw for ; Thu, 14 Feb 2013 19:13:47 -0800 (PST) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id E22FC21F8658 for ; Thu, 14 Feb 2013 19:13:46 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id p1so1971927vcq.30 for ; Thu, 14 Feb 2013 19:13:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=M+rzMtczsSKSBFtynRVMqzaF2dFUCGdRFmwJxY4JmF8=; b=xkwrmsrp2fvSXvYpkyU8DQ9wXJ1kaNzHWctYsCNIRYawOq8gZIvgyJ2rKpq9zHmRR6 P1LuTROO0pcgiw4mXkWfTZeb4p0O+01e3WSuAvzxfz/KoW6ikWpVIg0I/tHgpQ81nNEp j166ZIt+/0wYS0nZbOEtjm12IB5tQhMEOYtdKGy7nwHDehTmRM9G/2i5Vf+22ZLkkx6z SfsNc5jKldiv5u0RGcy2RQX9nTy+UcAUDWIleLWPc4HVYDdwdzjGyJ8Fy6zZzmXw9iGC /o0dtT3LgjSfgjWPxUyam24ERDZ+eHAGAF3nCS6zG23PIglA53VkgqcOhkpOBWqIQ+PS OcMA== MIME-Version: 1.0 X-Received: by 10.58.253.161 with SMTP id ab1mr1178761ved.55.1360898026266; Thu, 14 Feb 2013 19:13:46 -0800 (PST) Received: by 10.59.6.134 with HTTP; Thu, 14 Feb 2013 19:13:46 -0800 (PST) In-Reply-To: <93B6C36C-3E9F-4D11-8C08-3BB482C4A470@cisco.com> References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> <8D23D4052ABE7A4490E77B1A012B63074747458F@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474754C3@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630747475B92@mbx-01.win.nominum.com> <510A6327.6050506@s-carlsen.dk> <489D13FBFA9B3E41812EA89F188F018E1844B249@xmb-rcd-x04.cisco.com> <1FF595DD-C7F5-475D-93BB-EC7E64428EBD@gmail.com> <93B6C36C-3E9F-4D11-8C08-3BB482C4A470@cisco.com> Date: Thu, 14 Feb 2013 19:13:46 -0800 Message-ID: From: VithalPrasad Gaitonde To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=047d7bdc9c106e602504d5bac3da Cc: Bud Millwood , Dmitry Anipko , Ralph Droms , "dhcwg@ietf.org" , Andre Kostur , Lemon Ted Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-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, 15 Feb 2013 03:13:48 -0000 --047d7bdc9c106e602504d5bac3da Content-Type: text/plain; charset=ISO-8859-1 Apparently, some relay agents/switches can be configured to relay packets based on the amount of time the client has been trying (elapsed time option). Similar language exists for the behavior of the DHCP server. >From RFC 3315 section 22.9 - Servers and Relay Agents use the data value in this option (elapsed time) as input to policy controlling how a server responds to a client message. For example, the elapsed time option allows a secondary DHCP server to respond to a request when a primary server has not answered in a reasonable time. When the client retransmits at every 1 hour interval, does the client reset the elapsed time option to 0. If yes, with the above mentioned behavior of relay agents and servers, the single retransmission of SOLICIT or INFORM will turn out inadequate. Also, given the unreliability of UDP, doing only one retransmission of the message every hour (beyond the first hour) may lead to situations where the server does not see the request and the client has to wait for another hour to get an IPv6 address or options. Instead of making just a single retransmission at every 1 hour interval, the client should make at least a couple of retransmissions to increase the reliability of getting an IPv6 address or options from the server. Thanks, Prasad On Fri, Feb 1, 2013 at 8:10 PM, Bernie Volz (volz) wrote: > Fine by me too. > > - Bernie > > On Feb 1, 2013, at 9:52 PM, "Dmitry Anipko" > wrote: > > >>> A client is not expected to listen for a response during the entire > period between transmission of Solicit or Information-Request messages > > > > Looks good to me. > > > > Thanks. > > > > -----Original Message----- > > From: Ralph Droms [mailto:rdroms.ietf@gmail.com] > > Sent: Friday, February 01, 2013 6:08 PM > > To: Dmitry Anipko > > Cc: Bernie Volz (volz); Bud Millwood; Sten Carlsen; dhcwg@ietf.org; > Andre Kostur; Lemon Ted > > Subject: Re: [dhcwg] I-D Action: > draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt > > > > (resending to dhcwg mailing list) > > > > On Feb 1, 2013, at 5:59 PM 2/1/13, Dmitry Anipko < > Dmitry.Anipko@microsoft.com> > > wrote: > > > >> Agree with everything you wrote. I think several minutes waiting would > be fine, and I understand there may be good reasons for such waiting > interval (as opposed to hour). > >> > >> If there is a general agreement on these 2 adjustments (allowed waiting > period cap and INF_MAX_RT default), how do we move forward - Ralph, can > these be included in the next revision of the draft? > >> > >> Thank you. > > > > Adding INF_MAX_RT makes sense. > > > > In my opinion, the right thing to say about waiting for a response is > something vague, to the effect of "A client is not expected to listen for a > response during the entire period between transmission of Solicit or > Information-Request messages." > > > > - Ralph > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --047d7bdc9c106e602504d5bac3da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Apparently, some relay agents/switches can be configured to relay pack= ets based on the amount of time the client has been trying (elapsed time op= tion). Similar language exists for the behavior of the DHCP server.
=A0
From RFC 3315 section 22.9 -
Servers and Rela= y Agents use the data value in this option (elapsed time)
=A0=A0 as inpu= t to policy controlling how a server responds to a client
=A0=A0 message= .=A0 For example, the elapsed time option allows a secondary
=A0=A0 DHCP server to respond to a request when a primary server has not=A0=A0 answered in a reasonable time.
=A0
When the cli= ent retransmits at every 1 hour interval, does the client reset the elapsed= time option to 0. If yes, with the above mentioned behavior of relay agent= s and servers, the single retransmission of SOLICIT or INFORM will turn out= inadequate.
Also, given the unreliability of UDP, doing only one retransmiss= ion of the message every hour (beyond the first hour) may lead to situation= s where the server does not see the request and the client has to wait for = another hour to get an IPv6 address or options.
=A0
Instead of making just a single retransmission at every = 1 hour interval, the client should make at least=A0a couple of=A0retransmis= sions to increase the reliability of getting an IPv6 address or options fro= m the server.
=A0
Thanks,
Prasad
On Fri, Feb 1, 2013 at 8:10 PM, Bernie Volz (volz) &= lt;volz@cisco.com&g= t; wrote:
Fine by me too.

- Bernie

On Feb 1, 2013, at 9:52 PM, "Dmitry Anipko" <Dmitry.Anipko@microsoft.com> wrote:
>>> A client is not expected to listen for a response during the e= ntire period between transmission of Solicit or Information-Request message= s
>
> Looks good to me.
>
> Thanks.
>
> -----Original Message-----
> From: Ralph Droms [mailto:rdr= oms.ietf@gmail.com]
> Sent: Friday, February 01, 2013 6:08 PM
> To: Dmitry Anipko
> Cc: Bernie Volz (volz); Bud Millwood; Sten Carlsen; dhcwg@ietf.org; Andre Kostur; Lemon Ted
> Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update= -00.txt
>
> (resending to dhcwg mailing list)
>
> On Feb 1, 2013, at 5:59 PM 2/1/13, Dmitry Anipko <Dmitry.Anipko@microsoft.com>
> wrote:
>
>> Agree with everything you wrote. I think several minutes waiting w= ould be fine, and I understand there may be good reasons for such waiting i= nterval (as opposed to hour).
>>
>> If there is a general agreement on these 2 adjustments (allowed wa= iting period cap and INF_MAX_RT default), how do we move forward - Ralph, c= an these be included in the next revision of the draft?
>>
>> Thank you.
>
> Adding INF_MAX_RT makes sense.
>
> In my opinion, the right thing to say about waiting for a response is = something vague, to the effect of "A client is not expected to listen = for a response during the entire period between transmission of Solicit or = Information-Request messages."
>
> - Ralph
>
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

--047d7bdc9c106e602504d5bac3da-- From mohamed.boucadair@orange.com Fri Feb 15 00:35:34 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9891721F867B for ; Fri, 15 Feb 2013 00:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esIQVSgQJrWm for ; Fri, 15 Feb 2013 00:35:34 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id D699B21F8621 for ; Fri, 15 Feb 2013 00:35:33 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 3871C22C6FA; Fri, 15 Feb 2013 09:35:33 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 192FE23805E; Fri, 15 Feb 2013 09:35:33 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Fri, 15 Feb 2013 09:35:32 +0100 From: To: Ted Lemon Date: Fri, 15 Feb 2013 09:35:31 +0100 Thread-Topic: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration Thread-Index: AQHOCLdJAJANwYon10iWTDBlj58gmJh3pPhggACyx4CAAAFgAIAABnQAgAAVjoCAAA4xAIAAHkIAgAACF4CAAAmrgIAAGHmAgABLKRCAARlygIAAbz9w Message-ID: <94C682931C08B048B7A8645303FDC9F36EAFB569D6@PUEXCB1B.nanterre.francetelecom.fr> References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE519D1A750C@GRFMBX704BA020.griffon.local> <8D23D4052ABE7A4490E77B1A012B63074748A45A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748A6BA@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748ACB3@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748B26E@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748B5CB@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36EAFB565A8@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B63074748CE40@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074748CE40@mbx-01.win.nominum.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: "dhcwg@ietf.org WG" , Capello Alessandro Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 15 Feb 2013 08:35:34 -0000 Hi Ted, The question we have right now is closely related to softwire work. The IPv= 4 configuration (mainly an IPv4 address and optionally a set of port) shoul= d satisfy the following requirements: * the solutions should accommodate deployment contexts where no dhcpv4 is d= eployed. * the solution should accommodate IPv4 service continuity mechanisms which = assumes a full dependency between an IPv4 address and IPv6 prefix. * the solution should help in simplifying network operations when migrating= to IPv6; in particular IPv4-only network services should not be required f= or operating an IPv6 network over which IPv4 service is offered. * the solution should not optimize as much as possible required features to= be activated in the network compared to a dual-stack model (e.g., this has= a direct constraint on dhcp relay falvors to be embedded in the IP access = node). Note that all solutions discussed in softwire do not require extra IPv4 con= figuration (than the IPv4 address:[port set]). No IPv4 DNS server is needed= for instance. The provisioning discussion is also part of: http://tools.ietf.org/html/dra= ft-bfmk-softwire-unified-cpe-02.=20 Cheers, Med =20 >-----Message d'origine----- >De : Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 >Envoy=E9 : jeudi 14 f=E9vrier 2013 18:44 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : Wojciech Dec; dhcwg@ietf.org WG; Capello Alessandro >Objet : Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration > >On Feb 14, 2013, at 4:11 AM, mohamed.boucadair@orange.com wrote: >> The analysis is meaningless in the lack of clear and precise=20 >requirements.=20 > >The requirements are: we have a node that needs an IPv4=20 >configuration on an IPv6 network. In the context of using=20 >DHCP-based stateful configuration, how do we configure the=20 >IPv4 stack in the host? > >Do you disagree with this? > >For your reference, here's what the abstract of the document says: > > In order to provision end-user's hosts with the necessary IPv4 > configuration, a number of different mechanisms have been proposed. > This memo discusses the benefits and drawbacks of each and recommend > a single approach to use for the basis for future work. > >Is there some aspect of the problem that is not described in=20 >the abstract? Do you have proposed text? > >= From mohamed.boucadair@orange.com Fri Feb 15 00:38:32 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19BDE21F86AF for ; Fri, 15 Feb 2013 00:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vu8qjsW4Sj40 for ; Fri, 15 Feb 2013 00:38:31 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id DB73721F867B for ; Fri, 15 Feb 2013 00:38:30 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 9AF243B42BD; Fri, 15 Feb 2013 09:38:29 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 800024C024; Fri, 15 Feb 2013 09:38:29 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Fri, 15 Feb 2013 09:38:29 +0100 From: To: Ted Lemon Date: Fri, 15 Feb 2013 09:38:28 +0100 Thread-Topic: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration Thread-Index: AQHOCLdJAJANwYon10iWTDBlj58gmJh3pPhggACyx4CAAAFgAIAABnQAgAAVjoCAAA4xAIAAHkIAgAACF4CAAAmrgIAAGHmAgABLKRCAARlygIAAbz9wgAAEVQA= Message-ID: <94C682931C08B048B7A8645303FDC9F36EAFB569DB@PUEXCB1B.nanterre.francetelecom.fr> References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE519D1A750C@GRFMBX704BA020.griffon.local> <8D23D4052ABE7A4490E77B1A012B63074748A45A@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748A6BA@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748ACB3@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748B26E@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748B5CB@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36EAFB565A8@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B63074748CE40@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36EAFB569D6@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EAFB569D6@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: 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.10.24.110314 Cc: "dhcwg@ietf.org WG" , Capello Alessandro Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 15 Feb 2013 08:38:32 -0000 One correction inline. =20 >-----Message d'origine----- >De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De=20 >la part de mohamed.boucadair@orange.com >Envoy=E9 : vendredi 15 f=E9vrier 2013 09:36 >=C0 : Ted Lemon >Cc : dhcwg@ietf.org WG; Capello Alessandro >Objet : Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration > >Hi Ted, > >The question we have right now is closely related to softwire=20 >work. The IPv4 configuration (mainly an IPv4 address and=20 >optionally a set of port) should satisfy the following requirements: > >* the solutions should accommodate deployment contexts where=20 >no dhcpv4 is deployed. >* the solution should accommodate IPv4 service continuity=20 >mechanisms which assumes a full dependency between an IPv4=20 >address and IPv6 prefix. >* the solution should help in simplifying network operations=20 >when migrating to IPv6; in particular IPv4-only network=20 >services should not be required for operating an IPv6 network=20 >over which IPv4 service is offered. >* the solution should not optimize as much as possible=20 Med: s/should not/should. >required features to be activated in the network compared to a=20 >dual-stack model (e.g., this has a direct constraint on dhcp=20 >relay falvors to be embedded in the IP access node). > >Note that all solutions discussed in softwire do not require=20 >extra IPv4 configuration (than the IPv4 address:[port set]).=20 >No IPv4 DNS server is needed for instance. > >The provisioning discussion is also part of:=20 >http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-02.=20 > >Cheers, >Med >=20 > >>-----Message d'origine----- >>De : Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 >>Envoy=E9 : jeudi 14 f=E9vrier 2013 18:44 >>=C0 : BOUCADAIR Mohamed OLNC/OLN >>Cc : Wojciech Dec; dhcwg@ietf.org WG; Capello Alessandro >>Objet : Re: [dhcwg] Call for adoption:=20 >draft-rajtar-dhc-v4configuration >> >>On Feb 14, 2013, at 4:11 AM, mohamed.boucadair@orange.com wrote: >>> The analysis is meaningless in the lack of clear and precise=20 >>requirements.=20 >> >>The requirements are: we have a node that needs an IPv4=20 >>configuration on an IPv6 network. In the context of using=20 >>DHCP-based stateful configuration, how do we configure the=20 >>IPv4 stack in the host? >> >>Do you disagree with this? >> >>For your reference, here's what the abstract of the document says: >> >> In order to provision end-user's hosts with the necessary IPv4 >> configuration, a number of different mechanisms have been proposed. >> This memo discusses the benefits and drawbacks of each and=20 >recommend >> a single approach to use for the basis for future work. >> >>Is there some aspect of the problem that is not described in=20 >>the abstract? Do you have proposed text? >> >> >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg >= From Ted.Lemon@nominum.com Fri Feb 15 06:26:34 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB22821F89C5 for ; Fri, 15 Feb 2013 06:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.58 X-Spam-Level: X-Spam-Status: No, score=-106.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWFSxYE3YBdy for ; Fri, 15 Feb 2013 06:26:34 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3636221F846E for ; Fri, 15 Feb 2013 06:26:34 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUR5FmqDegR1fB+nypeahzJlLxE4Ilkz3@postini.com; Fri, 15 Feb 2013 06:26:34 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id CBBF11B82DA for ; Fri, 15 Feb 2013 06:26:33 -0800 (PST) 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 C1882190043; Fri, 15 Feb 2013 06:26:33 -0800 (PST) (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.0318.004; Fri, 15 Feb 2013 06:26:33 -0800 From: Ted Lemon To: "dhcwg@ietf.org WG" Thread-Topic: Call for adoption: draft-rajtar-dhc-v4configuration Thread-Index: AQHOCLdJAJANwYon10iWTDBlj58gmJh5y+dQgAG5roA= Date: Fri, 15 Feb 2013 14:26:33 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074748F074@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.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="GB18030" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 15 Feb 2013 14:26:35 -0000 There's been a lot of pushback on adopting this document; some of this I th= ink is motivated by the fact that the document came with a conclusion, and = people who disagree with this conclusion don't want to be seen as endorsing= it by agreeing to adopt the document. This is not the authors' fault=A1= =AAwhen we talked about this, I told them I thought it was okay to state a = conclusion, which in retrospect was a mistake. So I'd like to propose that we stop the call for adoption on this version o= f the document now, and that the authors reissue the document, without the = recommendation section, and with the addition of Roberta's argument in favo= r of a DHCPv6-only solution, which I think captures the real issue best. Would the authors be willing to do this? From ian.farrer@telekom.de Fri Feb 15 08:18:14 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29B121F88C7 for ; Fri, 15 Feb 2013 08:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWo7O6MnOIPB for ; Fri, 15 Feb 2013 08:18:14 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB1B21F861F for ; Fri, 15 Feb 2013 08:18:13 -0800 (PST) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 15 Feb 2013 17:18:12 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by he110890 ([10.134.92.131]) with mapi; Fri, 15 Feb 2013 17:18:12 +0100 From: To: , Date: Fri, 15 Feb 2013 17:18:10 +0100 Thread-Topic: Call for adoption: draft-rajtar-dhc-v4configuration Thread-Index: Ac4LmAz03J2e4o78TzyPkfvKrYadow== Message-ID: In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074748F074@mbx-01.win.nominum.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration X-BeenThere: dhcwg@ietf.org 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, 15 Feb 2013 16:18:14 -0000 Hi, We've made those changes and posted a new version. Cheers, Ian On 15/02/2013 15:26, "Ted Lemon" wrote: >There's been a lot of pushback on adopting this document; some of this I >think is motivated by the fact that the document came with a conclusion, >and people who disagree with this conclusion don't want to be seen as >endorsing it by agreeing to adopt the document. This is not the >authors' fault=8Bwhen we talked about this, I told them I thought it was >okay to state a conclusion, which in retrospect was a mistake. > >So I'd like to propose that we stop the call for adoption on this version >of the document now, and that the authors reissue the document, without >the recommendation section, and with the addition of Roberta's argument >in favor of a DHCPv6-only solution, which I think captures the real issue >best. > >Would the authors be willing to do this? > From volz@cisco.com Fri Feb 15 14:44:44 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C736021F8556 for ; Fri, 15 Feb 2013 14:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwm8k6Z433Jf for ; Fri, 15 Feb 2013 14:44:41 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id D820A21F854C for ; Fri, 15 Feb 2013 14:44:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23538; q=dns/txt; s=iport; t=1360968280; x=1362177880; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2ZblQLaWOmEf91/2tPzhgMqZUHAWr2fUCDBN4dNjN4I=; b=DmiXubdcA0xAmqunkOhSQWFo/cTxbKRbeNJVo9BOelgJFhBARoy/b50j ow3ROg16f04Bk9CxolVTg8NcUzVwA8iOQ3hRyIo2b7nJA782fmvS0F8mK Uw+nX3ro1TDu3+TqeLbXIMCU4ZP/jEs+5nv7sa6R6sEUDKE7Xo4Mik0HZ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFABK6HlGtJV2a/2dsb2JhbABEgkO9Tn0Wc4IfAQEBAwEBAQEqQQsMBAIBCBEEAQEBChYHByEGCxQJCAIEDgUIh3gDCQYMtAENiVYEjFKCKAYHGQcEBgECBIJZYQOUTo0chRODB4In X-IronPort-AV: E=Sophos;i="4.84,675,1355097600"; d="scan'208,217";a="177521443" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 15 Feb 2013 22:44:38 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1FMicrl005193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Feb 2013 22:44:38 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Fri, 15 Feb 2013 16:44:38 -0600 From: "Bernie Volz (volz)" To: VithalPrasad Gaitonde Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt Thread-Index: AQHN2aLtf97Q/V2yEUWdCx2wJ5mS4phWkuiAgAPtq4CAAAO7AIAEG3nDgANu8ACAAHd7gIAADdqAgABaxPCAAA4bAIAAAv0AgACPRYCAABelAIAAAoeAgAAf1ACAAFAk8IABY85ggABtj4CAAJrLAIAADG6A//+xX5qAFML4AIAA1sUw Date: Fri, 15 Feb 2013 22:44:37 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1846E736@xmb-rcd-x04.cisco.com> References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> <8D23D4052ABE7A4490E77B1A012B63074747458F@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474754C3@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630747475B92@mbx-01.win.nominum.com> <510A6327.6050506@s-carlsen.dk> <489D13FBFA9B3E41812EA89F188F018E1844B249@xmb-rcd-x04.cisco.com> <1FF595DD-C7F5-475D-93BB-EC7E64428EBD@gmail.com> <93B6C36C-3E9F-4D11-8C08-3BB482C4A470@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.89.9.178] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1846E736xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: Dmitry Anipko , Bud Millwood , Ralph Droms , "dhcwg@ietf.org" , Andre Kostur , Lemon Ted Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-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, 15 Feb 2013 22:44:44 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1846E736xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (I guess I should now start saying "WG co-chair hat off" ...) Interesting points. The elapsed time option only supports 16-bits and is in 100ths of a second,= so it will max out at 655.35 seconds (under 11 minutes). As these are a 'retransmission' and so the XID would be the same and the el= apsed time should reflect the time since the client started (obviously maxi= ng out at a value of 0xffff as documented in RFC 3315). Regarding the single packet issue ... I see: 1. Let it be. If the original retransmissions up this point didn't wo= rk, what's the chance that it will work now? And a single packet should gen= erally be OK. Though there may be some ND implementations that drop a packe= t they can't send instead of holding onto at least that one packet and that= might cause things to fail 'forever' (the server-to-client or relay-to-cli= ent ND entry would expire before the next packet arrives). 2. Have the client could 'restart' the Solicit process instead of usi= ng the longer time as a cap to the retransmission delay. But this means tha= t the client would send restart sending at the normal backoff intervals and= that makes the clients (if there are a lot) very chatty in total - which i= s what we wanted to prevent. This would also mean a new XID and new elapsed= time base. 3. Complicate the retransmission algorithm to allow some small number= (2 or 3) packets in a "shorter" interval after 'long' retransmission inter= val (this is what you suggested). Probably these should occur well within t= he typical ND cache expiration interval. 4. Something else? (Document that not retaining a packet per destinat= ion when needing ND is a bad idea.) 2 may be the most attractive as it is much simpler (and means this document= would define an MRD for Solicit too). But the long delay between retransmi= ssions leading up to the maximum may also suffer from the issue mentioned i= n #1, so #3 may have the best merit. - Bernie From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of V= ithalPrasad Gaitonde Sent: Thursday, February 14, 2013 10:14 PM To: Bernie Volz (volz) Cc: Bud Millwood; Dmitry Anipko; Ralph Droms; dhcwg@ietf.org; Andre Kostur;= Lemon Ted Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.t= xt Apparently, some relay agents/switches can be configured to relay packets b= ased on the amount of time the client has been trying (elapsed time option)= . Similar language exists for the behavior of the DHCP server. >From RFC 3315 section 22.9 - Servers and Relay Agents use the data value in this option (elapsed time) as input to policy controlling how a server responds to a client message. For example, the elapsed time option allows a secondary DHCP server to respond to a request when a primary server has not answered in a reasonable time. When the client retransmits at every 1 hour interval, does the client reset= the elapsed time option to 0. If yes, with the above mentioned behavior of= relay agents and servers, the single retransmission of SOLICIT or INFORM w= ill turn out inadequate. Also, given the unreliability of UDP, doing only one retransmission of the = message every hour (beyond the first hour) may lead to situations where the= server does not see the request and the client has to wait for another hou= r to get an IPv6 address or options. Instead of making just a single retransmission at every 1 hour interval, th= e client should make at least a couple of retransmissions to increase the r= eliability of getting an IPv6 address or options from the server. Thanks, Prasad On Fri, Feb 1, 2013 at 8:10 PM, Bernie Volz (volz) > wrote: Fine by me too. - Bernie On Feb 1, 2013, at 9:52 PM, "Dmitry Anipko" > wrote: >>> A client is not expected to listen for a response during the entire per= iod between transmission of Solicit or Information-Request messages > > Looks good to me. > > Thanks. > > -----Original Message----- > From: Ralph Droms [mailto:rdroms.ietf@gmail.com] > Sent: Friday, February 01, 2013 6:08 PM > To: Dmitry Anipko > Cc: Bernie Volz (volz); Bud Millwood; Sten Carlsen; dhcwg@ietf.org; Andre Kostur; Lemon Ted > Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00= .txt > > (resending to dhcwg mailing list) > > On Feb 1, 2013, at 5:59 PM 2/1/13, Dmitry Anipko > > wrote: > >> Agree with everything you wrote. I think several minutes waiting would b= e fine, and I understand there may be good reasons for such waiting interva= l (as opposed to hour). >> >> If there is a general agreement on these 2 adjustments (allowed waiting = period cap and INF_MAX_RT default), how do we move forward - Ralph, can the= se be included in the next revision of the draft? >> >> Thank you. > > Adding INF_MAX_RT makes sense. > > In my opinion, the right thing to say about waiting for a response is som= ething vague, to the effect of "A client is not expected to listen for a re= sponse during the entire period between transmission of Solicit or Informat= ion-Request messages." > > - Ralph > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --_000_489D13FBFA9B3E41812EA89F188F018E1846E736xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(I guess I should now sta= rt saying “WG co-chair hat off” …)

 <= /p>

Interesting points.<= /o:p>

 <= /p>

The elapsed time option o= nly supports 16-bits and is in 100ths of a second, so it will max out at 65= 5.35 seconds (under 11 minutes).

 <= /p>

As these are a ‘ret= ransmission’ and so the XID would be the same and the elapsed time sh= ould reflect the time since the client started (obviously maxing out at a value of 0xffff as documented in RFC 3315).

 <= /p>

Regarding the single pack= et issue … I see:

1. = ;      Let it be. If the= original retransmissions up this point didn’t work, what’s the= chance that it will work now? And a single packet should generally be OK. Though there may be some ND implementations that drop a packet they= can’t send instead of holding onto at least that one packet and that= might cause things to fail ‘forever’ (the server-to-client or = relay-to-client ND entry would expire before the next packet arrives).

2. = ;      Have the client c= ould ‘restart’ the Solicit process instead of using the longer = time as a cap to the retransmission delay. But this means that the client would send restart sending at the normal backoff intervals and that= makes the clients (if there are a lot) very chatty in total – which = is what we wanted to prevent. This would also mean a new XID and new elapse= d time base.

3. = ;      Complicate the re= transmission algorithm to allow some small number (2 or 3) packets in a = 220;shorter” interval after ‘long’ retransmission interva= l (this is what you suggested). Probably these should occur well within the typica= l ND cache expiration interval.

4. = ;      Something else? (= Document that not retaining a packet per destination when needing ND is a b= ad idea.)

 <= /p>

2 may be the most attract= ive as it is much simpler (and means this document would define an MRD for = Solicit too). But the long delay between retransmissions leading up to the maximum may also suffer from the issue mentioned in #1, = so #3 may have the best merit.

 <= /p>

- =          Bernie=

 <= /p>

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of VithalPrasad Gaitonde
Sent: Thursday, February 14, 2013 10:14 PM
To: Bernie Volz (volz)
Cc: Bud Millwood; Dmitry Anipko; Ralph Droms; dhcwg@ietf.org; Andre = Kostur; Lemon Ted
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-upda= te-00.txt

 

Apparently, some relay agents/switches can be config= ured to relay packets based on the amount of time the client has been tryin= g (elapsed time option). Similar language exists for the behavior of the DH= CP server.

 

From RFC 3315 section 22.9 -

Servers and Relay Agents use the data value in this = option (elapsed time)
   as input to policy controlling how a server responds to a clie= nt
   message.  For example, the elapsed time option allows a s= econdary
   DHCP server to respond to a request when a primary server has = not
   answered in a reasonable time.

 

When the client retransmits at every 1 hour interval= , does the client reset the elapsed time option to 0. If yes, with the abov= e mentioned behavior of relay agents and servers, the single retransmission= of SOLICIT or INFORM will turn out inadequate.

Also, given the unreliability of UDP, doing only one= retransmission of the message every hour (beyond the first hour) may lead = to situations where the server does not see the request and the client has = to wait for another hour to get an IPv6 address or options.

 

Instead of making just a single retransmission at ev= ery 1 hour interval, the client should make at least a couple of = retransmissions to increase the reliability of getting an IPv6 address or o= ptions from the server.

 

Thanks,

Prasad

On Fri, Feb 1, 2013 at 8:10 PM, Bernie Volz (volz) &= lt;volz@cisco.com&g= t; wrote:

Fine by me too.

- Bernie


On Feb 1, 2013, at 9:52 PM, "Dmitry Anipko" <Dmitry.Anipko@microsoft.com> wrote:
>>> A client is not expected to listen for a response during the e= ntire period between transmission of Solicit or Information-Request message= s
>
> Looks good to me.
>
> Thanks.
>
> -----Original Message-----
> From: Ralph Droms [mailto:rdr= oms.ietf@gmail.com]
> Sent: Friday, February 01, 2013 6:08 PM
> To: Dmitry Anipko
> Cc: Bernie Volz (volz); Bud Millwood; Sten Carlsen; dhcwg@ietf.org; Andre Kostur; Lemon Ted
> Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update= -00.txt
>
> (resending to dhcwg mailing list)
>
> On Feb 1, 2013, at 5:59 PM 2/1/13, Dmitry Anipko <Dmitry.Anipko@microsoft.com>
> wrote:
>
>> Agree with everything you wrote. I think several minutes waiting w= ould be fine, and I understand there may be good reasons for such waiting i= nterval (as opposed to hour).
>>
>> If there is a general agreement on these 2 adjustments (allowed wa= iting period cap and INF_MAX_RT default), how do we move forward - Ralph, c= an these be included in the next revision of the draft?
>>
>> Thank you.
>
> Adding INF_MAX_RT makes sense.
>
> In my opinion, the right thing to say about waiting for a response is = something vague, to the effect of "A client is not expected to listen = for a response during the entire period between transmission of Solicit or = Information-Request messages."
>
> - Ralph
>
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

 

--_000_489D13FBFA9B3E41812EA89F188F018E1846E736xmbrcdx04ciscoc_-- From Dmitry.Anipko@microsoft.com Fri Feb 15 19:12:13 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA10C11E80A3 for ; Fri, 15 Feb 2013 19:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MqvxEMGZZA8 for ; Fri, 15 Feb 2013 19:12:09 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3E51B21F856F for ; Fri, 15 Feb 2013 19:12:08 -0800 (PST) Received: from BL2FFO11FD022.protection.gbl (10.173.161.203) by BL2FFO11HUB005.protection.gbl (10.173.160.225) with Microsoft SMTP Server (TLS) id 15.0.620.12; Sat, 16 Feb 2013 03:12:06 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD022.mail.protection.outlook.com (10.173.161.101) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Sat, 16 Feb 2013 03:12:06 +0000 Received: from TK5EX14MBXC254.redmond.corp.microsoft.com ([169.254.2.84]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Sat, 16 Feb 2013 03:11:51 +0000 From: Dmitry Anipko To: "Bernie Volz (volz)" , VithalPrasad Gaitonde Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt Thread-Index: AQHN2aLtf97Q/V2yEUWdCx2wJ5mS4phWkuiAgAPtq4CAAAO7AIAEG3nDgANu8ACAAHd7gIAADdqAgABaxPCAAA4bAIAAAv0AgACPRYCAABelAIAAAoeAgAAf1ACAAFAk8IABY85ggABtj4CAADY2AIAADETQgAAWHwCAFF5hAIABRyKAgABJg0A= Date: Sat, 16 Feb 2013 03:11:50 +0000 Message-ID: References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> <8D23D4052ABE7A4490E77B1A012B63074747458F@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474754C3@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630747475B92@mbx-01.win.nominum.com> <510A6327.6050506@s-carlsen.dk> <489D13FBFA9B3E41812EA89F188F018E1844B249@xmb-rcd-x04.cisco.com> <1FF595DD-C7F5-475D-93BB-EC7E64428EBD@gmail.com> <93B6C36C-3E9F-4D11-8C08-3BB482C4A470@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1846E736@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1846E736@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.23] Content-Type: multipart/alternative; boundary="_000_FB329D818C7CAB438F0C7DD772EA1025062001BCTK5EX14MBXC254r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(479174001)(377454001)(24454001)(51704002)(199002)(189002)(13464002)(164054002)(79102001)(47446002)(44976002)(65816001)(512954001)(5343655001)(74662001)(55846006)(66066001)(74502001)(53806001)(50986001)(15202345001)(80022001)(5343635001)(49866001)(54356001)(47736001)(47976001)(54316002)(4396001)(56776001)(33656001)(59766001)(76482001)(20776003)(16406001)(77982001)(46102001)(16236675001)(51856001)(63696002)(31966008)(56816002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB005; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0759F7A50A Cc: "dhcwg@ietf.org" , Andre Kostur , Lemon Ted , Ralph Droms , Bud Millwood Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-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: Sat, 16 Feb 2013 03:12:13 -0000 --_000_FB329D818C7CAB438F0C7DD772EA1025062001BCTK5EX14MBXC254r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My understanding is that (2) would be against one of the motivations for th= e draft - reduce load on servers, as you pointed out. So I agree (3) would be better, if at all something needs to be done for th= is issue. From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Friday, February 15, 2013 2:45 PM To: VithalPrasad Gaitonde Cc: Bud Millwood; Dmitry Anipko; Ralph Droms; dhcwg@ietf.org; Andre Kostur;= Lemon Ted Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.t= xt (I guess I should now start saying "WG co-chair hat off" ...) Interesting points. The elapsed time option only supports 16-bits and is in 100ths of a second,= so it will max out at 655.35 seconds (under 11 minutes). As these are a 'retransmission' and so the XID would be the same and the el= apsed time should reflect the time since the client started (obviously maxi= ng out at a value of 0xffff as documented in RFC 3315). Regarding the single packet issue ... I see: 1. Let it be. If the original retransmissions up this point didn't wo= rk, what's the chance that it will work now? And a single packet should gen= erally be OK. Though there may be some ND implementations that drop a packe= t they can't send instead of holding onto at least that one packet and that= might cause things to fail 'forever' (the server-to-client or relay-to-cli= ent ND entry would expire before the next packet arrives). 2. Have the client could 'restart' the Solicit process instead of usi= ng the longer time as a cap to the retransmission delay. But this means tha= t the client would send restart sending at the normal backoff intervals and= that makes the clients (if there are a lot) very chatty in total - which i= s what we wanted to prevent. This would also mean a new XID and new elapsed= time base. 3. Complicate the retransmission algorithm to allow some small number= (2 or 3) packets in a "shorter" interval after 'long' retransmission inter= val (this is what you suggested). Probably these should occur well within t= he typical ND cache expiration interval. 4. Something else? (Document that not retaining a packet per destinat= ion when needing ND is a bad idea.) 2 may be the most attractive as it is much simpler (and means this document= would define an MRD for Solicit too). But the long delay between retransmi= ssions leading up to the maximum may also suffer from the issue mentioned i= n #1, so #3 may have the best merit. - Bernie From: dhcwg-bounces@ietf.org [mailto:dhcwg-b= ounces@ietf.org] On Behalf Of VithalPrasad Gaitonde Sent: Thursday, February 14, 2013 10:14 PM To: Bernie Volz (volz) Cc: Bud Millwood; Dmitry Anipko; Ralph Droms; dhcwg@ietf.org; Andre Kostur; Lemon Ted Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.t= xt Apparently, some relay agents/switches can be configured to relay packets b= ased on the amount of time the client has been trying (elapsed time option)= . Similar language exists for the behavior of the DHCP server. >From RFC 3315 section 22.9 - Servers and Relay Agents use the data value in this option (elapsed time) as input to policy controlling how a server responds to a client message. For example, the elapsed time option allows a secondary DHCP server to respond to a request when a primary server has not answered in a reasonable time. When the client retransmits at every 1 hour interval, does the client reset= the elapsed time option to 0. If yes, with the above mentioned behavior of= relay agents and servers, the single retransmission of SOLICIT or INFORM w= ill turn out inadequate. Also, given the unreliability of UDP, doing only one retransmission of the = message every hour (beyond the first hour) may lead to situations where the= server does not see the request and the client has to wait for another hou= r to get an IPv6 address or options. Instead of making just a single retransmission at every 1 hour interval, th= e client should make at least a couple of retransmissions to increase the r= eliability of getting an IPv6 address or options from the server. Thanks, Prasad On Fri, Feb 1, 2013 at 8:10 PM, Bernie Volz (volz) > wrote: Fine by me too. - Bernie On Feb 1, 2013, at 9:52 PM, "Dmitry Anipko" > wrote: >>> A client is not expected to listen for a response during the entire per= iod between transmission of Solicit or Information-Request messages > > Looks good to me. > > Thanks. > > -----Original Message----- > From: Ralph Droms [mailto:rdroms.ietf@gmail.com] > Sent: Friday, February 01, 2013 6:08 PM > To: Dmitry Anipko > Cc: Bernie Volz (volz); Bud Millwood; Sten Carlsen; dhcwg@ietf.org; Andre Kostur; Lemon Ted > Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00= .txt > > (resending to dhcwg mailing list) > > On Feb 1, 2013, at 5:59 PM 2/1/13, Dmitry Anipko > > wrote: > >> Agree with everything you wrote. I think several minutes waiting would b= e fine, and I understand there may be good reasons for such waiting interva= l (as opposed to hour). >> >> If there is a general agreement on these 2 adjustments (allowed waiting = period cap and INF_MAX_RT default), how do we move forward - Ralph, can the= se be included in the next revision of the draft? >> >> Thank you. > > Adding INF_MAX_RT makes sense. > > In my opinion, the right thing to say about waiting for a response is som= ething vague, to the effect of "A client is not expected to listen for a re= sponse during the entire period between transmission of Solicit or Informat= ion-Request messages." > > - Ralph > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --_000_FB329D818C7CAB438F0C7DD772EA1025062001BCTK5EX14MBXC254r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My understanding is that = (2) would be against one of the motivations for the draft – reduce lo= ad on servers, as you pointed out.

 <= /p>

So I agree (3) would be b= etter, if at all something needs to be done for this issue.

 <= /p>

From: Bernie V= olz (volz) [mailto:volz@cisco.com]
Sent: Friday, February 15, 2013 2:45 PM
To: VithalPrasad Gaitonde
Cc: Bud Millwood; Dmitry Anipko; Ralph Droms; dhcwg@ietf.org; Andre = Kostur; Lemon Ted
Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-upda= te-00.txt

 

(I guess I should now sta= rt saying “WG co-chair hat off” …)

 <= /p>

Interesting points.<= /o:p>

 <= /p>

The elapsed time option o= nly supports 16-bits and is in 100ths of a second, so it will max out at 65= 5.35 seconds (under 11 minutes).

 <= /p>

As these are a ‘ret= ransmission’ and so the XID would be the same and the elapsed time sh= ould reflect the time since the client started (obviously maxing out at a value of 0xffff as documented in RFC 3315).

 <= /p>

Regarding the single pack= et issue … I see:

1. = ;      Let it be. If the= original retransmissions up this point didn’t work, what’s the= chance that it will work now? And a single packet should generally be OK. Though there may be some ND implementations that drop a packet they= can’t send instead of holding onto at least that one packet and that= might cause things to fail ‘forever’ (the server-to-client or = relay-to-client ND entry would expire before the next packet arrives).

2. = ;      Have the client c= ould ‘restart’ the Solicit process instead of using the longer = time as a cap to the retransmission delay. But this means that the client would send restart sending at the normal backoff intervals and that= makes the clients (if there are a lot) very chatty in total – which = is what we wanted to prevent. This would also mean a new XID and new elapse= d time base.

3. = ;      Complicate the re= transmission algorithm to allow some small number (2 or 3) packets in a = 220;shorter” interval after ‘long’ retransmission interva= l (this is what you suggested). Probably these should occur well within the typica= l ND cache expiration interval.

4. = ;      Something else? (= Document that not retaining a packet per destination when needing ND is a b= ad idea.)

 <= /p>

2 may be the most attract= ive as it is much simpler (and means this document would define an MRD for = Solicit too). But the long delay between retransmissions leading up to the maximum may also suffer from the issue mentioned in #1, = so #3 may have the best merit.

 <= /p>

- =          Bernie=

 <= /p>

From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of VithalPrasad Gaitonde
Sent: Thursday, February 14, 2013 10:14 PM
To: Bernie Volz (volz)
Cc: Bud Millwood; Dmitry Anipko; Ralph Droms; dhcwg@ietf.org; Andre Kostur; Lemon Ted
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-upda= te-00.txt

 

Apparently, some relay agents/switches can be config= ured to relay packets based on the amount of time the client has been tryin= g (elapsed time option). Similar language exists for the behavior of the DH= CP server.

 

From RFC 3315 section 22.9 -

Servers and Relay Agents use the data value in this = option (elapsed time)
   as input to policy controlling how a server responds to a clie= nt
   message.  For example, the elapsed time option allows a s= econdary
   DHCP server to respond to a request when a primary server has = not
   answered in a reasonable time.

 

When the client retransmits at every 1 hour interval= , does the client reset the elapsed time option to 0. If yes, with the abov= e mentioned behavior of relay agents and servers, the single retransmission= of SOLICIT or INFORM will turn out inadequate.

Also, given the unreliability of UDP, doing only one= retransmission of the message every hour (beyond the first hour) may lead = to situations where the server does not see the request and the client has = to wait for another hour to get an IPv6 address or options.

 

Instead of making just a single retransmission at ev= ery 1 hour interval, the client should make at least a couple of = retransmissions to increase the reliability of getting an IPv6 address or o= ptions from the server.

 

Thanks,

Prasad

On Fri, Feb 1, 2013 at 8:10 PM, Bernie Volz (volz) &= lt;volz@cisco.com&g= t; wrote:

Fine by me too.

- Bernie


On Feb 1, 2013, at 9:52 PM, "Dmitry Anipko" <Dmitry.Anipko@microsoft.com> wrote:
>>> A client is not expected to listen for a response during the e= ntire period between transmission of Solicit or Information-Request message= s
>
> Looks good to me.
>
> Thanks.
>
> -----Original Message-----
> From: Ralph Droms [mailto:rdr= oms.ietf@gmail.com]
> Sent: Friday, February 01, 2013 6:08 PM
> To: Dmitry Anipko
> Cc: Bernie Volz (volz); Bud Millwood; Sten Carlsen; dhcwg@ietf.org; Andre Kostur; Lemon Ted
> Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update= -00.txt
>
> (resending to dhcwg mailing list)
>
> On Feb 1, 2013, at 5:59 PM 2/1/13, Dmitry Anipko <Dmitry.Anipko@microsoft.com>
> wrote:
>
>> Agree with everything you wrote. I think several minutes waiting w= ould be fine, and I understand there may be good reasons for such waiting i= nterval (as opposed to hour).
>>
>> If there is a general agreement on these 2 adjustments (allowed wa= iting period cap and INF_MAX_RT default), how do we move forward - Ralph, c= an these be included in the next revision of the draft?
>>
>> Thank you.
>
> Adding INF_MAX_RT makes sense.
>
> In my opinion, the right thing to say about waiting for a response is = something vague, to the effect of "A client is not expected to listen = for a response during the entire period between transmission of Solicit or = Information-Request messages."
>
> - Ralph
>
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

 

--_000_FB329D818C7CAB438F0C7DD772EA1025062001BCTK5EX14MBXC254r_-- From leaf.yeh.sdo@gmail.com Sun Feb 17 23:33:14 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8CF521F8B83 for ; Sun, 17 Feb 2013 23:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.385 X-Spam-Level: X-Spam-Status: No, score=-1.385 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_IP_219128=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHMPwqnnbe4u for ; Sun, 17 Feb 2013 23:33:13 -0800 (PST) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB8621F857A for ; Sun, 17 Feb 2013 23:33:13 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id bg4so2673814pad.40 for ; Sun, 17 Feb 2013 23:33:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=7qTnqRkM7ADZxfOnd0KtslpSvlrsKq1o3bWZvmRfcGE=; b=k4Cq0IPfmIYaJ+BbtyuMp4TsFbxsW9mhw12hhdy5vAfHY0LtEpepIpt1XjhN0RMAUA gXuGgmeHx1Zjrh7S7I8GaTvTfeBqe15VLb0mDV5OdGqr+OGHsYrhdDCtvb412FCUigsQ p+AlhfxDKYkxHsPAxuA9YvyY7tmVZ753EwOR2O5GREgpDYeSMzc8cms+/71eL/0qOYgT beTme5JTVe/HIdOTYSLmuXqvlCJI1oWqT/lqmRMLM7nKoAryxJK3g61BNX6qXrVSB9TO cfn5GsAUcQNphsbWqlzgLuE1XG1JQzsNN+XiJvaN52nMIdCgzJw5hNttIsV1Q+PfC6Xd 6FoQ== X-Received: by 10.66.166.43 with SMTP id zd11mr5002255pab.5.1361172793236; Sun, 17 Feb 2013 23:33:13 -0800 (PST) Received: from PC ([219.133.128.178]) by mx.google.com with ESMTPS id y9sm102875857paw.1.2013.02.17.23.33.09 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 17 Feb 2013 23:33:12 -0800 (PST) From: "Leaf Yeh" To: "'Bernie Volz \(volz\)'" References: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> <90903C21C73202418A48BFBE80AEE5EB22DEB892@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843CA16@xmb-rcd-x04.cisco.com> <90903C21C73202418A48BFBE80AEE5EB22DEDE19@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E18442EC0@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E184431CF@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E184431CF@xmb-rcd-x04.cisco.com> Date: Mon, 18 Feb 2013 15:33:02 +0800 Message-ID: <5121d938.294e420a.5385.55c5@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHN9+v1hlVR97tQwEWdQEw5vWHbDZhT66CwgADdE4D//5438IAn3Ctw Content-Language: zh-cn Cc: 'dhc WG' Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-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, 18 Feb 2013 07:33:14 -0000 E1. Editorial - How about change the title of the draft to be 'Updates of RFC 3315 and RFC3633 with multiple stateful options'? The updates could be summarized as follows: a. Client should keep a single session with the multiple stateful options (in subsequent messages, Request, Renew, and Rebind, to the server.) b. Ideally the Status Code option should be encapsulated in the IA option for all DHCP messages. This makes Advertisement messages equal to Reply messages. (A new recommendation to the server though there is a issue for backwards compatibility) c. The server SHOULD set the T1/T2 timers in all IA options in Reply and Advertise messages to the same value. (A new recommendation to the server) d. makes the server's IA processing of Renew and Rebind similar to the Request processing (but ORO sounds also make it). e. Allow the Confirm message work for DHCPv6-PD. Right? E2. Editorial - Page 3 - Section 3 < snip >Each IA holds one type of IA option; for example, ... Does it mean IA_NA and IA-PD will never share the same IA? I guess the better text could be 'Each IA option holds one type, for example,... ' T1. Page 7 - Section 4.4 The client also includes an IA option for each binding it desires but has been unable to obtain. Could the above text be replaced by the original text in RFC3315? 'The client MUST include an Option Request option (see section 22.7) to indicate the options the client is interested in receiving. The client MAY include options with data values as hints to the server about parameter values the client would like to have returned.' T2. Technical - Page 7- Section 4.4 If the server cannot find a client entry for the IA the server creates the bindings for that client according to the server's policy and configuration information and records the IAs and other information requested by the client. Not sure the above sounds a necessary behavior of the server. What is the issue if the server doesn't create the bindings for that client when the server cannot find a client entry for the IA? E3. Editorial - Page 7 - Section 4.4 However, it MUST limit the frequency at which is does this to no more often than the renewal frequency. I guess the right text sounds '...at which it does this to... '. E4. Editorial - Page 8 - Section 4.5 If such verification is needed the requesting router MUST initiate a Confirm message exchange as described in section 18.1.2, "Creation and Transmission of Confirm Messages" of RFC 3315. The above text sounds '...MUST initiate a Confirm/Reply message exchange...'. E5. Editorial - Saw many 'should's have not been in the format of 'SHOULD' yet. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Tuesday, January 22, 2013 7:25 AM To: Bud Millwood Cc: dhc WG; Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >The original text says to return an IA_* with no addr/prefix and a status code "NoBinding". Now, if we cannot fulfill the binding, we do the same thing, but we don't include a status code. Is that right? Hum ... perhaps it is best to follow the Request and return NoAddrsAvail status in the IA_* option (of course we'd need to update RFC 3633 text then as well to return NoPrefixAvail). The choices now seem to be: 1. Just return the IA_* option (empty). 2. Return IA_* option with NoAddrsAvail (or NoPrefixAvail) -- following Request logic. 3. Return IA_* option with NoBinding -- following existing Renew logic for unknown bindings. 4. Don't return the IA_* option (I think this is not a good choice and believe you don't either). Perhaps new #2 is the best as it matches the Request ... Renew and Request are really very similar anyway - the main differences were: - We are telling the server the client is renewing (thus is using the leases) - No new bindings were 'allowed' -- this is now not true and what we are proposing to change. We could do the same for the Rebind. BTW: The case for a Rebind where the server can't find the client entry for the IA is not covered in RFC 3315 (it is if the addresses are no longer appropriate, but not otherwise). In some ways, this missing text leaves it up to the server (which for some cases, may be good - for example, Failover may trust the client and if there is no conflict, the server may want to respond -- that is what we do in V4). In other instances, the server might want to drop the Rebind or respond with NoBindings to force client back to Solicit? Also, the Rebind is missing the text that allows the server to change the addresses as appears in Renew. Opinions? - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bud Millwood Sent: Monday, January 21, 2013 5:52 PM To: Bernie Volz (volz) Cc: dhc WG; Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 > Regarding 4.2, how is that? It always means no addresses available but may mean prefixes available. Yes of course; I should have reviewed 3633. > Regarding 4.4, I would expect the server to return the IA_* option but without any IAADDR/IAPREFIX options. (The server would not really create a record of this binding since it has no leases.) Perhaps the text should be clarified regarding this. The original text says to return an IA_* with no addr/prefix and a status code "NoBinding". Now, if we cannot fulfill the binding, we do the same thing, but we don't include a status code. Is that right? > Note that perhaps a question exists as to which behavior to document for the Reply in this case: > 1. Return the IA_* option, empty. > 2. Do not return the IA_* option. > Either approach would work. 1 may provide more information to the client (but client implementers may prefer 2) -- it is also sending back what the client sent (since it had no IAADDR/IAPREFIXes to include). (1) makes more sense to me because the server is explicitly acknowledging the IA_*. - Bud > Regarding 4.5, ok one of those edits can be done in a -04 (after 28th when WGLC ends). Usually the RFC-Editor also catches things like this, but best to give them a better document to start with. > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Bud Millwood > Sent: Monday, January 21, 2013 10:28 AM > To: Gaurav Halwasia (ghalwasi) > Cc: dhc WG; Bernie Volz (volz); Ted Lemon > Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 > > 4.2: Proposed solution: No change. For backwards compatibility, the > NoAddrsAvail Status Code option when no addresses are available will > be kept in the global scope for Advertise messages. > > Question: Does it need to be further clarified that in Advertise, "NoAddrsAvail" now may mean "SomeAddrsAvail"? > > 4.4: Note that clients that communicate with servers that do not support > this updated Renew processing will receive the NoBinding status for > the IA which had no bindings. > > Question: isn't this also a valid response if the server does support updated Renew processing, but cannot fulfill the binding for the IA? > > 4.5: It lets a server without a binding to reply to > the message, under the assumption that the server only needs > knowledge about the prefix(es) on the link, to inform the client that > the address is likely valid or not. > > - Change "lets" to "enables" or "allows", alt. remove "to" between "binding" and "reply". > > - Bud > > > On Wed, Jan 16, 2013 at 5:43 AM, Gaurav Halwasia (ghalwasi) wrote: >> Thanks for taking care of comments. I agree with you point regarding point (3). >> >> -Gaurav >> >> -----Original Message----- >> From: Bernie Volz (volz) >> Sent: Wednesday, January 16, 2013 2:38 AM >> To: Gaurav Halwasia (ghalwasi); Ted Lemon; dhc WG >> Subject: RE: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >> >> Hi: >> >> Thanks for the comments, I've made some comments below (BV>). >> >> Let's wait until the 28th before I draft the -04 version. Hopefully there will be more comments! >> >> - Bernie >> >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On >> Behalf Of Gaurav Halwasia (ghalwasi) >> Sent: Monday, January 14, 2013 10:47 PM >> To: Ted Lemon; dhc WG >> Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >> >> I read/reviewed this document and I support this document to move forward. >> >> I do have some comments and it would be good if authors can consider them. Even otherwise I support this document. >> >> 1.) In Abstract :- >> >> "Implementation experience of the CPE model >> described in has shown multiple issues" >> I think you wanted to specify RFC6204 after "described in" >> >> BV> Yes. >> >> 2.) Section 4.2 Placement of Status codes. >> In Reply messages IA specific status codes (NoAddrsAvail, NotOnlink, >> NoBinding) are encapsulated in the IA option. >> I think we should include "NoPrefixAvail" as well in the above line. I see no reason why it should not be. >> >> BV> Yes. Might be best to use (i.e.) too so that it is clear that this is just a partial list. >> >> 3.) For Confirm message. As I understand, we are now allowing CONFIRM >> message for IA_PD. I think we should update the definition of CONFIRM >> message in RFC3315 which currently only talks about *address* >> >> >> CONFIRM (4) A client sends a Confirm message to any >> available server to determine whether the >> addresses it was assigned are still appropriate >> to the link to which the client is connected. >> >> >> BV> Well this is a bit tricky as RFC 3315 knows nothing of prefix allocation. A RFC 3315bis would definitely want to reword it as such (as I would expect it to combine 3315 and 3633). This really falls into the changes to RFC 3633 that it would extend Confirm to include prefixes. We tried (I hope) to keep the RFC 3315 changes consistent with what RFC 3315 contained and PD changes to RFC 3633. There might be more we could add to RFC 3633, but do we really think that is necessary? I guess we could replace "addresses" with something more generic ("configuration information explicitly assigned to the client", which comes from the definition of binding in RFC 3315), but I think that doesn't really improve anything. >> >> BV> Thus, I will not make this change. >> >> >> Thanks, >> Gaurav >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On >> Behalf Of Ted Lemon >> Sent: Tuesday, January 15, 2013 1:04 AM >> To: dhc WG >> Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >> >> On Jan 14, 2013, at 2:15 PM, Bernie Volz (volz) wrote: >>> A 2nd Query regarding this as I heard nothing since the first. >> >> Oops, sorry about that, Bernie. >> >> Folks, the authors of this draft feel it's ready for a WGLC. There's been substantial discussion and comment already. This is pretty important IPv6 deployment work, so more eyes are better. Please review the draft and indicate whether or not you feel it is ready to be published. We have been getting very anemic responses to working group messages recently. Your response matters, so please do respond. >> >> We will evaluate consensus after January 28. Thanks! >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From leaf.yeh.sdo@gmail.com Sun Feb 17 23:33:19 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4618C21F8BBB for ; Sun, 17 Feb 2013 23:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_IP_219128=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0Up8H0k+9wr for ; Sun, 17 Feb 2013 23:33:18 -0800 (PST) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id 37E1221F8BB9 for ; Sun, 17 Feb 2013 23:33:18 -0800 (PST) Received: by mail-pb0-f41.google.com with SMTP id um15so1541783pbc.28 for ; Sun, 17 Feb 2013 23:33:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=4S1gnkIPO1pGJ36wu48LvvV0D30ajJkJww8eo00QHcY=; b=qHjZQijjNvu17J1FSQzYN971ujj3Ddv7dtzb7HWq3gWW6L8YWcSL9UimF3ZgnpZ6gv c1B1K5jPjMRwSOgGFr7AsU1+ZGmPloYJtf8wGy5MsO293n0ojc9gVvGBUx5Pdr7aO8TT 5VnFgkIamzgp5WCrDmOJnys/efkMpwdNPklxCRxmqtJiyHDUcN8BpI/yNEEFw+OgipSg IyrsQn7gZ+WuVUfWQ0gVqGF8iQ3MLxM+NsAXs2Bu3xHATyeI+hvoO4ZSyFRfKDBUMEhS wsSoUWHtStTCNEU3xNA7mfTWX74EsfKmo2677HWD77FQFZ1Q1LCLIjgzC+PIWWUlykvE zn2w== X-Received: by 10.68.144.97 with SMTP id sl1mr27775817pbb.49.1361172798010; Sun, 17 Feb 2013 23:33:18 -0800 (PST) Received: from PC ([219.133.128.178]) by mx.google.com with ESMTPS id y9sm102875857paw.1.2013.02.17.23.33.13 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 17 Feb 2013 23:33:17 -0800 (PST) From: "Leaf Yeh" To: "'Bernie Volz \(volz\)'" References: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> <90903C21C73202418A48BFBE80AEE5EB22DEB892@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843CA16@xmb-rcd-x04.cisco.com> <90903C21C73202418A48BFBE80AEE5EB22DEDE19@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E18442EC0@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E184431CF@xmb-rcd-x04.cisco.com> In-Reply-To: Date: Mon, 18 Feb 2013 15:33:02 +0800 Message-ID: <5121d93d.294e420a.5385.55cd@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac34Pu9L8dPgoQxOQ1CN2urt+gacOwVB/gtg Content-Language: zh-cn Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-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, 18 Feb 2013 07:33:19 -0000 Bernie - > The choices now seem to be: > 1. Just return the IA_* option (empty). > 2. Return IA_* option with NoAddrsAvail (or NoPrefixAvail) -- following Request logic. > 3. Return IA_* option with NoBinding -- following existing Renew logic for unknown bindings. > 4. Don't return the IA_* option (I think this is not a good choice and believe you don't either). >Perhaps new #2 is the best as it matches the Request ... Renew and Request are really very similar anyway #2 & # 3 sounds roughly the same to me. Could the client directly interpret the 'NoBinding' to be 'NoAddrsAvail (or NoPrefixAvail)' here? Bernie - BTW: The case for a Rebind where the server can't find the client entry for the IA is not covered in RFC 3315 (it is if the addresses are no longer appropriate, but not otherwise). In some ways, this missing text leaves it up to the server (which for some cases, may be good - for example, Failover may trust the client and if there is no conflict, the server may want to respond -- that is what we do in V4). In other instances, the server might want to drop the Rebind or respond with NoBindings to force client back to Solicit? Also, the Rebind is missing the text that allows the server to change the addresses as appears in Renew. Do we need more text on REBIND here? Sounds like the same behavior as the RENEW at server side: (referring to section 18.2.3 of RFC3315) a. If the server cannot find a client entry for the IA, the server returns the IA containing with a Status Code option set to NoBinding in the Reply message. b. The server may choose to change the list of addresses/prefixes and their lifetimes in IAs that are returned to the client. (I think we'd mention IA_PD in the updates of RFC3315) Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bud Millwood Sent: Tuesday, January 22, 2013 9:22 AM To: Bernie Volz (volz) Cc: dhc WG; Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 On Tue, Jan 22, 2013 at 12:24 AM, Bernie Volz (volz) wrote: >>The original text says to return an IA_* with no addr/prefix and a status code "NoBinding". Now, if we cannot fulfill the binding, we do the same thing, but we don't include a status code. Is that right? > > Hum ... perhaps it is best to follow the Request and return NoAddrsAvail status in the IA_* option (of course we'd need to update RFC 3633 text then as well to return NoPrefixAvail). > > The choices now seem to be: > 1. Just return the IA_* option (empty). > 2. Return IA_* option with NoAddrsAvail (or NoPrefixAvail) -- following Request logic. > 3. Return IA_* option with NoBinding -- following existing Renew logic for unknown bindings. > 4. Don't return the IA_* option (I think this is not a good choice and believe you don't either). > > Perhaps new #2 is the best as it matches the Request ... Renew and Request are really very similar anyway - the main differences were: > - We are telling the server the client is renewing (thus is using the > leases) > - No new bindings were 'allowed' -- this is now not true and what we are proposing to change. I think #2 is best approach. Since we can now create bindings in Renew, and a client should be prepared to obtain a new lease at this time, it's basically the same thing as Request from the standpoint of the protocol. And judging by the names of the error codes, NoAddrsAvail and NoPrefixAvail seem better because they reflect the server's inability to create a binding. "NoBinding" seems more like "No info, can't proceed" (which is more suited the previous behavior). > We could do the same for the Rebind. I suppose my argument in favor of this is the same as above. If the client must be prepared to accept a new lease at this time, it's like a "deferred Request". > BTW: The case for a Rebind where the server can't find the client entry for the IA is not covered in RFC 3315 (it is if the addresses are no longer appropriate, but not otherwise). In some ways, this missing text leaves it up to the server (which for some cases, may be good - for example, Failover may trust the client and if there is no conflict, the server may want to respond -- that is what we do in V4). In other instances, the server might want to drop the Rebind or respond with NoBindings to force client back to Solicit? Also, the Rebind is missing the text that allows the server to change the addresses as appears in Renew. Maybe it's important to distinguish between not being able to create a new binding for a non-existent lease (NoAddrsAvail/NoPrefixAvail) and not being able to create a new binding for an existing lease? (Or for that matter, for the latter, not being able to rebind the addr/prefix in question due to lack of information). - Bud > > Opinions? > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Bud Millwood > Sent: Monday, January 21, 2013 5:52 PM > To: Bernie Volz (volz) > Cc: dhc WG; Ted Lemon > Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 > >> Regarding 4.2, how is that? It always means no addresses available but may mean prefixes available. > > Yes of course; I should have reviewed 3633. > >> Regarding 4.4, I would expect the server to return the IA_* option but without any IAADDR/IAPREFIX options. (The server would not really create a record of this binding since it has no leases.) Perhaps the text should be clarified regarding this. > > The original text says to return an IA_* with no addr/prefix and a status code "NoBinding". Now, if we cannot fulfill the binding, we do the same thing, but we don't include a status code. Is that right? > >> Note that perhaps a question exists as to which behavior to document for the Reply in this case: >> 1. Return the IA_* option, empty. >> 2. Do not return the IA_* option. >> Either approach would work. 1 may provide more information to the client (but client implementers may prefer 2) -- it is also sending back what the client sent (since it had no IAADDR/IAPREFIXes to include). > > (1) makes more sense to me because the server is explicitly acknowledging the IA_*. > > - Bud > >> Regarding 4.5, ok one of those edits can be done in a -04 (after 28th when WGLC ends). Usually the RFC-Editor also catches things like this, but best to give them a better document to start with. >> >> - Bernie >> >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On >> Behalf Of Bud Millwood >> Sent: Monday, January 21, 2013 10:28 AM >> To: Gaurav Halwasia (ghalwasi) >> Cc: dhc WG; Bernie Volz (volz); Ted Lemon >> Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >> >> 4.2: Proposed solution: No change. For backwards compatibility, the >> NoAddrsAvail Status Code option when no addresses are available will >> be kept in the global scope for Advertise messages. >> >> Question: Does it need to be further clarified that in Advertise, "NoAddrsAvail" now may mean "SomeAddrsAvail"? >> >> 4.4: Note that clients that communicate with servers that do not support >> this updated Renew processing will receive the NoBinding status for >> the IA which had no bindings. >> >> Question: isn't this also a valid response if the server does support updated Renew processing, but cannot fulfill the binding for the IA? >> >> 4.5: It lets a server without a binding to reply to >> the message, under the assumption that the server only needs >> knowledge about the prefix(es) on the link, to inform the client that >> the address is likely valid or not. >> >> - Change "lets" to "enables" or "allows", alt. remove "to" between "binding" and "reply". >> >> - Bud >> >> >> On Wed, Jan 16, 2013 at 5:43 AM, Gaurav Halwasia (ghalwasi) wrote: >>> Thanks for taking care of comments. I agree with you point regarding point (3). >>> >>> -Gaurav >>> >>> -----Original Message----- >>> From: Bernie Volz (volz) >>> Sent: Wednesday, January 16, 2013 2:38 AM >>> To: Gaurav Halwasia (ghalwasi); Ted Lemon; dhc WG >>> Subject: RE: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >>> >>> Hi: >>> >>> Thanks for the comments, I've made some comments below (BV>). >>> >>> Let's wait until the 28th before I draft the -04 version. Hopefully there will be more comments! >>> >>> - Bernie >>> >>> -----Original Message----- >>> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On >>> Behalf Of Gaurav Halwasia (ghalwasi) >>> Sent: Monday, January 14, 2013 10:47 PM >>> To: Ted Lemon; dhc WG >>> Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >>> >>> I read/reviewed this document and I support this document to move forward. >>> >>> I do have some comments and it would be good if authors can consider them. Even otherwise I support this document. >>> >>> 1.) In Abstract :- >>> >>> "Implementation experience of the CPE model >>> described in has shown multiple issues" >>> I think you wanted to specify RFC6204 after "described in" >>> >>> BV> Yes. >>> >>> 2.) Section 4.2 Placement of Status codes. >>> In Reply messages IA specific status codes (NoAddrsAvail, NotOnlink, >>> NoBinding) are encapsulated in the IA option. >>> I think we should include "NoPrefixAvail" as well in the above line. I see no reason why it should not be. >>> >>> BV> Yes. Might be best to use (i.e.) too so that it is clear that this is just a partial list. >>> >>> 3.) For Confirm message. As I understand, we are now allowing >>> CONFIRM message for IA_PD. I think we should update the definition >>> of CONFIRM message in RFC3315 which currently only talks about >>> *address* >>> >>> >>> CONFIRM (4) A client sends a Confirm message to any >>> available server to determine whether the >>> addresses it was assigned are still appropriate >>> to the link to which the client is connected. >>> >>> >>> BV> Well this is a bit tricky as RFC 3315 knows nothing of prefix allocation. A RFC 3315bis would definitely want to reword it as such (as I would expect it to combine 3315 and 3633). This really falls into the changes to RFC 3633 that it would extend Confirm to include prefixes. We tried (I hope) to keep the RFC 3315 changes consistent with what RFC 3315 contained and PD changes to RFC 3633. There might be more we could add to RFC 3633, but do we really think that is necessary? I guess we could replace "addresses" with something more generic ("configuration information explicitly assigned to the client", which comes from the definition of binding in RFC 3315), but I think that doesn't really improve anything. >>> >>> BV> Thus, I will not make this change. >>> >>> >>> Thanks, >>> Gaurav >>> -----Original Message----- >>> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On >>> Behalf Of Ted Lemon >>> Sent: Tuesday, January 15, 2013 1:04 AM >>> To: dhc WG >>> Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >>> >>> On Jan 14, 2013, at 2:15 PM, Bernie Volz (volz) wrote: >>>> A 2nd Query regarding this as I heard nothing since the first. >>> >>> Oops, sorry about that, Bernie. >>> >>> Folks, the authors of this draft feel it's ready for a WGLC. There's been substantial discussion and comment already. This is pretty important IPv6 deployment work, so more eyes are better. Please review the draft and indicate whether or not you feel it is ready to be published. We have been getting very anemic responses to working group messages recently. Your response matters, so please do respond. >>> >>> We will evaluate consensus after January 28. Thanks! >>> >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > 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 Feb 18 08:10:23 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDA321F8C10 for ; Mon, 18 Feb 2013 08:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNL9Ld3jyNYz for ; Mon, 18 Feb 2013 08:10:22 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id ED56321F8B90 for ; Mon, 18 Feb 2013 08:10:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14516; q=dns/txt; s=iport; t=1361203822; x=1362413422; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=plHtHOChsu2Pwj3UJU3K+1vo5qxq+Ew8uLLdzMhnz/I=; b=T/oIULBvu3UNJSkgHjWglXVyg2GRAGqRMFLDj0aVSfrm+1v8XBRgY/4z USLq0dyAuycA2WCHkAb+8AZ6dkYVSZnxUTXlYO1y4gyjiDRvG7EPtQHig sE0HBD8KaYSUfVQBIzXAphUFqNYSqwb0yVOJegYmxv18FC840NBs/Glip 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANFRIlGtJXG+/2dsb2JhbAA7CcAjgQQWc4IfAQEBAwEBAQEkEzQLBQcEAgEIEQQBAQEKFAkHJwsUCQgCBA4FCBOHcQYMwDUEjW0EgRUmCwcGgllhA6cEgweBaj0 X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; d="scan'208";a="178386661" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 18 Feb 2013 16:10:21 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1IGAL63004258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Feb 2013 16:10:21 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Mon, 18 Feb 2013 10:10:21 -0600 From: "Bernie Volz (volz)" To: Leaf Yeh Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 Thread-Index: AQHN9+v1hlVR97tQwEWdQEw5vWHbDZhT66CwgADdE4D//5438IAn3CtwgAOrH4A= Date: Mon, 18 Feb 2013 16:10:20 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1847035E@xmb-rcd-x04.cisco.com> References: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> <90903C21C73202418A48BFBE80AEE5EB22DEB892@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843CA16@xmb-rcd-x04.cisco.com> <90903C21C73202418A48BFBE80AEE5EB22DEDE19@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E18442EC0@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E184431CF@xmb-rcd-x04.cisco.com> <5121d938.294e420a.5385.55c5@mx.google.com> In-Reply-To: <5121d938.294e420a.5385.55c5@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.246.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'dhc WG' Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-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, 18 Feb 2013 16:10:23 -0000 Hi: Thanks for the thorough review. Some comments below (BV>). - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of L= eaf Yeh Sent: Monday, February 18, 2013 2:33 AM To: Bernie Volz (volz) Cc: 'dhc WG' Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 E1. Editorial - How about change the title of the draft to be 'Updates of RFC 3315 and RFC3633 with multiple stateful options'? BV> While we could change the title, I don't really see this as that critic= al. The updates could be summarized as follows: a. Client should keep a single session with the multiple stateful options (in subsequent messages, Request, Renew, and Rebind, to the server.)=20 b. Ideally the Status Code option should be encapsulated in the IA option for all DHCP messages. This makes Advertisement messages equal to Reply messages. (A new recommendation to the server though there is a issue for backwards compatibility) c. The server SHOULD set the T1/T2 timers in all IA options in Reply and Advertise messages to the same value. (A new recommendation to the server) d. makes the server's IA processing of Renew and Rebind similar to the Request processing (but ORO sounds also make it). e. Allow the Confirm message work for DHCPv6-PD. Right? BV> Yes, except for D and ORO. (See below.) E2. Editorial - Page 3 - Section 3=20 < snip >Each IA holds one type of IA option; for example, ... Does it mean IA_NA and IA-PD will never share the same IA? I guess the better text could be 'Each IA option holds one type, for example,... ' BV> I am not sure what you are asking here. An instance of an IA is a IA_NA= or IA_PD. IA is short for Identity Association. Note that this just update= s RFC 3315's definition which was address based. T1. Page 7 - Section 4.4 The client also includes an IA option for each binding it desires but has been unable to obtain. Could the above text be replaced by the original text in RFC3315?=20 'The client MUST include an Option Request option (see section 22.7) to indicate the options the client is interested in receiving. The client MAY include options with data values as hints to the server about parameter values the client would like to have returned.' BV> ORO are not used for IA_NA/IA_PD/IA_TA. As the client must assign an IA= ID so it must send the IA_* option. T2. Technical - Page 7- Section 4.4 If the server cannot find a client entry for the IA the server creates the bindings for that client according to the server's policy and configuration information and records the IAs and other information requested by the client. Not sure the above sounds a necessary behavior of the server. What is the issue if the server doesn't create the bindings for that client when the server cannot find a client entry for the IA?=09 BV> Interesting point and the text should probably be revised to allow the = older behavior as servers might not be updated. E3. Editorial - Page 7 - Section 4.4 However, it MUST limit the frequency at which is does this to no more often than the renewal frequency. I guess the right text sounds '...at which it does this to... '. BV> Yes. This should be it, not is. E4. Editorial - Page 8 - Section 4.5 If such verification is needed the requesting router MUST initiate a Confirm message exchange as described in section 18.1.2, "Creation and Transmission of Confirm Messages" of RFC 3315. The above text sounds '...MUST initiate a Confirm/Reply message exchange...'. BV> Yes. To we should add /Reply. E5. Editorial - Saw many 'should's have not been in the format of 'SHOULD' yet. BV> There may be a few that could be changed to SHOULD. In general, only th= e proposed solution and changes would have these capitalized per RFC 2119. = I think there are only 2 to consider for should -> SHOULD - in 4. and 4.4. = in proposed solution text. For must -> MUST, 4.6. There are a few grey are= as that may also switch the case ... I think for the discuss text we may wa= nt to lower case. I'll discuss this with Ole and see what we do for a revis= ed draft. If someone has a strong opinion one way or the other, please let = us know. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Tuesday, January 22, 2013 7:25 AM To: Bud Millwood Cc: dhc WG; Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >The original text says to return an IA_* with no addr/prefix and a status code "NoBinding". Now, if we cannot fulfill the binding, we do the same thing, but we don't include a status code. Is that right? Hum ... perhaps it is best to follow the Request and return NoAddrsAvail status in the IA_* option (of course we'd need to update RFC 3633 text then as well to return NoPrefixAvail). The choices now seem to be: 1. Just return the IA_* option (empty). 2. Return IA_* option with NoAddrsAvail (or NoPrefixAvail) -- following Request logic. 3. Return IA_* option with NoBinding -- following existing Renew logic for unknown bindings. 4. Don't return the IA_* option (I think this is not a good choice and believe you don't either). Perhaps new #2 is the best as it matches the Request ... Renew and Request are really very similar anyway - the main differences were: - We are telling the server the client is renewing (thus is using the leases) - No new bindings were 'allowed' -- this is now not true and what we are proposing to change. We could do the same for the Rebind. BTW: The case for a Rebind where the server can't find the client entry for the IA is not covered in RFC 3315 (it is if the addresses are no longer appropriate, but not otherwise). In some ways, this missing text leaves it up to the server (which for some cases, may be good - for example, Failover may trust the client and if there is no conflict, the server may want to respond -- that is what we do in V4). In other instances, the server might want to drop the Rebind or respond with NoBindings to force client back to Solicit? Also, the Rebind is missing the text that allows the server to change the addresses as appears in Renew.=20 Opinions? - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bud Millwood Sent: Monday, January 21, 2013 5:52 PM To: Bernie Volz (volz) Cc: dhc WG; Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 > Regarding 4.2, how is that? It always means no addresses available but ma= y mean prefixes available. Yes of course; I should have reviewed 3633. > Regarding 4.4, I would expect the server to return the IA_* option but without any IAADDR/IAPREFIX options. (The server would not really create a record of this binding since it has no leases.) Perhaps the text should be clarified regarding this. The original text says to return an IA_* with no addr/prefix and a status code "NoBinding". Now, if we cannot fulfill the binding, we do the same thing, but we don't include a status code. Is that right? > Note that perhaps a question exists as to which behavior to document for the Reply in this case: > 1. Return the IA_* option, empty. > 2. Do not return the IA_* option. > Either approach would work. 1 may provide more information to the client (but client implementers may prefer 2) -- it is also sending back what the client sent (since it had no IAADDR/IAPREFIXes to include). (1) makes more sense to me because the server is explicitly acknowledging the IA_*. - Bud > Regarding 4.5, ok one of those edits can be done in a -04 (after 28th whe= n WGLC ends). Usually the RFC-Editor also catches things like this, but best to give them a better document to start with. > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf=20 > Of Bud Millwood > Sent: Monday, January 21, 2013 10:28 AM > To: Gaurav Halwasia (ghalwasi) > Cc: dhc WG; Bernie Volz (volz); Ted Lemon > Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 > > 4.2: Proposed solution: No change. For backwards compatibility, the > NoAddrsAvail Status Code option when no addresses are available will > be kept in the global scope for Advertise messages. > > Question: Does it need to be further clarified that in Advertise, "NoAddrsAvail" now may mean "SomeAddrsAvail"? > > 4.4: Note that clients that communicate with servers that do not support > this updated Renew processing will receive the NoBinding status for > the IA which had no bindings. > > Question: isn't this also a valid response if the server does support updated Renew processing, but cannot fulfill the binding for the IA? > > 4.5: It lets a server without a binding to reply to > the message, under the assumption that the server only needs > knowledge about the prefix(es) on the link, to inform the client that > the address is likely valid or not. > > - Change "lets" to "enables" or "allows", alt. remove "to" between "binding" and "reply". > > - Bud > > > On Wed, Jan 16, 2013 at 5:43 AM, Gaurav Halwasia (ghalwasi) wrote: >> Thanks for taking care of comments. I agree with you point regarding point (3). >> >> -Gaurav >> >> -----Original Message----- >> From: Bernie Volz (volz) >> Sent: Wednesday, January 16, 2013 2:38 AM >> To: Gaurav Halwasia (ghalwasi); Ted Lemon; dhc WG >> Subject: RE: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >> >> Hi: >> >> Thanks for the comments, I've made some comments below (BV>). >> >> Let's wait until the 28th before I draft the -04 version. Hopefully ther= e will be more comments! >> >> - Bernie >> >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On=20 >> Behalf Of Gaurav Halwasia (ghalwasi) >> Sent: Monday, January 14, 2013 10:47 PM >> To: Ted Lemon; dhc WG >> Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >> >> I read/reviewed this document and I support this document to move forward. >> >> I do have some comments and it would be good if authors can consider them. Even otherwise I support this document. >> >> 1.) In Abstract :- >> >> "Implementation experience of the CPE model >> described in has shown multiple issues" >> I think you wanted to specify RFC6204 after "described in" >> >> BV> Yes. >> >> 2.) Section 4.2 Placement of Status codes. >> In Reply messages IA specific status codes (NoAddrsAvail, NotOnlink, >> NoBinding) are encapsulated in the IA option. >> I think we should include "NoPrefixAvail" as well in the above line. I see no reason why it should not be. >> >> BV> Yes. Might be best to use (i.e.) too so that it is clear that this i= s just a partial list. >> >> 3.) For Confirm message. As I understand, we are now allowing CONFIRM=20 >> message for IA_PD. I think we should update the definition of CONFIRM=20 >> message in RFC3315 which currently only talks about *address* >> >> >> CONFIRM (4) A client sends a Confirm message to any >> available server to determine whether the >> addresses it was assigned are still appropriate >> to the link to which the client is connected. >> >> >> BV> Well this is a bit tricky as RFC 3315 knows nothing of prefix allocation. A RFC 3315bis would definitely want to reword it as such (as I would expect it to combine 3315 and 3633). This really falls into the changes to RFC 3633 that it would extend Confirm to include prefixes. We tried (I hope) to keep the RFC 3315 changes consistent with what RFC 3315 contained and PD changes to RFC 3633. There might be more we could add to RFC 3633, but do we really think that is necessary? I guess we could replac= e "addresses" with something more generic ("configuration information explicitly assigned to the client", which comes from the definition of binding in RFC 3315), but I think that doesn't really improve anything. >> >> BV> Thus, I will not make this change. >> >> >> Thanks, >> Gaurav >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On=20 >> Behalf Of Ted Lemon >> Sent: Tuesday, January 15, 2013 1:04 AM >> To: dhc WG >> Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >> >> On Jan 14, 2013, at 2:15 PM, Bernie Volz (volz) wrote: >>> A 2nd Query regarding this as I heard nothing since the first. >> >> Oops, sorry about that, Bernie. >> >> Folks, the authors of this draft feel it's ready for a WGLC. There's been substantial discussion and comment already. This is pretty important IPv6 deployment work, so more eyes are better. Please review the draft an= d indicate whether or not you feel it is ready to be published. We have bee= n getting very anemic responses to working group messages recently. Your response matters, so please do respond. >> >> We will evaluate consensus after January 28. Thanks! >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ 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 Feb 18 08:28:13 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE6F21F8BDB for ; Mon, 18 Feb 2013 08:28:13 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FI6ssLi6CnFj for ; Mon, 18 Feb 2013 08:28:11 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAC821F8943 for ; Mon, 18 Feb 2013 08:28:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15099; q=dns/txt; s=iport; t=1361204891; x=1362414491; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+z+VKVQ1HY68Z8iXoSZTs/+6Lw7syquhXpWUS1I3LBk=; b=gzMPZxOIArWV4Xd1n+IQRzD+Zu7hhH17n+ufBD1B6bhXknoPoc+dUpw/ BQrZ8jEQIHGnETVAPTMtrleqA46ayVGN8Td9UwqUwCfq85meYd1vtISVz KPMCjWsNcZqMyVNmrdW0GebJGh18h6CqUteYqFlN329tjvt4z+bLzQn94 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIZVIlGtJXHA/2dsb2JhbABEwCOBBBZzgh8BAQEDAQEBATc0CwUHBAIBCBEEAQEBChQJBycLFAkIAQEEDgUIE4dxBgzAQgSPBiYLBwaCWWEDkjOUUYMHgic X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; d="scan'208";a="178329011" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 18 Feb 2013 16:28:10 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1IGS924026013 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Feb 2013 16:28:10 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Mon, 18 Feb 2013 10:28:09 -0600 From: "Bernie Volz (volz)" To: Leaf Yeh Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 Thread-Index: Ac34Pu9LhlVR97tQwEWdQEw5vWHbDQVB/gtgACr11EA= Date: Mon, 18 Feb 2013 16:28:09 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1847039E@xmb-rcd-x04.cisco.com> References: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> <90903C21C73202418A48BFBE80AEE5EB22DEB892@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843CA16@xmb-rcd-x04.cisco.com> <90903C21C73202418A48BFBE80AEE5EB22DEDE19@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E18442EC0@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E184431CF@xmb-rcd-x04.cisco.com> <5121d93d.294e420a.5385.55cd@mx.google.com> In-Reply-To: <5121d93d.294e420a.5385.55cd@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.246.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-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, 18 Feb 2013 16:28:13 -0000 Hi again: #1 and #2 are probably 'equal'. The REBIND case is an interesting one and while #2 and #3 are probably clos= e to the same result in terms of the client's behavior, I wonder what exist= ing servers do -- I would guess that they are more likely to return #3 (mat= ching Renew) if they aren't willing to 'create' the binding? The subtle difference between #2 and #3 may be: - #2 means that the server would be willing to assign the binding a lease i= f it had a lease to give. - #3 means that the server would not be willing to assign the binding a lea= se because it has no record of the binding and would not create one. For #2, the message is clear that the client can continue to try. Whereas f= or #3, it may be that the client needs to return to Solicit if it ever hope= s to get the binding. I think that may be the key to this ... NoBinding means that the server wil= l not assign a new binding except via Solicit/... whereas NoAddrsAvail/NoPr= efixAvail means that the server has nothing to give the client but would ot= herwise accept the binding. I think we should make Renew and Rebind the same here (i.e. return #2 and #= 3 depending on the situation). What the client does with this information i= s likely: - If NoBinding, return to Solicit. - If NoAddrsAvail/NoPrefixAvail, continue to Renew/Rebind with the existing= leases (at T1/T2 times). If no leases, return to Solicit. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of L= eaf Yeh Sent: Monday, February 18, 2013 2:33 AM To: Bernie Volz (volz) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 Bernie - > The choices now seem to be: > 1. Just return the IA_* option (empty). > 2. Return IA_* option with NoAddrsAvail (or NoPrefixAvail) -- following Request logic. > 3. Return IA_* option with NoBinding -- following existing Renew logic fo= r unknown bindings. > 4. Don't return the IA_* option (I think this is not a good choice and believe you don't either). >Perhaps new #2 is the best as it matches the Request ... Renew and Request are really very similar anyway #2 & # 3 sounds roughly the same to me. Could the client directly interpret the 'NoBinding' to be 'NoAddrsAvail (or NoPrefixAvail)' here? Bernie - BTW: The case for a Rebind where the server can't find the client entry for the IA is not covered in RFC 3315 (it is if the addresses are no longer appropriate, but not otherwise). In some ways, this missing text leaves it up to the server (which for some cases, may be good - for example= , Failover may trust the client and if there is no conflict, the server may want to respond -- that is what we do in V4). In other instances, the serve= r might want to drop the Rebind or respond with NoBindings to force client back to Solicit? Also, the Rebind is missing the text that allows the serve= r to change the addresses as appears in Renew. Do we need more text on REBIND here? Sounds like the same behavior as the RENEW at server side: (referring to section 18.2.3 of RFC3315) a. If the server cannot find a client entry for the IA, the server returns the IA containing with a Status Code option set to NoBinding in the Reply message. b. The server may choose to change the list of addresses/prefixes and their lifetimes in IAs that are returned to the client. (I think we'd mention IA_PD in the updates of RFC3315) Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bud Millwood Sent: Tuesday, January 22, 2013 9:22 AM To: Bernie Volz (volz) Cc: dhc WG; Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 On Tue, Jan 22, 2013 at 12:24 AM, Bernie Volz (volz) wrote= : >>The original text says to return an IA_* with no addr/prefix and a status code "NoBinding". Now, if we cannot fulfill the binding, we do the same thing, but we don't include a status code. Is that right? > > Hum ... perhaps it is best to follow the Request and return NoAddrsAvail status in the IA_* option (of course we'd need to update RFC 3633 text then as well to return NoPrefixAvail). > > The choices now seem to be: > 1. Just return the IA_* option (empty). > 2. Return IA_* option with NoAddrsAvail (or NoPrefixAvail) -- following Request logic. > 3. Return IA_* option with NoBinding -- following existing Renew logic fo= r unknown bindings. > 4. Don't return the IA_* option (I think this is not a good choice and believe you don't either). > > Perhaps new #2 is the best as it matches the Request ... Renew and Reques= t are really very similar anyway - the main differences were: > - We are telling the server the client is renewing (thus is using the=20 > leases) > - No new bindings were 'allowed' -- this is now not true and what we are proposing to change. I think #2 is best approach. Since we can now create bindings in Renew, and a client should be prepared to obtain a new lease at this time, it's basically the same thing as Request from the standpoint of the protocol. An= d judging by the names of the error codes, NoAddrsAvail and NoPrefixAvail see= m better because they reflect the server's inability to create a binding. "NoBinding" seems more like "No info, can't proceed" (which is more suited the previous behavior). > We could do the same for the Rebind. I suppose my argument in favor of this is the same as above. If the client must be prepared to accept a new lease at this time, it's like a "deferred Request". > BTW: The case for a Rebind where the server can't find the client entry for the IA is not covered in RFC 3315 (it is if the addresses are no longer appropriate, but not otherwise). In some ways, this missing text leaves it up to the server (which for some cases, may be good - for example, Failover may trust the client and if there is no conflict, the server may want to respond -- that is what we do in V4). In other instances, the server might want to drop the Rebind or respond with NoBindings to force client back to Solicit? Also, the Rebind is missing the text that allows the server to change the addresses as appears in Renew. Maybe it's important to distinguish between not being able to create a new binding for a non-existent lease (NoAddrsAvail/NoPrefixAvail) and not being able to create a new binding for an existing lease? (Or for that matter, fo= r the latter, not being able to rebind the addr/prefix in question due to lac= k of information). - Bud > > Opinions? > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf=20 > Of Bud Millwood > Sent: Monday, January 21, 2013 5:52 PM > To: Bernie Volz (volz) > Cc: dhc WG; Ted Lemon > Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 > >> Regarding 4.2, how is that? It always means no addresses available but may mean prefixes available. > > Yes of course; I should have reviewed 3633. > >> Regarding 4.4, I would expect the server to return the IA_* option but without any IAADDR/IAPREFIX options. (The server would not really create a record of this binding since it has no leases.) Perhaps the text should be clarified regarding this. > > The original text says to return an IA_* with no addr/prefix and a status code "NoBinding". Now, if we cannot fulfill the binding, we do the same thing, but we don't include a status code. Is that right? > >> Note that perhaps a question exists as to which behavior to document for the Reply in this case: >> 1. Return the IA_* option, empty. >> 2. Do not return the IA_* option. >> Either approach would work. 1 may provide more information to the client (but client implementers may prefer 2) -- it is also sending back what the client sent (since it had no IAADDR/IAPREFIXes to include). > > (1) makes more sense to me because the server is explicitly acknowledging the IA_*. > > - Bud > >> Regarding 4.5, ok one of those edits can be done in a -04 (after 28th when WGLC ends). Usually the RFC-Editor also catches things like this, but best to give them a better document to start with. >> >> - Bernie >> >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On=20 >> Behalf Of Bud Millwood >> Sent: Monday, January 21, 2013 10:28 AM >> To: Gaurav Halwasia (ghalwasi) >> Cc: dhc WG; Bernie Volz (volz); Ted Lemon >> Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >> >> 4.2: Proposed solution: No change. For backwards compatibility, the >> NoAddrsAvail Status Code option when no addresses are available will >> be kept in the global scope for Advertise messages. >> >> Question: Does it need to be further clarified that in Advertise, "NoAddrsAvail" now may mean "SomeAddrsAvail"? >> >> 4.4: Note that clients that communicate with servers that do not support >> this updated Renew processing will receive the NoBinding status for >> the IA which had no bindings. >> >> Question: isn't this also a valid response if the server does support updated Renew processing, but cannot fulfill the binding for the IA? >> >> 4.5: It lets a server without a binding to reply to >> the message, under the assumption that the server only needs >> knowledge about the prefix(es) on the link, to inform the client that >> the address is likely valid or not. >> >> - Change "lets" to "enables" or "allows", alt. remove "to" between "binding" and "reply". >> >> - Bud >> >> >> On Wed, Jan 16, 2013 at 5:43 AM, Gaurav Halwasia (ghalwasi) wrote: >>> Thanks for taking care of comments. I agree with you point regarding point (3). >>> >>> -Gaurav >>> >>> -----Original Message----- >>> From: Bernie Volz (volz) >>> Sent: Wednesday, January 16, 2013 2:38 AM >>> To: Gaurav Halwasia (ghalwasi); Ted Lemon; dhc WG >>> Subject: RE: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >>> >>> Hi: >>> >>> Thanks for the comments, I've made some comments below (BV>). >>> >>> Let's wait until the 28th before I draft the -04 version. Hopefully there will be more comments! >>> >>> - Bernie >>> >>> -----Original Message----- >>> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On=20 >>> Behalf Of Gaurav Halwasia (ghalwasi) >>> Sent: Monday, January 14, 2013 10:47 PM >>> To: Ted Lemon; dhc WG >>> Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >>> >>> I read/reviewed this document and I support this document to move forward. >>> >>> I do have some comments and it would be good if authors can consider them. Even otherwise I support this document. >>> >>> 1.) In Abstract :- >>> >>> "Implementation experience of the CPE model >>> described in has shown multiple issues" >>> I think you wanted to specify RFC6204 after "described in" >>> >>> BV> Yes. >>> >>> 2.) Section 4.2 Placement of Status codes. >>> In Reply messages IA specific status codes (NoAddrsAvail, NotOnlink, >>> NoBinding) are encapsulated in the IA option. >>> I think we should include "NoPrefixAvail" as well in the above line. I see no reason why it should not be. >>> >>> BV> Yes. Might be best to use (i.e.) too so that it is clear that this is just a partial list. >>> >>> 3.) For Confirm message. As I understand, we are now allowing=20 >>> CONFIRM message for IA_PD. I think we should update the definition=20 >>> of CONFIRM message in RFC3315 which currently only talks about=20 >>> *address* >>> >>> >>> CONFIRM (4) A client sends a Confirm message to any >>> available server to determine whether the >>> addresses it was assigned are still appropriat= e >>> to the link to which the client is connected. >>> >>> >>> BV> Well this is a bit tricky as RFC 3315 knows nothing of prefix allocation. A RFC 3315bis would definitely want to reword it as such (as I would expect it to combine 3315 and 3633). This really falls into the changes to RFC 3633 that it would extend Confirm to include prefixes. We tried (I hope) to keep the RFC 3315 changes consistent with what RFC 3315 contained and PD changes to RFC 3633. There might be more we could add to RFC 3633, but do we really think that is necessary? I guess we could replac= e "addresses" with something more generic ("configuration information explicitly assigned to the client", which comes from the definition of binding in RFC 3315), but I think that doesn't really improve anything. >>> >>> BV> Thus, I will not make this change. >>> >>> >>> Thanks, >>> Gaurav >>> -----Original Message----- >>> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On=20 >>> Behalf Of Ted Lemon >>> Sent: Tuesday, January 15, 2013 1:04 AM >>> To: dhc WG >>> Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >>> >>> On Jan 14, 2013, at 2:15 PM, Bernie Volz (volz) wrote: >>>> A 2nd Query regarding this as I heard nothing since the first. >>> >>> Oops, sorry about that, Bernie. >>> >>> Folks, the authors of this draft feel it's ready for a WGLC. There's been substantial discussion and comment already. This is pretty important IPv6 deployment work, so more eyes are better. Please review the draft an= d indicate whether or not you feel it is ready to be published. We have bee= n getting very anemic responses to working group messages recently. Your response matters, so please do respond. >>> >>> We will evaluate consensus after January 28. Thanks! >>> >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From leaf.yeh.sdo@gmail.com Mon Feb 18 08:58:24 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3E321F8AA3 for ; Mon, 18 Feb 2013 08:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_IP_219128=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wu7cIaiK0UQx for ; Mon, 18 Feb 2013 08:58:23 -0800 (PST) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB6521F8A4E for ; Mon, 18 Feb 2013 08:58:22 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id bg4so2871626pad.26 for ; Mon, 18 Feb 2013 08:58:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=t0TtLvTyIXeXaPPPbk3QBVMA8HhxmmcmuNIGKO6oOUg=; b=VNpHzZMdBvIV8ZSqOgrTpCmeTJDvFyHoLNJO9Q16nBegATX5wUMiM6GET8W5u0ngmN x6rm/703YcAMvFHJSA3+nHPyDl6cMIXe3xrah93QErOu4ZhEafvENRq2iDkYnj0m2jwD uOQgqt1APR1s/z5F8A9F2TKj9966DsbJoVqbbwsuzoWZ5JL4q94NBx6ceTVIK8J7OLi8 YmEAom+H5ftL12510p6LslyYHykMdiKn74/3FLJB5ycPSEUOCMXsev4iTNgtzG8ZdOOZ u5CMg7vDjyLDEqY9I9Hl+sgkN7r9bPgC05+Mt8y7qEquIrVQtiWz89LLX09YcuNiU2FV urXQ== X-Received: by 10.68.42.9 with SMTP id j9mr31986702pbl.142.1361206702363; Mon, 18 Feb 2013 08:58:22 -0800 (PST) Received: from PC ([219.133.128.178]) by mx.google.com with ESMTPS id bi2sm104307273pab.18.2013.02.18.08.58.13 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 18 Feb 2013 08:58:21 -0800 (PST) From: "Leaf Yeh" To: "'Bernie Volz \(volz\)'" References: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> <90903C21C73202418A48BFBE80AEE5EB22DEB892@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843CA16@xmb-rcd-x04.cisco.com> <90903C21C73202418A48BFBE80AEE5EB22DEDE19@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E18442EC0@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E184431CF@xmb-rcd-x04.cisco.com> <5121d938.294e420a.5385.55c5@mx.google.com> <489D13FBFA9B3E41812EA89F188F018E1847035E@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1847035E@xmb-rcd-x04.cisco.com> Date: Tue, 19 Feb 2013 00:58:03 +0800 Message-ID: <51225dad.c258420a.6d66.ffffd588@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHN9+v1hlVR97tQwEWdQEw5vWHbDZhT66CwgADdE4D//5438IAn3CtwgAOrH4CAAAqIIA== Content-Language: zh-cn Cc: 'dhc WG' Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-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, 18 Feb 2013 16:58:24 -0000 E2. Editorial - Page 3 - Section 3 < snip >Each IA holds one type of IA option; for example, ... LY> Does it mean IA_NA and IA-PD will never share the same IA? I guess the better text could be 'Each IA option holds one type, for example,... ' BV> I am not sure what you are asking here. An instance of an IA is a IA_NA or IA_PD. IA is short for Identity Association. Note that this just updates RFC 3315's definition which was address based. IA(Identity Association) is specified by IAID, which sounds associated with the client's interface. My question is whether a IA-NA and a IA_PD could have the same IAID? If yes, my text might be better. T1. Page 7 - Section 4.4 The client also includes an IA option for each binding it desires but has been unable to obtain. LY> Could the above text be replaced by the original text in RFC3315? 'The client MUST include an Option Request option (see section 22.7) to indicate the options the client is interested in receiving. The client MAY include options with data values as hints to the server about parameter values the client would like to have returned.' BV> ORO are not used for IA_NA/IA_PD/IA_TA. Not 100% sure about this point. I can't find the referenced text in RFC3315 yet. BV> As the client must assign an IAID so it must send the IA_* option. The might mean that IA_xx should also be included after ORO. I meant the original text in RFC3315 might cover the case of the above new suggested text in the new draft. Best Regards, Leaf -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Tuesday, February 19, 2013 12:10 AM To: Leaf Yeh Cc: 'dhc WG' Subject: RE: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 Hi: Thanks for the thorough review. Some comments below (BV>). - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Leaf Yeh Sent: Monday, February 18, 2013 2:33 AM To: Bernie Volz (volz) Cc: 'dhc WG' Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 E1. Editorial - How about change the title of the draft to be 'Updates of RFC 3315 and RFC3633 with multiple stateful options'? BV> While we could change the title, I don't really see this as that critical. The updates could be summarized as follows: a. Client should keep a single session with the multiple stateful options (in subsequent messages, Request, Renew, and Rebind, to the server.) b. Ideally the Status Code option should be encapsulated in the IA option for all DHCP messages. This makes Advertisement messages equal to Reply messages. (A new recommendation to the server though there is a issue for backwards compatibility) c. The server SHOULD set the T1/T2 timers in all IA options in Reply and Advertise messages to the same value. (A new recommendation to the server) d. makes the server's IA processing of Renew and Rebind similar to the Request processing (but ORO sounds also make it). e. Allow the Confirm message work for DHCPv6-PD. Right? BV> Yes, except for D and ORO. (See below.) E2. Editorial - Page 3 - Section 3 < snip >Each IA holds one type of IA option; for example, ... Does it mean IA_NA and IA-PD will never share the same IA? I guess the better text could be 'Each IA option holds one type, for example,... ' BV> I am not sure what you are asking here. An instance of an IA is a IA_NA or IA_PD. IA is short for Identity Association. Note that this just updates RFC 3315's definition which was address based. T1. Page 7 - Section 4.4 The client also includes an IA option for each binding it desires but has been unable to obtain. Could the above text be replaced by the original text in RFC3315? 'The client MUST include an Option Request option (see section 22.7) to indicate the options the client is interested in receiving. The client MAY include options with data values as hints to the server about parameter values the client would like to have returned.' BV> ORO are not used for IA_NA/IA_PD/IA_TA. As the client must assign an IAID so it must send the IA_* option. T2. Technical - Page 7- Section 4.4 If the server cannot find a client entry for the IA the server creates the bindings for that client according to the server's policy and configuration information and records the IAs and other information requested by the client. Not sure the above sounds a necessary behavior of the server. What is the issue if the server doesn't create the bindings for that client when the server cannot find a client entry for the IA? BV> Interesting point and the text should probably be revised to allow the older behavior as servers might not be updated. E3. Editorial - Page 7 - Section 4.4 However, it MUST limit the frequency at which is does this to no more often than the renewal frequency. I guess the right text sounds '...at which it does this to... '. BV> Yes. This should be it, not is. E4. Editorial - Page 8 - Section 4.5 If such verification is needed the requesting router MUST initiate a Confirm message exchange as described in section 18.1.2, "Creation and Transmission of Confirm Messages" of RFC 3315. The above text sounds '...MUST initiate a Confirm/Reply message exchange...'. BV> Yes. To we should add /Reply. E5. Editorial - Saw many 'should's have not been in the format of 'SHOULD' yet. BV> There may be a few that could be changed to SHOULD. In general, only the proposed solution and changes would have these capitalized per RFC 2119. I think there are only 2 to consider for should -> SHOULD - in 4. and 4.4. in proposed solution text. For must -> MUST, 4.6. There are a few grey areas that may also switch the case ... I think for the discuss text we may want to lower case. I'll discuss this with Ole and see what we do for a revised draft. If someone has a strong opinion one way or the other, please let us know. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Tuesday, January 22, 2013 7:25 AM To: Bud Millwood Cc: dhc WG; Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >The original text says to return an IA_* with no addr/prefix and a >status code "NoBinding". Now, if we cannot fulfill the binding, we do the same thing, but we don't include a status code. Is that right? Hum ... perhaps it is best to follow the Request and return NoAddrsAvail status in the IA_* option (of course we'd need to update RFC 3633 text then as well to return NoPrefixAvail). The choices now seem to be: 1. Just return the IA_* option (empty). 2. Return IA_* option with NoAddrsAvail (or NoPrefixAvail) -- following Request logic. 3. Return IA_* option with NoBinding -- following existing Renew logic for unknown bindings. 4. Don't return the IA_* option (I think this is not a good choice and believe you don't either). Perhaps new #2 is the best as it matches the Request ... Renew and Request are really very similar anyway - the main differences were: - We are telling the server the client is renewing (thus is using the leases) - No new bindings were 'allowed' -- this is now not true and what we are proposing to change. We could do the same for the Rebind. BTW: The case for a Rebind where the server can't find the client entry for the IA is not covered in RFC 3315 (it is if the addresses are no longer appropriate, but not otherwise). In some ways, this missing text leaves it up to the server (which for some cases, may be good - for example, Failover may trust the client and if there is no conflict, the server may want to respond -- that is what we do in V4). In other instances, the server might want to drop the Rebind or respond with NoBindings to force client back to Solicit? Also, the Rebind is missing the text that allows the server to change the addresses as appears in Renew. Opinions? - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bud Millwood Sent: Monday, January 21, 2013 5:52 PM To: Bernie Volz (volz) Cc: dhc WG; Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 > Regarding 4.2, how is that? It always means no addresses available but > may mean prefixes available. Yes of course; I should have reviewed 3633. > Regarding 4.4, I would expect the server to return the IA_* option but without any IAADDR/IAPREFIX options. (The server would not really create a record of this binding since it has no leases.) Perhaps the text should be clarified regarding this. The original text says to return an IA_* with no addr/prefix and a status code "NoBinding". Now, if we cannot fulfill the binding, we do the same thing, but we don't include a status code. Is that right? > Note that perhaps a question exists as to which behavior to document > for the Reply in this case: > 1. Return the IA_* option, empty. > 2. Do not return the IA_* option. > Either approach would work. 1 may provide more information to the > client (but client implementers may prefer 2) -- it is also sending back what the client sent (since it had no IAADDR/IAPREFIXes to include). (1) makes more sense to me because the server is explicitly acknowledging the IA_*. - Bud > Regarding 4.5, ok one of those edits can be done in a -04 (after 28th > when WGLC ends). Usually the RFC-Editor also catches things like this, but best to give them a better document to start with. > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Bud Millwood > Sent: Monday, January 21, 2013 10:28 AM > To: Gaurav Halwasia (ghalwasi) > Cc: dhc WG; Bernie Volz (volz); Ted Lemon > Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 > > 4.2: Proposed solution: No change. For backwards compatibility, the > NoAddrsAvail Status Code option when no addresses are available will > be kept in the global scope for Advertise messages. > > Question: Does it need to be further clarified that in Advertise, "NoAddrsAvail" now may mean "SomeAddrsAvail"? > > 4.4: Note that clients that communicate with servers that do not support > this updated Renew processing will receive the NoBinding status for > the IA which had no bindings. > > Question: isn't this also a valid response if the server does support updated Renew processing, but cannot fulfill the binding for the IA? > > 4.5: It lets a server without a binding to reply to > the message, under the assumption that the server only needs > knowledge about the prefix(es) on the link, to inform the client that > the address is likely valid or not. > > - Change "lets" to "enables" or "allows", alt. remove "to" between "binding" and "reply". > > - Bud > > > On Wed, Jan 16, 2013 at 5:43 AM, Gaurav Halwasia (ghalwasi) wrote: >> Thanks for taking care of comments. I agree with you point regarding point (3). >> >> -Gaurav >> >> -----Original Message----- >> From: Bernie Volz (volz) >> Sent: Wednesday, January 16, 2013 2:38 AM >> To: Gaurav Halwasia (ghalwasi); Ted Lemon; dhc WG >> Subject: RE: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >> >> Hi: >> >> Thanks for the comments, I've made some comments below (BV>). >> >> Let's wait until the 28th before I draft the -04 version. Hopefully >> there will be more comments! >> >> - Bernie >> >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On >> Behalf Of Gaurav Halwasia (ghalwasi) >> Sent: Monday, January 14, 2013 10:47 PM >> To: Ted Lemon; dhc WG >> Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >> >> I read/reviewed this document and I support this document to move forward. >> >> I do have some comments and it would be good if authors can consider them. Even otherwise I support this document. >> >> 1.) In Abstract :- >> >> "Implementation experience of the CPE model >> described in has shown multiple issues" >> I think you wanted to specify RFC6204 after "described in" >> >> BV> Yes. >> >> 2.) Section 4.2 Placement of Status codes. >> In Reply messages IA specific status codes (NoAddrsAvail, NotOnlink, >> NoBinding) are encapsulated in the IA option. >> I think we should include "NoPrefixAvail" as well in the above line. >> I see no reason why it should not be. >> >> BV> Yes. Might be best to use (i.e.) too so that it is clear that >> BV> this is just a partial list. >> >> 3.) For Confirm message. As I understand, we are now allowing CONFIRM >> message for IA_PD. I think we should update the definition of CONFIRM >> message in RFC3315 which currently only talks about *address* >> >> >> CONFIRM (4) A client sends a Confirm message to any >> available server to determine whether the >> addresses it was assigned are still appropriate >> to the link to which the client is connected. >> >> >> BV> Well this is a bit tricky as RFC 3315 knows nothing of prefix allocation. A RFC 3315bis would definitely want to reword it as such (as I would expect it to combine 3315 and 3633). This really falls into the changes to RFC 3633 that it would extend Confirm to include prefixes. We tried (I hope) to keep the RFC 3315 changes consistent with what RFC 3315 contained and PD changes to RFC 3633. There might be more we could add to RFC 3633, but do we really think that is necessary? I guess we could replace "addresses" with something more generic ("configuration information explicitly assigned to the client", which comes from the definition of binding in RFC 3315), but I think that doesn't really improve anything. >> >> BV> Thus, I will not make this change. >> >> >> Thanks, >> Gaurav >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On >> Behalf Of Ted Lemon >> Sent: Tuesday, January 15, 2013 1:04 AM >> To: dhc WG >> Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >> >> On Jan 14, 2013, at 2:15 PM, Bernie Volz (volz) wrote: >>> A 2nd Query regarding this as I heard nothing since the first. >> >> Oops, sorry about that, Bernie. >> >> Folks, the authors of this draft feel it's ready for a WGLC. There's been substantial discussion and comment already. This is pretty important IPv6 deployment work, so more eyes are better. Please review the draft and indicate whether or not you feel it is ready to be published. We have been getting very anemic responses to working group messages recently. Your response matters, so please do respond. >> >> We will evaluate consensus after January 28. Thanks! >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ 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 Feb 18 09:29:09 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3CD21F8C4F for ; Mon, 18 Feb 2013 09:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwU3jRqP-ZAZ for ; Mon, 18 Feb 2013 09:29:07 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7C41D21F8C3E for ; Mon, 18 Feb 2013 09:29:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21276; q=dns/txt; s=iport; t=1361208547; x=1362418147; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=111Hlh4JmUhjeFlwAK28SYo0kKDti6Hyl2+YEIDSpd4=; b=LhwiNQPHCL3Uxq5pUGoNFr2KTMfr1v4yBesCJDYwd+kSMIubnWyI6fR7 dRewUYMjryjAt5NgaB7oJNEbY9h8qVkpaXcLLdLfHjbIPxk23wt4hoLKX +tPLLdiXiA5I7o02VILZ82SplRezsuYpQp2+AXxxZKLCmtNwZsnXWxBUC 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOtjIlGtJXG8/2dsb2JhbAA7CcAjgQQWc4IfAQEBAwEBAQEkEzQLBQcEAgEIEQQBAQEKFAkHJwsUCQgCBA4FCBOHcQYMwGMEjW0EgRUmCwcGgllhA6cEgweBaQEfBBo X-IronPort-AV: E=Sophos;i="4.84,689,1355097600"; d="scan'208";a="178410420" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 18 Feb 2013 17:29:06 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1IHT6sa027876 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Feb 2013 17:29:06 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Mon, 18 Feb 2013 11:29:06 -0600 From: "Bernie Volz (volz)" To: Leaf Yeh Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 Thread-Index: AQHN9+v1hlVR97tQwEWdQEw5vWHbDZhT66CwgADdE4D//5438IAn3CtwgAOrH4CAAAqIIIAADE8g Date: Mon, 18 Feb 2013 17:29:05 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E18470444@xmb-rcd-x04.cisco.com> References: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> <90903C21C73202418A48BFBE80AEE5EB22DEB892@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843CA16@xmb-rcd-x04.cisco.com> <90903C21C73202418A48BFBE80AEE5EB22DEDE19@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E18442EC0@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E184431CF@xmb-rcd-x04.cisco.com> <5121d938.294e420a.5385.55c5@mx.google.com> <489D13FBFA9B3E41812EA89F188F018E1847035E@xmb-rcd-x04.cisco.com> <51225dad.c258420a.6d66.ffffd588@mx.google.com> In-Reply-To: <51225dad.c258420a.6d66.ffffd588@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.246.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'dhc WG' Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-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, 18 Feb 2013 17:29:09 -0000 An IA is an identity association which consists of the type (NA, TA, PD) an= d the IAID. IAID value is only unique to IA type. So, a client can well spe= cify IA_NA IAID 1 and IA_PD IAID 1. Here's the RFC 3315 text: Identity association (IA) A collection of addresses assigned to a client. Each IA has an associated IAID. A client may have more than one IA assigned to it; for example, one for each of its interfaces. Each IA holds one type of address; for example, an identity association for temporary addresses (IA_TA) holds temporary addresses (see "identity association for temporary addresses"). Throughout this document, "IA" is used to refer to an identity association without identifying the type of addresses in the IA. Here's the draft text to define this to make it more generic: Identity association (IA): A collection of stateful options assigned to a client. Each IA has an associated IAID. A client may have more than one IA assigned to it; for example, one for each of its interfaces. Each IA holds one type of IA option; for example, an identity association for temporary addresses (IA_TA) holds temporary addresses (see "identity association for temporary addresses"). Throughout this document, "IA" is used to refer to an identity association without identifying the type of stateful option in the IA. I think the text in question (Each IA holds one type of IA option) is suppo= sed to mean IAADDR or IAPREFIX (but it could also have referred to IA_NA, I= A_TA, IA_PD)? We don't want to enumerate the types as there could be more d= efined in the future. (I think Ole wrote this text in the initial version o= f the draft, so perhaps he can clarify; but it may also have been tweaked a= long the way.)=20 Perhaps to relate this better to the RFC 3315 definition of 'binding' we in= stead use: Identity association (IA): A collection of stateful options assigned to a client. Each IA has an IA-type and ass= ociated IAID. A client may have more than one IA assigned to it; for example, one for each of its interfaces. Each IA holds one type of stateful options; for example, an identity association for temporary addresses (IA_TA) holds temporary addresses (see "identity association for temporary addresses"). Throughout this document, "IA" is used to refer to an identity association without identifying the type of stateful option in the IA. >BV> ORO are not used for IA_NA/IA_PD/IA_TA.=20 > >Not 100% sure about this point. I can't find the referenced text in RFC331= 5 yet. I'm not sure that text is there, but neither is there text to say to add it= . (Our server ignores IA_NA, IA_PD, IA_TA in the ORO if it is there because= there is EXPLICIT processing for this already in RFC 3315/3633 so there is= no need to do anything based on the ORO for these options. Some clients do= add it.) Note that there is no text that the ORO should include the Server-ID option= ; a server is REQUIRED to add this always. The requirement for adding options into the ORO is really for those options= that have no explicit processing (such as the DNS resolver address).=20 - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of L= eaf Yeh Sent: Monday, February 18, 2013 11:58 AM To: Bernie Volz (volz) Cc: 'dhc WG' Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 E2. Editorial - Page 3 - Section 3 < snip >Each IA holds one type of IA option; for example, ... LY> Does it mean IA_NA and IA-PD will never share the same IA? I guess=20 LY> the better text could be 'Each IA option holds one type, for example,... ' BV> I am not sure what you are asking here. An instance of an IA is a=20 BV> IA_NA or IA_PD. IA is short for Identity Association. Note that this just updates= RFC 3315's definition which was address based. IA(Identity Association) is specified by IAID, which sounds associated with= the client's interface. My question is whether a IA-NA and a IA_PD could h= ave the same IAID? If yes, my text might be better. T1. Page 7 - Section 4.4 The client also includes an IA option for each binding it desires but= has been unable to obtain. LY> Could the above text be replaced by the original text in RFC3315?=20 'The client MUST include an Option Request option (see section 22.7) to ind= icate the options the client is interested in receiving. The client MAY inc= lude options with data values as hints to the server about parameter values= the client would like to have returned.' BV> ORO are not used for IA_NA/IA_PD/IA_TA.=20 Not 100% sure about this point. I can't find the referenced text in RFC3315= yet. BV> As the client must assign an IAID so it must send the IA_* option. The might mean that IA_xx should also be included after ORO.=20 I meant the original text in RFC3315 might cover the case of the above new = suggested text in the new draft. Best Regards, Leaf -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Tuesday, February 19, 2013 12:10 AM To: Leaf Yeh Cc: 'dhc WG' Subject: RE: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 Hi: Thanks for the thorough review. Some comments below (BV>). - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of L= eaf Yeh Sent: Monday, February 18, 2013 2:33 AM To: Bernie Volz (volz) Cc: 'dhc WG' Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 E1. Editorial - How about change the title of the draft to be 'Updates of R= FC 3315 and RFC3633 with multiple stateful options'? BV> While we could change the title, I don't really see this as that critical. The updates could be summarized as follows: a. Client should keep a single session with the multiple stateful options (= in subsequent messages, Request, Renew, and Rebind, to the server.) b. Ideally the Status Code option should be encapsulated in the IA option for = all DHCP messages. This makes Advertisement messages equal to Reply message= s. (A new recommendation to the server though there is a issue for backward= s compatibility) c. The server SHOULD set the T1/T2 timers in all IA option= s in Reply and Advertise messages to the same value. (A new recommendation = to the server) d. makes the server's IA processing of Renew and Rebind simi= lar to the Request processing (but ORO sounds also make it). e. Allow the Confirm message work for DHCPv6-PD. Right? BV> Yes, except for D and ORO. (See below.) E2. Editorial - Page 3 - Section 3 < snip >Each IA holds one type of IA option; for example, ... Does it mean IA_NA and IA-PD will never share the same IA? I guess the bett= er text could be 'Each IA option holds one type, for example,... ' BV> I am not sure what you are asking here. An instance of an IA is a=20 BV> IA_NA or IA_PD. IA is short for Identity Association. Note that this just updates= RFC 3315's definition which was address based. T1. Page 7 - Section 4.4 The client also includes an IA option for each binding it desires but= has been unable to obtain. Could the above text be replaced by the original text in RFC3315?=20 'The client MUST include an Option Request option (see section 22.7) to ind= icate the options the client is interested in receiving. The client MAY inc= lude options with data values as hints to the server about parameter values= the client would like to have returned.' BV> ORO are not used for IA_NA/IA_PD/IA_TA. As the client must assign an IAID so it must send the IA_* option. T2. Technical - Page 7- Section 4.4 If the server cannot find a client entry for the IA the server create= s the bindings for that client according to the server's policy and configu= ration information and records the IAs and other information requested by t= he client. Not sure the above sounds a necessary behavior of the server. What is the i= ssue if the server doesn't create the bindings for that client when the server cannot find a client entry for the IA?=09 BV> Interesting point and the text should probably be revised to allow=20 BV> the older behavior as servers might not be updated. E3. Editorial - Page 7 - Section 4.4 However, it MUST limit the frequency at which is does this to no more= often than the renewal frequency. I guess the right text sounds '...at which it does this to... '. BV> Yes. This should be it, not is. E4. Editorial - Page 8 - Section 4.5 If such verification is needed the requesting router MUST initiate a= Confirm message exchange as described in section 18.1.2, "Creation and Tra= nsmission of Confirm Messages" of RFC 3315. The above text sounds '...MUST initiate a Confirm/Reply message exchange...= '. BV> Yes. To we should add /Reply. E5. Editorial - Saw many 'should's have not been in the format of 'SHOULD' yet. BV> There may be a few that could be changed to SHOULD. In general, only=20 BV> the proposed solution and changes would have these capitalized per RFC 2119. I = think there are only 2 to consider for should -> SHOULD - in 4. and 4.4. i= n proposed solution text. For must -> MUST, 4.6. There are a few grey areas= that may also switch the case ... I think for the discuss text we may want= to lower case. I'll discuss this with Ole and see what we do for a revised= draft. If someone has a strong opinion one way or the other, please let us= know. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ernie Volz (volz) Sent: Tuesday, January 22, 2013 7:25 AM To: Bud Millwood Cc: dhc WG; Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >The original text says to return an IA_* with no addr/prefix and a=20 >status code "NoBinding". Now, if we cannot fulfill the binding, we do the same thi= ng, but we don't include a status code. Is that right? Hum ... perhaps it is best to follow the Request and return NoAddrsAvail st= atus in the IA_* option (of course we'd need to update RFC 3633 text then a= s well to return NoPrefixAvail). The choices now seem to be: 1. Just return the IA_* option (empty). 2. Return IA_* option with NoAddrsAvail (or NoPrefixAvail) -- following Req= uest logic. 3. Return IA_* option with NoBinding -- following existing Renew logic for = unknown bindings. 4. Don't return the IA_* option (I think this is not a good choice and beli= eve you don't either). Perhaps new #2 is the best as it matches the Request ... Renew and Request = are really very similar anyway - the main differences were: - We are telling the server the client is renewing (thus is using the leases) - No new bindings were 'allowed' -- this is now not true and what we are pr= oposing to change. We could do the same for the Rebind. BTW: The case for a Rebind where the server can't find the client entry for= the IA is not covered in RFC 3315 (it is if the addresses are no longer ap= propriate, but not otherwise). In some ways, this missing text leaves it up= to the server (which for some cases, may be good - for example, Failover m= ay trust the client and if there is no conflict, the server may want to res= pond -- that is what we do in V4). In other instances, the server might wan= t to drop the Rebind or respond with NoBindings to force client back to Sol= icit? Also, the Rebind is missing the text that allows the server to change= the addresses as appears in Renew.=20 Opinions? - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ud Millwood Sent: Monday, January 21, 2013 5:52 PM To: Bernie Volz (volz) Cc: dhc WG; Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 > Regarding 4.2, how is that? It always means no addresses available but=20 > may mean prefixes available. Yes of course; I should have reviewed 3633. > Regarding 4.4, I would expect the server to return the IA_* option but without any IAADDR/IAPREFIX options. (The server would not really create a = record of this binding since it has no leases.) Perhaps the text should be = clarified regarding this. The original text says to return an IA_* with no addr/prefix and a status c= ode "NoBinding". Now, if we cannot fulfill the binding, we do the same thin= g, but we don't include a status code. Is that right? > Note that perhaps a question exists as to which behavior to document=20 > for the Reply in this case: > 1. Return the IA_* option, empty. > 2. Do not return the IA_* option. > Either approach would work. 1 may provide more information to the=20 > client (but client implementers may prefer 2) -- it is also sending back what the = client sent (since it had no IAADDR/IAPREFIXes to include). (1) makes more sense to me because the server is explicitly acknowledging t= he IA_*. - Bud > Regarding 4.5, ok one of those edits can be done in a -04 (after 28th=20 > when WGLC ends). Usually the RFC-Editor also catches things like this, but best = to give them a better document to start with. > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf=20 > Of Bud Millwood > Sent: Monday, January 21, 2013 10:28 AM > To: Gaurav Halwasia (ghalwasi) > Cc: dhc WG; Bernie Volz (volz); Ted Lemon > Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 > > 4.2: Proposed solution: No change. For backwards compatibility, the > NoAddrsAvail Status Code option when no addresses are available will > be kept in the global scope for Advertise messages. > > Question: Does it need to be further clarified that in Advertise, "NoAddrsAvail" now may mean "SomeAddrsAvail"? > > 4.4: Note that clients that communicate with servers that do not support > this updated Renew processing will receive the NoBinding status for > the IA which had no bindings. > > Question: isn't this also a valid response if the server does support updated Renew processing, but cannot fulfill the binding for the IA? > > 4.5: It lets a server without a binding to reply to > the message, under the assumption that the server only needs > knowledge about the prefix(es) on the link, to inform the client that > the address is likely valid or not. > > - Change "lets" to "enables" or "allows", alt. remove "to" between "binding" and "reply". > > - Bud > > > On Wed, Jan 16, 2013 at 5:43 AM, Gaurav Halwasia (ghalwasi) wrote: >> Thanks for taking care of comments. I agree with you point regarding point (3). >> >> -Gaurav >> >> -----Original Message----- >> From: Bernie Volz (volz) >> Sent: Wednesday, January 16, 2013 2:38 AM >> To: Gaurav Halwasia (ghalwasi); Ted Lemon; dhc WG >> Subject: RE: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >> >> Hi: >> >> Thanks for the comments, I've made some comments below (BV>). >> >> Let's wait until the 28th before I draft the -04 version. Hopefully=20 >> there will be more comments! >> >> - Bernie >> >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On=20 >> Behalf Of Gaurav Halwasia (ghalwasi) >> Sent: Monday, January 14, 2013 10:47 PM >> To: Ted Lemon; dhc WG >> Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >> >> I read/reviewed this document and I support this document to move forward. >> >> I do have some comments and it would be good if authors can consider them. Even otherwise I support this document. >> >> 1.) In Abstract :- >> >> "Implementation experience of the CPE model >> described in has shown multiple issues" >> I think you wanted to specify RFC6204 after "described in" >> >> BV> Yes. >> >> 2.) Section 4.2 Placement of Status codes. >> In Reply messages IA specific status codes (NoAddrsAvail, NotOnlink, >> NoBinding) are encapsulated in the IA option. >> I think we should include "NoPrefixAvail" as well in the above line.=20 >> I see no reason why it should not be. >> >> BV> Yes. Might be best to use (i.e.) too so that it is clear that=20 >> BV> this is just a partial list. >> >> 3.) For Confirm message. As I understand, we are now allowing CONFIRM=20 >> message for IA_PD. I think we should update the definition of CONFIRM=20 >> message in RFC3315 which currently only talks about *address* >> >> >> CONFIRM (4) A client sends a Confirm message to any >> available server to determine whether the >> addresses it was assigned are still appropriate >> to the link to which the client is connected. >> >> >> BV> Well this is a bit tricky as RFC 3315 knows nothing of prefix allocation. A RFC 3315bis would definitely want to reword it as such (as I = would expect it to combine 3315 and 3633). This really falls into the chang= es to RFC 3633 that it would extend Confirm to include prefixes. We tried (= I hope) to keep the RFC 3315 changes consistent with what RFC 3315 containe= d and PD changes to RFC 3633. There might be more we could add to RFC 3633,= but do we really think that is necessary? I guess we could replace "addres= ses" with something more generic ("configuration information explicitly ass= igned to the client", which comes from the definition of binding in RFC 331= 5), but I think that doesn't really improve anything. >> >> BV> Thus, I will not make this change. >> >> >> Thanks, >> Gaurav >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On=20 >> Behalf Of Ted Lemon >> Sent: Tuesday, January 15, 2013 1:04 AM >> To: dhc WG >> Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >> >> On Jan 14, 2013, at 2:15 PM, Bernie Volz (volz) wrote: >>> A 2nd Query regarding this as I heard nothing since the first. >> >> Oops, sorry about that, Bernie. >> >> Folks, the authors of this draft feel it's ready for a WGLC. There's been substantial discussion and comment already. This is pretty important IPv6 deployment work, so more eyes are better. Please review the draft an= d indicate whether or not you feel it is ready to be published. We have bee= n getting very anemic responses to working group messages recently. Your response matters, so please do respond. >> >> We will evaluate consensus after January 28. Thanks! >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From internet-drafts@ietf.org Mon Feb 18 19:57:56 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52ADB21F8CD3; Mon, 18 Feb 2013 19:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhAmp1bxb+A5; Mon, 18 Feb 2013 19:57:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836D421F8B85; Mon, 18 Feb 2013 19:57:55 -0800 (PST) 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.40 Message-ID: <20130219035755.7392.52332.idtracker@ietfa.amsl.com> Date: Mon, 18 Feb 2013 19:57:55 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-13.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, 19 Feb 2013 03:57:56 -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-13.txt Pages : 9 Date : 2013-02-18 Abstract: This document 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-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-relay-id-suboption-13 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From leaf.yeh.sdo@gmail.com Tue Feb 19 08:08:29 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F34821F8B7E for ; Tue, 19 Feb 2013 08:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.805 X-Spam-Level: X-Spam-Status: No, score=-2.805 tagged_above=-999 required=5 tests=[AWL=0.794, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmWwX+LCIvx5 for ; Tue, 19 Feb 2013 08:08:21 -0800 (PST) Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by ietfa.amsl.com (Postfix) with ESMTP id C625521F8E0F for ; Tue, 19 Feb 2013 08:08:21 -0800 (PST) Received: by mail-pb0-f51.google.com with SMTP id un15so2295480pbc.38 for ; Tue, 19 Feb 2013 08:08:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=c3vmCI2hFCzoKKmiF4WaaokaaXa++AfgkEB2LsFKKbI=; b=AF/f9+3uSo0+K+8hiaRMRfsj42qkl9OfeSZzTl7XD1dLRHOhsNT3PoSIG9IDeOwimh PTdXb3tH5zxp4iqCR8Z8GldAXKqlDuc1IUD3mXWSugpT7sVBz87+13CHyiMsRo5kQYi3 diXb8HWLgQ0zAWoRPoMEtCQ6DbEOnHqCFOWInGl1pXjqh2qiylAsMcj5lbYfEXP8ygfp RMRETvG4wUyzQ3jvpMWknJPHY3p+iwedoQ0U8OfbfxzGQMbA84kZ1mJYFWfCiMMPJyXF CnZgidvOsCgtAA9mCUAdLOq9zw6Y7TCI+UHkdgFJaEWx3gDkSgIU9EfjWg/WjKssJstn KcKQ== X-Received: by 10.68.213.231 with SMTP id nv7mr41772608pbc.85.1361290101541; Tue, 19 Feb 2013 08:08:21 -0800 (PST) Received: from PC ([218.18.219.150]) by mx.google.com with ESMTPS id qf7sm18436976pbb.2.2013.02.19.08.08.14 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 19 Feb 2013 08:08:20 -0800 (PST) From: "Leaf Yeh" To: "'Bernie Volz \(volz\)'" References: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> <90903C21C73202418A48BFBE80AEE5EB22DEB892@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843CA16@xmb-rcd-x04.cisco.com> <90903C21C73202418A48BFBE80AEE5EB22DEDE19@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E18442EC0@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E184431CF@xmb-rcd-x04.cisco.com> <5121d938.294e420a.5385.55c5@mx.google.com> <489D13FBFA9B3E41812EA89F188F018E1847035E@xmb-rcd-x04.cisco.com> <51225dad.c258420a.6d66.ffffd588@mx.google.com> <489D13FBFA9B3E41812EA89F188F018E18470444@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E18470444@xmb-rcd-x04.cisco.com> Date: Wed, 20 Feb 2013 00:08:07 +0800 Message-ID: <5123a374.2789440a.7be8.11b9@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHN9+v1hlVR97tQwEWdQEw5vWHbDZhT66CwgADdE4D//5438IAn3CtwgAOrH4CAAAqIIIAADE8ggAF9q0A= Content-Language: zh-cn Cc: 'dhc WG' Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-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, 19 Feb 2013 16:08:29 -0000 BV> Identity association (IA): A collection of stateful options assigned to a client. Each IA has an IA-type and associated IAID. A client may have more than one IA assigned to it; for example, one for each of its interfaces. Each IA holds one type of stateful options; for example, an identity association for temporary addresses (IA_TA) holds temporary addresses (see "identity association for temporary addresses"). Throughout this document, "IA" is used to refer to an identity association without identifying the type of stateful option in the IA. The above new text sounds not the best yet. :-) Per the above text, IA is a 'A collection of stateful options (eg. IA_xx) assigned to a client.', which sounds "Each 'IA_xx' holds one type of stateful options." Right? BV> Our server ignores IA_NA, IA_PD, IA_TA in the ORO. Got it. Best Regards, Leaf -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Tuesday, February 19, 2013 1:29 AM To: Leaf Yeh Cc: 'dhc WG' Subject: RE: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 An IA is an identity association which consists of the type (NA, TA, PD) and the IAID. IAID value is only unique to IA type. So, a client can well specify IA_NA IAID 1 and IA_PD IAID 1. Here's the RFC 3315 text: Identity association (IA) A collection of addresses assigned to a client. Each IA has an associated IAID. A client may have more than one IA assigned to it; for example, one for each of its interfaces. Each IA holds one type of address; for example, an identity association for temporary addresses (IA_TA) holds temporary addresses (see "identity association for temporary addresses"). Throughout this document, "IA" is used to refer to an identity association without identifying the type of addresses in the IA. Here's the draft text to define this to make it more generic: Identity association (IA): A collection of stateful options assigned to a client. Each IA has an associated IAID. A client may have more than one IA assigned to it; for example, one for each of its interfaces. Each IA holds one type of IA option; for example, an identity association for temporary addresses (IA_TA) holds temporary addresses (see "identity association for temporary addresses"). Throughout this document, "IA" is used to refer to an identity association without identifying the type of stateful option in the IA. I think the text in question (Each IA holds one type of IA option) is supposed to mean IAADDR or IAPREFIX (but it could also have referred to IA_NA, IA_TA, IA_PD)? We don't want to enumerate the types as there could be more defined in the future. (I think Ole wrote this text in the initial version of the draft, so perhaps he can clarify; but it may also have been tweaked along the way.) Perhaps to relate this better to the RFC 3315 definition of 'binding' we instead use: Identity association (IA): A collection of stateful options assigned to a client. Each IA has an IA-type and associated IAID. A client may have more than one IA assigned to it; for example, one for each of its interfaces. Each IA holds one type of stateful options; for example, an identity association for temporary addresses (IA_TA) holds temporary addresses (see "identity association for temporary addresses"). Throughout this document, "IA" is used to refer to an identity association without identifying the type of stateful option in the IA. >BV> ORO are not used for IA_NA/IA_PD/IA_TA. > >Not 100% sure about this point. I can't find the referenced text in RFC3315 yet. I'm not sure that text is there, but neither is there text to say to add it. (Our server ignores IA_NA, IA_PD, IA_TA in the ORO if it is there because there is EXPLICIT processing for this already in RFC 3315/3633 so there is no need to do anything based on the ORO for these options. Some clients do add it.) Note that there is no text that the ORO should include the Server-ID option; a server is REQUIRED to add this always. The requirement for adding options into the ORO is really for those options that have no explicit processing (such as the DNS resolver address). - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Leaf Yeh Sent: Monday, February 18, 2013 11:58 AM To: Bernie Volz (volz) Cc: 'dhc WG' Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 E2. Editorial - Page 3 - Section 3 < snip >Each IA holds one type of IA option; for example, ... LY> Does it mean IA_NA and IA-PD will never share the same IA? I guess LY> the better text could be 'Each IA option holds one type, for example,... ' BV> I am not sure what you are asking here. An instance of an IA is a BV> IA_NA or IA_PD. IA is short for Identity Association. Note that this just updates RFC 3315's definition which was address based. IA(Identity Association) is specified by IAID, which sounds associated with the client's interface. My question is whether a IA-NA and a IA_PD could have the same IAID? If yes, my text might be better. T1. Page 7 - Section 4.4 The client also includes an IA option for each binding it desires but has been unable to obtain. LY> Could the above text be replaced by the original text in RFC3315? 'The client MUST include an Option Request option (see section 22.7) to indicate the options the client is interested in receiving. The client MAY include options with data values as hints to the server about parameter values the client would like to have returned.' BV> ORO are not used for IA_NA/IA_PD/IA_TA. Not 100% sure about this point. I can't find the referenced text in RFC3315 yet. BV> As the client must assign an IAID so it must send the IA_* option. The might mean that IA_xx should also be included after ORO. I meant the original text in RFC3315 might cover the case of the above new suggested text in the new draft. Best Regards, Leaf -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Tuesday, February 19, 2013 12:10 AM To: Leaf Yeh Cc: 'dhc WG' Subject: RE: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 Hi: Thanks for the thorough review. Some comments below (BV>). - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Leaf Yeh Sent: Monday, February 18, 2013 2:33 AM To: Bernie Volz (volz) Cc: 'dhc WG' Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 E1. Editorial - How about change the title of the draft to be 'Updates of RFC 3315 and RFC3633 with multiple stateful options'? BV> While we could change the title, I don't really see this as that critical. The updates could be summarized as follows: a. Client should keep a single session with the multiple stateful options (in subsequent messages, Request, Renew, and Rebind, to the server.) b. Ideally the Status Code option should be encapsulated in the IA option for all DHCP messages. This makes Advertisement messages equal to Reply messages. (A new recommendation to the server though there is a issue for backwards compatibility) c. The server SHOULD set the T1/T2 timers in all IA options in Reply and Advertise messages to the same value. (A new recommendation to the server) d. makes the server's IA processing of Renew and Rebind similar to the Request processing (but ORO sounds also make it). e. Allow the Confirm message work for DHCPv6-PD. Right? BV> Yes, except for D and ORO. (See below.) E2. Editorial - Page 3 - Section 3 < snip >Each IA holds one type of IA option; for example, ... Does it mean IA_NA and IA-PD will never share the same IA? I guess the better text could be 'Each IA option holds one type, for example,... ' BV> I am not sure what you are asking here. An instance of an IA is a BV> IA_NA or IA_PD. IA is short for Identity Association. Note that this just updates RFC 3315's definition which was address based. T1. Page 7 - Section 4.4 The client also includes an IA option for each binding it desires but has been unable to obtain. Could the above text be replaced by the original text in RFC3315? 'The client MUST include an Option Request option (see section 22.7) to indicate the options the client is interested in receiving. The client MAY include options with data values as hints to the server about parameter values the client would like to have returned.' BV> ORO are not used for IA_NA/IA_PD/IA_TA. As the client must assign an IAID so it must send the IA_* option. T2. Technical - Page 7- Section 4.4 If the server cannot find a client entry for the IA the server creates the bindings for that client according to the server's policy and configuration information and records the IAs and other information requested by the client. Not sure the above sounds a necessary behavior of the server. What is the issue if the server doesn't create the bindings for that client when the server cannot find a client entry for the IA? BV> Interesting point and the text should probably be revised to allow BV> the older behavior as servers might not be updated. E3. Editorial - Page 7 - Section 4.4 However, it MUST limit the frequency at which is does this to no more often than the renewal frequency. I guess the right text sounds '...at which it does this to... '. BV> Yes. This should be it, not is. E4. Editorial - Page 8 - Section 4.5 If such verification is needed the requesting router MUST initiate a Confirm message exchange as described in section 18.1.2, "Creation and Transmission of Confirm Messages" of RFC 3315. The above text sounds '...MUST initiate a Confirm/Reply message exchange...'. BV> Yes. To we should add /Reply. E5. Editorial - Saw many 'should's have not been in the format of 'SHOULD' yet. BV> There may be a few that could be changed to SHOULD. In general, only BV> the proposed solution and changes would have these capitalized per RFC 2119. I think there are only 2 to consider for should -> SHOULD - in 4. and 4.4. in proposed solution text. For must -> MUST, 4.6. There are a few grey areas that may also switch the case ... I think for the discuss text we may want to lower case. I'll discuss this with Ole and see what we do for a revised draft. If someone has a strong opinion one way or the other, please let us know. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Tuesday, January 22, 2013 7:25 AM To: Bud Millwood Cc: dhc WG; Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >The original text says to return an IA_* with no addr/prefix and a >status code "NoBinding". Now, if we cannot fulfill the binding, we do the same thing, but we don't include a status code. Is that right? Hum ... perhaps it is best to follow the Request and return NoAddrsAvail status in the IA_* option (of course we'd need to update RFC 3633 text then as well to return NoPrefixAvail). The choices now seem to be: 1. Just return the IA_* option (empty). 2. Return IA_* option with NoAddrsAvail (or NoPrefixAvail) -- following Request logic. 3. Return IA_* option with NoBinding -- following existing Renew logic for unknown bindings. 4. Don't return the IA_* option (I think this is not a good choice and believe you don't either). Perhaps new #2 is the best as it matches the Request ... Renew and Request are really very similar anyway - the main differences were: - We are telling the server the client is renewing (thus is using the leases) - No new bindings were 'allowed' -- this is now not true and what we are proposing to change. We could do the same for the Rebind. BTW: The case for a Rebind where the server can't find the client entry for the IA is not covered in RFC 3315 (it is if the addresses are no longer appropriate, but not otherwise). In some ways, this missing text leaves it up to the server (which for some cases, may be good - for example, Failover may trust the client and if there is no conflict, the server may want to respond -- that is what we do in V4). In other instances, the server might want to drop the Rebind or respond with NoBindings to force client back to Solicit? Also, the Rebind is missing the text that allows the server to change the addresses as appears in Renew. Opinions? - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bud Millwood Sent: Monday, January 21, 2013 5:52 PM To: Bernie Volz (volz) Cc: dhc WG; Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 > Regarding 4.2, how is that? It always means no addresses available but > may mean prefixes available. Yes of course; I should have reviewed 3633. > Regarding 4.4, I would expect the server to return the IA_* option but without any IAADDR/IAPREFIX options. (The server would not really create a record of this binding since it has no leases.) Perhaps the text should be clarified regarding this. The original text says to return an IA_* with no addr/prefix and a status code "NoBinding". Now, if we cannot fulfill the binding, we do the same thing, but we don't include a status code. Is that right? > Note that perhaps a question exists as to which behavior to document > for the Reply in this case: > 1. Return the IA_* option, empty. > 2. Do not return the IA_* option. > Either approach would work. 1 may provide more information to the > client (but client implementers may prefer 2) -- it is also sending back what the client sent (since it had no IAADDR/IAPREFIXes to include). (1) makes more sense to me because the server is explicitly acknowledging the IA_*. - Bud > Regarding 4.5, ok one of those edits can be done in a -04 (after 28th > when WGLC ends). Usually the RFC-Editor also catches things like this, but best to give them a better document to start with. > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Bud Millwood > Sent: Monday, January 21, 2013 10:28 AM > To: Gaurav Halwasia (ghalwasi) > Cc: dhc WG; Bernie Volz (volz); Ted Lemon > Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 > > 4.2: Proposed solution: No change. For backwards compatibility, the > NoAddrsAvail Status Code option when no addresses are available will > be kept in the global scope for Advertise messages. > > Question: Does it need to be further clarified that in Advertise, "NoAddrsAvail" now may mean "SomeAddrsAvail"? > > 4.4: Note that clients that communicate with servers that do not support > this updated Renew processing will receive the NoBinding status for > the IA which had no bindings. > > Question: isn't this also a valid response if the server does support updated Renew processing, but cannot fulfill the binding for the IA? > > 4.5: It lets a server without a binding to reply to > the message, under the assumption that the server only needs > knowledge about the prefix(es) on the link, to inform the client that > the address is likely valid or not. > > - Change "lets" to "enables" or "allows", alt. remove "to" between "binding" and "reply". > > - Bud > > > On Wed, Jan 16, 2013 at 5:43 AM, Gaurav Halwasia (ghalwasi) wrote: >> Thanks for taking care of comments. I agree with you point regarding point (3). >> >> -Gaurav >> >> -----Original Message----- >> From: Bernie Volz (volz) >> Sent: Wednesday, January 16, 2013 2:38 AM >> To: Gaurav Halwasia (ghalwasi); Ted Lemon; dhc WG >> Subject: RE: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >> >> Hi: >> >> Thanks for the comments, I've made some comments below (BV>). >> >> Let's wait until the 28th before I draft the -04 version. Hopefully >> there will be more comments! >> >> - Bernie >> >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On >> Behalf Of Gaurav Halwasia (ghalwasi) >> Sent: Monday, January 14, 2013 10:47 PM >> To: Ted Lemon; dhc WG >> Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >> >> I read/reviewed this document and I support this document to move forward. >> >> I do have some comments and it would be good if authors can consider them. Even otherwise I support this document. >> >> 1.) In Abstract :- >> >> "Implementation experience of the CPE model >> described in has shown multiple issues" >> I think you wanted to specify RFC6204 after "described in" >> >> BV> Yes. >> >> 2.) Section 4.2 Placement of Status codes. >> In Reply messages IA specific status codes (NoAddrsAvail, NotOnlink, >> NoBinding) are encapsulated in the IA option. >> I think we should include "NoPrefixAvail" as well in the above line. >> I see no reason why it should not be. >> >> BV> Yes. Might be best to use (i.e.) too so that it is clear that >> BV> this is just a partial list. >> >> 3.) For Confirm message. As I understand, we are now allowing CONFIRM >> message for IA_PD. I think we should update the definition of CONFIRM >> message in RFC3315 which currently only talks about *address* >> >> >> CONFIRM (4) A client sends a Confirm message to any >> available server to determine whether the >> addresses it was assigned are still appropriate >> to the link to which the client is connected. >> >> >> BV> Well this is a bit tricky as RFC 3315 knows nothing of prefix allocation. A RFC 3315bis would definitely want to reword it as such (as I would expect it to combine 3315 and 3633). This really falls into the changes to RFC 3633 that it would extend Confirm to include prefixes. We tried (I hope) to keep the RFC 3315 changes consistent with what RFC 3315 contained and PD changes to RFC 3633. There might be more we could add to RFC 3633, but do we really think that is necessary? I guess we could replace "addresses" with something more generic ("configuration information explicitly assigned to the client", which comes from the definition of binding in RFC 3315), but I think that doesn't really improve anything. >> >> BV> Thus, I will not make this change. >> >> >> Thanks, >> Gaurav >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On >> Behalf Of Ted Lemon >> Sent: Tuesday, January 15, 2013 1:04 AM >> To: dhc WG >> Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >> >> On Jan 14, 2013, at 2:15 PM, Bernie Volz (volz) wrote: >>> A 2nd Query regarding this as I heard nothing since the first. >> >> Oops, sorry about that, Bernie. >> >> Folks, the authors of this draft feel it's ready for a WGLC. There's been substantial discussion and comment already. This is pretty important IPv6 deployment work, so more eyes are better. Please review the draft and indicate whether or not you feel it is ready to be published. We have been getting very anemic responses to working group messages recently. Your response matters, so please do respond. >> >> We will evaluate consensus after January 28. Thanks! >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From msiodelski@gmail.com Tue Feb 19 09:44:38 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE19C21F8E65 for ; Tue, 19 Feb 2013 09:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJZlVPjAxxfC for ; Tue, 19 Feb 2013 09:44:38 -0800 (PST) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id DFDD721F8E3D for ; Tue, 19 Feb 2013 09:44:37 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id er20so6887039lab.32 for ; Tue, 19 Feb 2013 09:44:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=z24s8C0DLguMj5WtmmhUYGEuP0s2Va2/9IheAdvWKUA=; b=trykzYYEoSWNGtS/lfi7abw1uaq+qG6c3hPSKr5tp9EXCuJaQHKv5gH/nbCrKhcfel Vil4qCCdW4j9Ssoy4i1d8LNQ/HQPLcRwlQTyP9pKF/iGyjZrPPtnQbG1dKWGEPVKvay6 PFsBH7z0j8YMG5Cj2GF9jYyH42NQ1ndiJ5nsWBfI+fpe/wEWrQZ8xVdYju76ZLp9ugHY z7jgqoHIs8pHlbgtWWRndW+jmPAS6Y6pMm46mO4ZS1f1BSDx8FydzkYqVXay0zQCCPMs gdDwNeB/ETl3YEe4mGGHsKgUItRTe6hL8M3uTNoN1gewxAWXlh4cemb2Ft0v6D0pTtUm xCOg== MIME-Version: 1.0 X-Received: by 10.152.147.130 with SMTP id tk2mr15067488lab.24.1361295876626; Tue, 19 Feb 2013 09:44:36 -0800 (PST) Received: by 10.112.71.140 with HTTP; Tue, 19 Feb 2013 09:44:36 -0800 (PST) Date: Tue, 19 Feb 2013 18:44:36 +0100 Message-ID: From: Marcin Siodelski To: dhcwg@ietf.org Content-Type: multipart/alternative; boundary=e89a8f22beb929185704d617652a Cc: wdec@cisco.com Subject: [dhcwg] Comments regarding draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04 X-BeenThere: dhcwg@ietf.org 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, 19 Feb 2013 17:44:39 -0000 --e89a8f22beb929185704d617652a Content-Type: text/plain; charset=ISO-8859-1 Hello, I have just read the draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04 and I have a few comments to share.... 1. It is easy to deduce that there can be just a single instance of the option carrying the link-layer address in a particular message. However, I think it should be explicitly mentioned for the clarity of the document. Note that the standards don't prohibit sending multiple instances of the option with the certain code. Also, some of the options may be included only once. 2. I suggest that it is mentioned what a server is supposed to do if it finds two instances of the option in the single DHCP message. ignore the options? Ignore the whole message? It is specifically important when multiple options carry different link-layer addresses. 3. It is said that the Relay Agent MAY add the link-layer option to the message, but it is NOT said what happens if a client sends this option. Again, is this ignored by the Relay Agent OR the Server? 4. I suggest that it is explicitly mentioned that the new option does not replace the DUID in any sense but it rather carries the supplementary information - the client-id requirements from the RFC3315 still apply. 5. Minor: there is the inconsitency with respect to the name of the option. In section 3: it is "Client Link-layer Address", in the header of the page it is "Client Link-layer address", in section 5 it is "client link-layer address", in section 7 it is "Client Link Layer Address". Cheers, Marcin --e89a8f22beb929185704d617652a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,=A0

I have just read the draft-ietf-dhc-dhcpv6-cli= ent-link-layer-addr-opt-04 and I have a few comments to share....

1. It is easy to deduce that there can be just a single ins= tance of the option carrying the link-layer address in a particular message= . However, I think it should be explicitly mentioned for the clarity of the= document. Note that the standards don't prohibit sending multiple inst= ances of the option with the certain code. Also, some of the options may be= included only once.

2. I suggest that it is mentioned what a server is supp= osed to do if it finds two instances of the option in the single DHCP messa= ge. ignore the options? Ignore the whole message? It is specifically import= ant when multiple options carry different link-layer addresses.

3. It is said that the Relay Agent MAY add the link-lay= er option to the message, but it is NOT said what happens if a client sends= this option. Again, is this ignored by the Relay Agent OR the Server?

4. I suggest that it is explicitly mentioned that the n= ew option does not replace the DUID in any sense but it rather carries the = supplementary information - the client-id requirements from the RFC3315 sti= ll apply.

5. Minor: there is the inconsitency with respect to the= name of the option. In section 3: it is "Client Link-layer Address&qu= ot;, in the header of the page it is "Client Link-layer address",= in section 5 it is "client link-layer address", in section 7 it = is "Client Link Layer Address".

Cheers,
Marcin
--e89a8f22beb929185704d617652a-- From leaf.yeh.sdo@gmail.com Tue Feb 19 17:40:18 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF1021F8818 for ; Tue, 19 Feb 2013 17:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.893 X-Spam-Level: X-Spam-Status: No, score=-2.893 tagged_above=-999 required=5 tests=[AWL=0.706, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYfpsAtLzL2P for ; Tue, 19 Feb 2013 17:40:13 -0800 (PST) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by ietfa.amsl.com (Postfix) with ESMTP id 6D10821F882A for ; Tue, 19 Feb 2013 17:40:13 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id bj3so3689283pad.20 for ; Tue, 19 Feb 2013 17:40:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=nsBKkqXwqQLjcYFqsh3zQMH2mJ/OipoVxUyWUpmfShA=; b=YYp2cQ4ckJALed7hm3bIsrb3zW8b7G08DN69qaAZF3+f+xjMjQ9o83QX5W8aIq+8nk 3zR4+wcdwdvSqEr70/BdhFOR6sICJ75BTKpyqVHtYapGrzZKrN5kzdSJUhKmCvEltt7v BYDus+LuGxZnas3urYrDRGSE5+vJI5IcIUNmeGysLfCgUdDl3SprXAyiekTwAfM3Ir0N jCl9UT8aUEYZBXXx6WKc8vlDZzPdanqQERLzVI0GSVcb1DxmoIiKGQPtcRxf3DzP+VjZ DzH0M3qqiSAUdcSDe2WcmeIarP3Dp2OZqTaGpZuv0TcEuilzL4UfDyoFn/T7rUzBGJC2 aZsw== X-Received: by 10.68.189.103 with SMTP id gh7mr46387071pbc.92.1361324408487; Tue, 19 Feb 2013 17:40:08 -0800 (PST) Received: from PC ([218.18.197.160]) by mx.google.com with ESMTPS id hs8sm19747611pbc.27.2013.02.19.17.40.04 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 19 Feb 2013 17:40:07 -0800 (PST) From: "Leaf Yeh" To: "'Bernie Volz \(volz\)'" References: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> <90903C21C73202418A48BFBE80AEE5EB22DEB892@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843CA16@xmb-rcd-x04.cisco.com> <90903C21C73202418A48BFBE80AEE5EB22DEDE19@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E18442EC0@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E184431CF@xmb-rcd-x04.cisco.com> <5121d93d.294e420a.5385.55cd@mx.google.com> <489D13FBFA9B3E41812EA89F188F018E1847039E@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1847039E@xmb-rcd-x04.cisco.com> Date: Wed, 20 Feb 2013 09:40:00 +0800 Message-ID: <51242977.08c2440a.0f10.7106@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac34Pu9LhlVR97tQwEWdQEw5vWHbDQVB/gtgACr11EAAA2H+wA== Content-Language: zh-cn Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-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, 20 Feb 2013 01:40:18 -0000 BV> I think we should make Renew and Rebind the same here Agreed. BV> If NoBinding, return to Solicit. I guess this 'Nobinding' sounds in the "global" scope of the message. BV> If NoAddrsAvail/NoPrefixAvail, continue to Renew/Rebind with the existing leases (at T1/T2 times). If no leases, return to Solicit. I guess the above 'lease' is associated with the IA, 'A collection of stateful options(IA_xx) assigned to a client('s interface)'. Right? Best Regards, Leaf -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Tuesday, February 19, 2013 12:28 AM To: Leaf Yeh Cc: dhcwg@ietf.org Subject: RE: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 Hi again: #1 and #2 are probably 'equal'. The REBIND case is an interesting one and while #2 and #3 are probably close to the same result in terms of the client's behavior, I wonder what existing servers do -- I would guess that they are more likely to return #3 (matching Renew) if they aren't willing to 'create' the binding? The subtle difference between #2 and #3 may be: - #2 means that the server would be willing to assign the binding a lease if it had a lease to give. - #3 means that the server would not be willing to assign the binding a lease because it has no record of the binding and would not create one. For #2, the message is clear that the client can continue to try. Whereas for #3, it may be that the client needs to return to Solicit if it ever hopes to get the binding. I think that may be the key to this ... NoBinding means that the server will not assign a new binding except via Solicit/... whereas NoAddrsAvail/NoPrefixAvail means that the server has nothing to give the client but would otherwise accept the binding. I think we should make Renew and Rebind the same here (i.e. return #2 and #3 depending on the situation). What the client does with this information is likely: - If NoBinding, return to Solicit. - If NoAddrsAvail/NoPrefixAvail, continue to Renew/Rebind with the existing leases (at T1/T2 times). If no leases, return to Solicit. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Leaf Yeh Sent: Monday, February 18, 2013 2:33 AM To: Bernie Volz (volz) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 Bernie - > The choices now seem to be: > 1. Just return the IA_* option (empty). > 2. Return IA_* option with NoAddrsAvail (or NoPrefixAvail) -- > following Request logic. > 3. Return IA_* option with NoBinding -- following existing Renew logic > for unknown bindings. > 4. Don't return the IA_* option (I think this is not a good choice and believe you don't either). >Perhaps new #2 is the best as it matches the Request ... Renew and >Request are really very similar anyway #2 & # 3 sounds roughly the same to me. Could the client directly interpret the 'NoBinding' to be 'NoAddrsAvail (or NoPrefixAvail)' here? Bernie - BTW: The case for a Rebind where the server can't find the client entry for the IA is not covered in RFC 3315 (it is if the addresses are no longer appropriate, but not otherwise). In some ways, this missing text leaves it up to the server (which for some cases, may be good - for example, Failover may trust the client and if there is no conflict, the server may want to respond -- that is what we do in V4). In other instances, the server might want to drop the Rebind or respond with NoBindings to force client back to Solicit? Also, the Rebind is missing the text that allows the server to change the addresses as appears in Renew. Do we need more text on REBIND here? Sounds like the same behavior as the RENEW at server side: (referring to section 18.2.3 of RFC3315) a. If the server cannot find a client entry for the IA, the server returns the IA containing with a Status Code option set to NoBinding in the Reply message. b. The server may choose to change the list of addresses/prefixes and their lifetimes in IAs that are returned to the client. (I think we'd mention IA_PD in the updates of RFC3315) Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bud Millwood Sent: Tuesday, January 22, 2013 9:22 AM To: Bernie Volz (volz) Cc: dhc WG; Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 On Tue, Jan 22, 2013 at 12:24 AM, Bernie Volz (volz) wrote: >>The original text says to return an IA_* with no addr/prefix and a >>status code "NoBinding". Now, if we cannot fulfill the binding, we do the same thing, but we don't include a status code. Is that right? > > Hum ... perhaps it is best to follow the Request and return > NoAddrsAvail status in the IA_* option (of course we'd need to update RFC 3633 text then as well to return NoPrefixAvail). > > The choices now seem to be: > 1. Just return the IA_* option (empty). > 2. Return IA_* option with NoAddrsAvail (or NoPrefixAvail) -- > following Request logic. > 3. Return IA_* option with NoBinding -- following existing Renew logic > for unknown bindings. > 4. Don't return the IA_* option (I think this is not a good choice and believe you don't either). > > Perhaps new #2 is the best as it matches the Request ... Renew and > Request are really very similar anyway - the main differences were: > - We are telling the server the client is renewing (thus is using the > leases) > - No new bindings were 'allowed' -- this is now not true and what we > are proposing to change. I think #2 is best approach. Since we can now create bindings in Renew, and a client should be prepared to obtain a new lease at this time, it's basically the same thing as Request from the standpoint of the protocol. And judging by the names of the error codes, NoAddrsAvail and NoPrefixAvail seem better because they reflect the server's inability to create a binding. "NoBinding" seems more like "No info, can't proceed" (which is more suited the previous behavior). > We could do the same for the Rebind. I suppose my argument in favor of this is the same as above. If the client must be prepared to accept a new lease at this time, it's like a "deferred Request". > BTW: The case for a Rebind where the server can't find the client > entry for the IA is not covered in RFC 3315 (it is if the addresses are no longer appropriate, but not otherwise). In some ways, this missing text leaves it up to the server (which for some cases, may be good - for example, Failover may trust the client and if there is no conflict, the server may want to respond -- that is what we do in V4). In other instances, the server might want to drop the Rebind or respond with NoBindings to force client back to Solicit? Also, the Rebind is missing the text that allows the server to change the addresses as appears in Renew. Maybe it's important to distinguish between not being able to create a new binding for a non-existent lease (NoAddrsAvail/NoPrefixAvail) and not being able to create a new binding for an existing lease? (Or for that matter, for the latter, not being able to rebind the addr/prefix in question due to lack of information). - Bud > > Opinions? > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Bud Millwood > Sent: Monday, January 21, 2013 5:52 PM > To: Bernie Volz (volz) > Cc: dhc WG; Ted Lemon > Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 > >> Regarding 4.2, how is that? It always means no addresses available >> but may mean prefixes available. > > Yes of course; I should have reviewed 3633. > >> Regarding 4.4, I would expect the server to return the IA_* option >> but without any IAADDR/IAPREFIX options. (The server would not really create a record of this binding since it has no leases.) Perhaps the text should be clarified regarding this. > > The original text says to return an IA_* with no addr/prefix and a > status code "NoBinding". Now, if we cannot fulfill the binding, we do the same thing, but we don't include a status code. Is that right? > >> Note that perhaps a question exists as to which behavior to document >> for the Reply in this case: >> 1. Return the IA_* option, empty. >> 2. Do not return the IA_* option. >> Either approach would work. 1 may provide more information to the >> client (but client implementers may prefer 2) -- it is also sending back what the client sent (since it had no IAADDR/IAPREFIXes to include). > > (1) makes more sense to me because the server is explicitly > acknowledging the IA_*. > > - Bud > >> Regarding 4.5, ok one of those edits can be done in a -04 (after 28th when WGLC ends). Usually the RFC-Editor also catches things like this, but best to give them a better document to start with. >> >> - Bernie >> >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On >> Behalf Of Bud Millwood >> Sent: Monday, January 21, 2013 10:28 AM >> To: Gaurav Halwasia (ghalwasi) >> Cc: dhc WG; Bernie Volz (volz); Ted Lemon >> Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >> >> 4.2: Proposed solution: No change. For backwards compatibility, the >> NoAddrsAvail Status Code option when no addresses are available will >> be kept in the global scope for Advertise messages. >> >> Question: Does it need to be further clarified that in Advertise, "NoAddrsAvail" now may mean "SomeAddrsAvail"? >> >> 4.4: Note that clients that communicate with servers that do not support >> this updated Renew processing will receive the NoBinding status for >> the IA which had no bindings. >> >> Question: isn't this also a valid response if the server does support updated Renew processing, but cannot fulfill the binding for the IA? >> >> 4.5: It lets a server without a binding to reply to >> the message, under the assumption that the server only needs >> knowledge about the prefix(es) on the link, to inform the client that >> the address is likely valid or not. >> >> - Change "lets" to "enables" or "allows", alt. remove "to" between "binding" and "reply". >> >> - Bud >> >> >> On Wed, Jan 16, 2013 at 5:43 AM, Gaurav Halwasia (ghalwasi) wrote: >>> Thanks for taking care of comments. I agree with you point regarding point (3). >>> >>> -Gaurav >>> >>> -----Original Message----- >>> From: Bernie Volz (volz) >>> Sent: Wednesday, January 16, 2013 2:38 AM >>> To: Gaurav Halwasia (ghalwasi); Ted Lemon; dhc WG >>> Subject: RE: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >>> >>> Hi: >>> >>> Thanks for the comments, I've made some comments below (BV>). >>> >>> Let's wait until the 28th before I draft the -04 version. Hopefully there will be more comments! >>> >>> - Bernie >>> >>> -----Original Message----- >>> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On >>> Behalf Of Gaurav Halwasia (ghalwasi) >>> Sent: Monday, January 14, 2013 10:47 PM >>> To: Ted Lemon; dhc WG >>> Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >>> >>> I read/reviewed this document and I support this document to move forward. >>> >>> I do have some comments and it would be good if authors can consider them. Even otherwise I support this document. >>> >>> 1.) In Abstract :- >>> >>> "Implementation experience of the CPE model >>> described in has shown multiple issues" >>> I think you wanted to specify RFC6204 after "described in" >>> >>> BV> Yes. >>> >>> 2.) Section 4.2 Placement of Status codes. >>> In Reply messages IA specific status codes (NoAddrsAvail, NotOnlink, >>> NoBinding) are encapsulated in the IA option. >>> I think we should include "NoPrefixAvail" as well in the above line. >>> I see no reason why it should not be. >>> >>> BV> Yes. Might be best to use (i.e.) too so that it is clear that >>> BV> this is just a partial list. >>> >>> 3.) For Confirm message. As I understand, we are now allowing >>> CONFIRM message for IA_PD. I think we should update the definition >>> of CONFIRM message in RFC3315 which currently only talks about >>> *address* >>> >>> >>> CONFIRM (4) A client sends a Confirm message to any >>> available server to determine whether the >>> addresses it was assigned are still appropriate >>> to the link to which the client is connected. >>> >>> >>> BV> Well this is a bit tricky as RFC 3315 knows nothing of prefix allocation. A RFC 3315bis would definitely want to reword it as such (as I would expect it to combine 3315 and 3633). This really falls into the changes to RFC 3633 that it would extend Confirm to include prefixes. We tried (I hope) to keep the RFC 3315 changes consistent with what RFC 3315 contained and PD changes to RFC 3633. There might be more we could add to RFC 3633, but do we really think that is necessary? I guess we could replace "addresses" with something more generic ("configuration information explicitly assigned to the client", which comes from the definition of binding in RFC 3315), but I think that doesn't really improve anything. >>> >>> BV> Thus, I will not make this change. >>> >>> >>> Thanks, >>> Gaurav >>> -----Original Message----- >>> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On >>> Behalf Of Ted Lemon >>> Sent: Tuesday, January 15, 2013 1:04 AM >>> To: dhc WG >>> Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >>> >>> On Jan 14, 2013, at 2:15 PM, Bernie Volz (volz) wrote: >>>> A 2nd Query regarding this as I heard nothing since the first. >>> >>> Oops, sorry about that, Bernie. >>> >>> Folks, the authors of this draft feel it's ready for a WGLC. There's been substantial discussion and comment already. This is pretty important IPv6 deployment work, so more eyes are better. Please review the draft and indicate whether or not you feel it is ready to be published. We have been getting very anemic responses to working group messages recently. Your response matters, so please do respond. >>> >>> We will evaluate consensus after January 28. Thanks! >>> >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Tue Feb 19 18:51:52 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79AA821F8806 for ; Tue, 19 Feb 2013 18:51:52 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLCl4A9spSDc for ; Tue, 19 Feb 2013 18:51:50 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3955F21F87FF for ; Tue, 19 Feb 2013 18:51:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12707; q=dns/txt; s=iport; t=1361328710; x=1362538310; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EGymcAREIaKjwMe3ZIfCjCLtvhOlSQ5ZYzR1jyAfX44=; b=dWixWWoNqeNhVR+dr8eXqcIVUtlyWitPCwAOBsXRbsAWO3mQiCIZb6Se MRFE6hzmO793p7K3HFE0VKfWHGoiVFyIlF8WWgd2LKtpLH6nMpSsl55WJ Bh2H7LgJuuZM5S4vut37Retub+ZsXiDyZKwqqZnPAEmNE/F88JrSEJMaX w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJU4JFGtJV2Z/2dsb2JhbABFgkO+C4ELFnOCHwEBAQQtOhIQAgEIDgMEAQELHQcyFAkIAgQBDQUIiAqyUY4Kjl0mCwYBBoJZYQOnA4FSgSgNgic X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; d="scan'208,217";a="175983814" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 20 Feb 2013 02:51:49 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1K2pnMF028178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Feb 2013 02:51:49 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 20:51:49 -0600 From: "Bernie Volz (volz)" To: Marcin Siodelski , "dhcwg@ietf.org" Thread-Topic: [dhcwg] Comments regarding draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04 Thread-Index: AQHODsjOwN6TMsiTs0uOOlJEBh7uD5iCC0fA Date: Wed, 20 Feb 2013 02:51:48 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E18472DFE@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.184] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E18472DFExmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "Wojciech Dec \(wdec\)" Subject: Re: [dhcwg] Comments regarding draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04 X-BeenThere: dhcwg@ietf.org 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, 20 Feb 2013 02:51:52 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E18472DFExmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (WG co-chair hat off - not that it has yet really been put on anyway.) Regarding #1 and #2, while perhaps best to clarify that there is only one (= in the Relay-Forw closest to the client), I think these really are not 'req= uire' to be addressed. We generally assume that only one is present when it= is pretty clear that is all that makes sense and the server would use only= the first (I doubt most servers would care to check for a second because t= here is no reason to do so - yes, a server that processes the options seque= ntially might save just the last but that isn't a major issue and for vario= us reasons I doubt any server processes options this way). For #3, if a client adds this, it will be in the client's message and not i= n Relay-Forw so it will be ignored by the server (and other relays). - Bernie From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of M= arcin Siodelski Sent: Tuesday, February 19, 2013 12:45 PM To: dhcwg@ietf.org Cc: Wojciech Dec (wdec) Subject: [dhcwg] Comments regarding draft-ietf-dhc-dhcpv6-client-link-layer= -addr-opt-04 Hello, I have just read the draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04 an= d I have a few comments to share.... 1. It is easy to deduce that there can be just a single instance of the opt= ion carrying the link-layer address in a particular message. However, I thi= nk it should be explicitly mentioned for the clarity of the document. Note = that the standards don't prohibit sending multiple instances of the option = with the certain code. Also, some of the options may be included only once. 2. I suggest that it is mentioned what a server is supposed to do if it fin= ds two instances of the option in the single DHCP message. ignore the optio= ns? Ignore the whole message? It is specifically important when multiple op= tions carry different link-layer addresses. 3. It is said that the Relay Agent MAY add the link-layer option to the mes= sage, but it is NOT said what happens if a client sends this option. Again,= is this ignored by the Relay Agent OR the Server? 4. I suggest that it is explicitly mentioned that the new option does not r= eplace the DUID in any sense but it rather carries the supplementary inform= ation - the client-id requirements from the RFC3315 still apply. 5. Minor: there is the inconsitency with respect to the name of the option.= In section 3: it is "Client Link-layer Address", in the header of the page= it is "Client Link-layer address", in section 5 it is "client link-layer a= ddress", in section 7 it is "Client Link Layer Address". Cheers, Marcin --_000_489D13FBFA9B3E41812EA89F188F018E18472DFExmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(WG co-chair hat off R= 11; not that it has yet really been put on anyway.)

 <= /p>

Regarding #1 and #2, whil= e perhaps best to clarify that there is only one (in the Relay-Forw closest= to the client), I think these really are not ‘require’ to be addressed. We generally assume that only one is present when it is p= retty clear that is all that makes sense and the server would use only the = first (I doubt most servers would care to check for a second because there = is no reason to do so – yes, a server that processes the options sequentially might save just the last but that = isn’t a major issue and for various reasons I doubt any server proces= ses options this way).

 <= /p>

For #3, if a client adds = this, it will be in the client’s message and not in Relay-Forw so it = will be ignored by the server (and other relays).

 <= /p>

- =          Bernie=

 <= /p>

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Marcin Siodelski
Sent: Tuesday, February 19, 2013 12:45 PM
To: dhcwg@ietf.org
Cc: Wojciech Dec (wdec)
Subject: [dhcwg] Comments regarding draft-ietf-dhc-dhcpv6-client-lin= k-layer-addr-opt-04

 

Hello, 

 

I have just read the draft-ietf-dhc-dhcpv6-client-li= nk-layer-addr-opt-04 and I have a few comments to share....

 

1. It is easy to deduce that there can be just a sin= gle instance of the option carrying the link-layer address in a particular = message. However, I think it should be explicitly mentioned for the clarity= of the document. Note that the standards don't prohibit sending multiple instances of the option with the certain c= ode. Also, some of the options may be included only once.

 

2. I suggest that it is mentioned what a server is s= upposed to do if it finds two instances of the option in the single DHCP me= ssage. ignore the options? Ignore the whole message? It is specifically imp= ortant when multiple options carry different link-layer addresses.

 

3. It is said that the Relay Agent MAY add the link-= layer option to the message, but it is NOT said what happens if a client se= nds this option. Again, is this ignored by the Relay Agent OR the Server?

 

4. I suggest that it is explicitly mentioned that th= e new option does not replace the DUID in any sense but it rather carries t= he supplementary information - the client-id requirements from the RFC3315 = still apply.

 

5. Minor: there is the inconsitency with respect to = the name of the option. In section 3: it is "Client Link-layer Address= ", in the header of the page it is "Client Link-layer address&quo= t;, in section 5 it is "client link-layer address", in section 7 it is "Client Link Layer Address".

 

Cheers,

Marcin

--_000_489D13FBFA9B3E41812EA89F188F018E18472DFExmbrcdx04ciscoc_-- From ghalwasi@cisco.com Tue Feb 19 20:24:50 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F85821F886B for ; Tue, 19 Feb 2013 20:24:50 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BVIB7tm9btc for ; Tue, 19 Feb 2013 20:24:47 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 967B021F86D5 for ; Tue, 19 Feb 2013 20:24:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16950; q=dns/txt; s=iport; t=1361334287; x=1362543887; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=z3ZFxDzaS8ltD2jL6y15ZUR1n6ZriRpXBeeJrWpwJzc=; b=fEmCMe7737ggU7Jp/yN9zrXsgAlzEMIKCZcicsna321KQDKXZNWXfuda 15NCzClAxh5Ff2hvA4pfuznZ2Cm75/QWCznpn7PA9NS3vNs4E5JEKbuSl 0Nf/InTPySafhitaGlA6HWZZrtTRjJsba9s9/N9zitsk2tXa8MjyTWjxz 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAK9OJFGtJV2b/2dsb2JhbABFgkO+DIELFnOCHwEBAQQtOhIQAgEIEQQBAQsdBzIUCQgCBAENBQiICsBcjl0mCwYBBoJZYQOnA4FSgTWCJw X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; d="scan'208,217";a="179005917" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 20 Feb 2013 04:24:46 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1K4OkoT008830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Feb 2013 04:24:46 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.248]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 22:24:45 -0600 From: "Gaurav Halwasia (ghalwasi)" To: "Bernie Volz (volz)" , Marcin Siodelski , "dhcwg@ietf.org" Thread-Topic: [dhcwg] Comments regarding draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04 Thread-Index: AQHODxU/eI0cWtgvOUGnXz3V0OvM/JiCJHMw Date: Wed, 20 Feb 2013 04:24:45 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB22E61BC5@xmb-aln-x06.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E18472DFE@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E18472DFE@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.142.100.114] Content-Type: multipart/alternative; boundary="_000_90903C21C73202418A48BFBE80AEE5EB22E61BC5xmbalnx06ciscoc_" MIME-Version: 1.0 Cc: "Wojciech Dec \(wdec\)" Subject: Re: [dhcwg] Comments regarding draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04 X-BeenThere: dhcwg@ietf.org 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, 20 Feb 2013 04:24:50 -0000 --_000_90903C21C73202418A48BFBE80AEE5EB22E61BC5xmbalnx06ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Marcin for reading the document and commenting. I agree with Bernie. For 4, I think it's pretty much clear in the WG and it's clear from the dis= cussions so far that this document in no way suggesting to replace DUID. I= don't see that this document in any way gives the impression to replace DU= ID. So I think that making it explicit might not be required. For 5, We will take care of it in the next revision or at the time of AUTH4= 8 (whichever is earlier) -Gaurav From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= e rnie Volz (volz) Sent: Wednesday, February 20, 2013 8:22 AM To: Marcin Siodelski; dhcwg@ietf.org Cc: Wojciech Dec (wdec) Subject: Re: [dhcwg] Comments regarding draft-ietf-dhc-dhcpv6-client-link-l= ayer-addr-opt-04 (WG co-chair hat off - not that it has yet really been put on anyway.) Regarding #1 and #2, while perhaps best to clarify that there is only one (= in the Relay-Forw closest to the client), I think these really are not 'req= uire' to be addressed. We generally assume that only one is present when it= is pretty clear that is all that makes sense and the server would use only= the first (I doubt most servers would care to check for a second because t= here is no reason to do so - yes, a server that processes the options seque= ntially might save just the last but that isn't a major issue and for vario= us reasons I doubt any server processes options this way). For #3, if a client adds this, it will be in the client's message and not i= n Relay-Forw so it will be ignored by the server (and other relays). - Bernie From: dhcwg-bounces@ietf.org [mailto:dhcwg-b= ounces@ietf.org] On Behalf Of Marcin Siodelski Sent: Tuesday, February 19, 2013 12:45 PM To: dhcwg@ietf.org Cc: Wojciech Dec (wdec) Subject: [dhcwg] Comments regarding draft-ietf-dhc-dhcpv6-client-link-layer= -addr-opt-04 Hello, I have just read the draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04 an= d I have a few comments to share.... 1. It is easy to deduce that there can be just a single instance of the opt= ion carrying the link-layer address in a particular message. However, I thi= nk it should be explicitly mentioned for the clarity of the document. Note = that the standards don't prohibit sending multiple instances of the option = with the certain code. Also, some of the options may be included only once. 2. I suggest that it is mentioned what a server is supposed to do if it fin= ds two instances of the option in the single DHCP message. ignore the optio= ns? Ignore the whole message? It is specifically important when multiple op= tions carry different link-layer addresses. 3. It is said that the Relay Agent MAY add the link-layer option to the mes= sage, but it is NOT said what happens if a client sends this option. Again,= is this ignored by the Relay Agent OR the Server? 4. I suggest that it is explicitly mentioned that the new option does not r= eplace the DUID in any sense but it rather carries the supplementary inform= ation - the client-id requirements from the RFC3315 still apply. 5. Minor: there is the inconsitency with respect to the name of the option.= In section 3: it is "Client Link-layer Address", in the header of the page= it is "Client Link-layer address", in section 5 it is "client link-layer a= ddress", in section 7 it is "Client Link Layer Address". Cheers, Marcin --_000_90903C21C73202418A48BFBE80AEE5EB22E61BC5xmbalnx06ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Marcin for reading= the document and commenting.

 <= /p>

I agree with Bernie.=

 <= /p>

For 4, I think it’s= pretty much clear in the WG and it’s clear from the discussions so f= ar that this document in no way suggesting to replace DUID.  I donR= 17;t see that this document in any way gives the impression to replace DUID. So= I think that making it explicit might not be required.

 <= /p>

For 5, We will take care = of it in the next revision or at the time of AUTH48 (whichever is earlier)<= o:p>

 <= /p>

-Gaurav=

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Be

rnie Volz (volz)
Sent: Wednesday, February 20, 2013 8:22 AM
To: Marcin Siodelski; dhcwg@ietf.org
Cc: Wojciech Dec (wdec)
Subject: Re: [dhcwg] Comments regarding draft-ietf-dhc-dhcpv6-client= -link-layer-addr-opt-04

 

(WG co-chair hat off R= 11; not that it has yet really been put on anyway.)

 <= /p>

Regarding #1 and #2, whil= e perhaps best to clarify that there is only one (in the Relay-Forw closest= to the client), I think these really are not ‘require’ to be addressed. We generally assume that only one is present when it is p= retty clear that is all that makes sense and the server would use only the = first (I doubt most servers would care to check for a second because there = is no reason to do so – yes, a server that processes the options sequentially might save just the last but that = isn’t a major issue and for various reasons I doubt any server proces= ses options this way).

 <= /p>

For #3, if a client adds = this, it will be in the client’s message and not in Relay-Forw so it = will be ignored by the server (and other relays).

 <= /p>

- =          Bernie=

 <= /p>

From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Marcin Siodelski
Sent: Tuesday, February 19, 2013 12:45 PM
To: dhcwg@ietf.org
Cc: Wojciech Dec (wdec)
Subject: [dhcwg] Comments regarding draft-ietf-dhc-dhcpv6-client-lin= k-layer-addr-opt-04

 

Hello, 

 

I have just read the draft-ietf-dhc-dhcpv6-client-li= nk-layer-addr-opt-04 and I have a few comments to share....

 

1. It is easy to deduce that there can be just a sin= gle instance of the option carrying the link-layer address in a particular = message. However, I think it should be explicitly mentioned for the clarity= of the document. Note that the standards don't prohibit sending multiple instances of the option with the certain c= ode. Also, some of the options may be included only once.

 

2. I suggest that it is mentioned what a server is s= upposed to do if it finds two instances of the option in the single DHCP me= ssage. ignore the options? Ignore the whole message? It is specifically imp= ortant when multiple options carry different link-layer addresses.

 

3. It is said that the Relay Agent MAY add the link-= layer option to the message, but it is NOT said what happens if a client se= nds this option. Again, is this ignored by the Relay Agent OR the Server?

 

4. I suggest that it is explicitly mentioned that th= e new option does not replace the DUID in any sense but it rather carries t= he supplementary information - the client-id requirements from the RFC3315 = still apply.

 

5. Minor: there is the inconsitency with respect to = the name of the option. In section 3: it is "Client Link-layer Address= ", in the header of the page it is "Client Link-layer address&quo= t;, in section 5 it is "client link-layer address", in section 7 it is "Client Link Layer Address".

 

Cheers,

Marcin

--_000_90903C21C73202418A48BFBE80AEE5EB22E61BC5xmbalnx06ciscoc_-- From wwwrun@rfc-editor.org Wed Feb 20 13:45:50 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE1A21E803F; Wed, 20 Feb 2013 13:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.34 X-Spam-Level: X-Spam-Status: No, score=-102.34 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7xmpuNNiDO1; Wed, 20 Feb 2013 13:45:49 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id D2BC921E8037; Wed, 20 Feb 2013 13:45:49 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C4CDEB1E014; Wed, 20 Feb 2013 13:44:58 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130220214458.C4CDEB1E014@rfc-editor.org> Date: Wed, 20 Feb 2013 13:44:58 -0800 (PST) Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] BCP 180, RFC 6853 on DHCPv6 Redundancy Deployment Considerations X-BeenThere: dhcwg@ietf.org 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, 20 Feb 2013 21:45:50 -0000 A new Request for Comments is now available in online RFC libraries. BCP 180 RFC 6853 Title: DHCPv6 Redundancy Deployment Considerations Author: J. Brzozowski, J. Tremblay, J. Chen, T. Mrugalski Status: Best Current Practice Stream: IETF Date: February 2013 Mailbox: john_brzozowski@cable.comcast.com, jf@jftremblay.com, jack.chen@twcable.com, tomasz.mrugalski@gmail.com Pages: 16 Characters: 34209 See Also: BCP 180 I-D Tag: draft-ietf-dhc-dhcpv6-redundancy-consider-03.txt URL: http://www.rfc-editor.org/rfc/rfc6853.txt This document provides information for those wishing to use DHCPv6 to support their deployment of IPv6. In particular, it discusses the provision of semi-redundant DHCPv6 services. This document is a product of the Dynamic Host Configuration Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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 tomasz.mrugalski@gmail.com Fri Feb 22 08:46:49 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F21521F8E74 for ; Fri, 22 Feb 2013 08:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=-0.622, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PymzAWfhzKXt for ; Fri, 22 Feb 2013 08:46:47 -0800 (PST) Received: from mail-wi0-x22a.google.com (wi-in-x022a.1e100.net [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 78CC821F85FE for ; Fri, 22 Feb 2013 08:46:47 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hm11so2371045wib.5 for ; Fri, 22 Feb 2013 08:46:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=2joUD5qyu0L67525du6Gy48R9h8XnNuLXULcVpf3FrQ=; b=ZuR5jVg55fCYRzfCbrvGjeP/y4TimcpQVZEU4XVPvK6MMWFSM1SveCnzlm5LWhKKMC 2YVAXR06qcQSJ2Yyzwi5jOZ59t7JXl+QRPm0je1GHP43tVWo3qOPvS9Z22SLNQETIl4G 4n8XwBPfccey4Mo+1dfAKzJ30K9lk/k4KIV4N/xga5VifkZ5LD1uyWXi3/+tr6KjUw1k b5DBb/mLz7tRJRTSaqEXK9+pA3jZ4xtvfzOyJfwCpyZO6kUBfLcKdQU8FgTDpLT0b7ck 31E6hxUjVmIeP7VOKrZ3KfoO15Hbx5r7p9+1J8OdXDlHd+rr2z4xc8+VNw4N9FzcXxzl h1cA== X-Received: by 10.180.108.3 with SMTP id hg3mr37635wib.33.1361551604555; Fri, 22 Feb 2013 08:46:44 -0800 (PST) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id dw1sm4613387wib.5.2013.02.22.08.46.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Feb 2013 08:46:43 -0800 (PST) Message-ID: <5127A0EF.4030508@gmail.com> Date: Fri, 22 Feb 2013 17:46:39 +0100 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: dhcwg@ietf.org References: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> <90903C21C73202418A48BFBE80AEE5EB22DEB892@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843CA16@xmb-rcd-x04.cisco.com> <90903C21C73202418A48BFBE80AEE5EB22DEDE19@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E18442EC0@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E184431CF@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E184431CF@xmb-rcd-x04.cisco.com> X-TagToolbar-Keys: D20130222174639871 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-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, 22 Feb 2013 16:46:49 -0000 On 22.01.2013 00:24, Bernie Volz (volz) wrote: >> The original text says to return an IA_* with no addr/prefix and a >> status code "NoBinding". Now, if we cannot fulfill the binding, we >> do the same thing, but we don't include a status code. Is that >> right? > > Hum ... perhaps it is best to follow the Request and return > NoAddrsAvail status in the IA_* option (of course we'd need to update > RFC 3633 text then as well to return NoPrefixAvail). > > The choices now seem to be: 1. Just return the IA_* option (empty). > 2. Return IA_* option with NoAddrsAvail (or NoPrefixAvail) -- > following Request logic. 3. Return IA_* option with NoBinding -- > following existing Renew logic for unknown bindings. 4. Don't return > the IA_* option (I think this is not a good choice and believe you > don't either). > > Perhaps new #2 is the best as it matches the Request ... Renew and > Request are really very similar anyway - the main differences were: - > We are telling the server the client is renewing (thus is using the > leases) - No new bindings were 'allowed' -- this is now not true and > what we are proposing to change. Agree. Include IA_* with status code (#2 or #3, depending on the situation) in it is my preference as well. Ideally we should do that for every response server generates, regardless of the message type that triggered it (solicit, request, renew, rebind, but also decline and confirm). A question about NoAddrsAvail status. The typical meaning is obvious (we run out of addresses), but some implementations (e.g. dibbler) allows you to specify that each client can get up to specified maximum number of addresses. If you configure that to two, and client sends three IA_NAs, two of them will be assigned and the third one will get NoAddrsAvail status (within 3rd IA_NA). Is this allowed behavior within the proposed text? The text should clarify that while there are currently 3 IA types defined (IA_NA, IA_TA, IA_PD), there may be more defined in the future and the same approach will apply to them. I'm not sure how likely new IA types are, but there's one DHC draft that defines IA_PA and it seems to be alive (draft-ietf-dhc-host-gen-id-04). Another aspect I'd like this draft to clarify is whether REPLY sent as a response to REQUEST must include exactly the addresses/prefixes sent in REQUEST. Currently strict interpretation of the 18.2.1 section of RFC3315 (6th paragraph) says that is must reject it: If the server cannot assign any addresses to an IA in the message from the client, the server MUST include the IA in the Reply message with no addresses in the IA and a Status Code option in the IA containing status code NoAddrsAvail. We should update that text to allow other addresses being assigned if that specified address/prefix is no longer available. Here's a rationale for it. Currently when server sends Advertise, it should keep the addresses and prefixes in a not well defined state. They are not leased yet (there's specific text that forbids forming lease at that time), but they are reserved for a short time with the expectation that the client will send Request shortly. This short-term reservation is annoying and unnecessary. It would be much simpler if the server sends address X in Advertise, but when the client sends Request with X in it, server sends Reply with address Y instead. ("sorry, someone else got X, here's Y for you"). There's a specific scenario, where this is very helpful. Imagine a case where large network recovers after blackout and you have thousands of clients trying to get addresses. Server will respond faster if it only needs to complete address/prefix selection and send the advertise (without needing to update its database to mark the address as temporary reserved). Also, some comments about specific sections of the text: Section 4.2 It would be better to says failure status codes (i.e. other than Success), rather than enumerate them explicitly. As said above, I very much prefer to include status codes in IA. I think the argument about status codes in global scope in somewhat dubious. Old clients that will not find status code in global scope will try to get an address from IA and find out that it is not there. Anyway, if you care about backward compability, I propose to add the following text: Server MUST include status code in each IA and MAY include in global scope. Imagine a case, where client requests IA_NA, IA_TA and IA_PD. Server assigns only non-temporary (NA) address, but no temporary or prefix. What would the global status be: Success, NoAddrsAvail or NoPrefixAvail? There's no valid answer to that question. Section 4.5 Since this proposal extends CONFIRM to cover IA_PD as well, it would be useful to have the capability to say: this address is valid here, but that prefix is not. For the we need the capability to provide per IA response. I would like to have section 18.2.2 of RFC3315 updated. We can add the same text as proposed in section 4.2 (MUST include status in IA, MAY include in global scope). I think this approach would be backwards compatible - old clients would just ignore received extra IA options in CONFIRM. Section 4.6 How would the "client get back a lease" work? This is all happening on the server side, right? The server remembers that the client used address X last time and since it is free when client tries to renew it, server may as well assign it again. That's my interpretation and I hope you meant that. The other interpretation would be "the client can use its address past its expiration time, just needs to send RENEW". We should reword this section to make it clear that this is not the case. I think rewording it as "A client can attempt to get back a lease by using RENEW message, but must adhere to server's response". This is basic common sense for anyone dealing with DHCP, but I've heard scary ideas on more than one occasion, so it's better to be very clear. I would very much prefer that client that released address or prefix used Request rather than Renew. I don't like the idea, but since Renew and Request will be almost identical, I can live with it. I strongly support this work going forward (with or without my comments). Tomek p.s. A request for Bernie and Ole: Once you guys are done with this draft, please don't throw away your notes and comments that you chose to not include. They'll be useful once we decide to start rfc3315bis work. > > We could do the same for the Rebind. > > BTW: The case for a Rebind where the server can't find the client > entry for the IA is not covered in RFC 3315 (it is if the addresses > are no longer appropriate, but not otherwise). In some ways, this > missing text leaves it up to the server (which for some cases, may be > good - for example, Failover may trust the client and if there is no > conflict, the server may want to respond -- that is what we do in > V4). In other instances, the server might want to drop the Rebind or > respond with NoBindings to force client back to Solicit? Also, the > Rebind is missing the text that allows the server to change the > addresses as appears in Renew. > > Opinions? > > - Bernie > > -----Original Message----- From: dhcwg-bounces@ietf.org > [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bud Millwood Sent: > Monday, January 21, 2013 5:52 PM To: Bernie Volz (volz) Cc: dhc WG; > Ted Lemon Subject: Re: [dhcwg] WGLC: > draft-ietf-dhc-dhcpv6-stateful-issues-03 > >> Regarding 4.2, how is that? It always means no addresses available >> but may mean prefixes available. > > Yes of course; I should have reviewed 3633. > >> Regarding 4.4, I would expect the server to return the IA_* option >> but without any IAADDR/IAPREFIX options. (The server would not >> really create a record of this binding since it has no leases.) >> Perhaps the text should be clarified regarding this. > > The original text says to return an IA_* with no addr/prefix and a > status code "NoBinding". Now, if we cannot fulfill the binding, we do > the same thing, but we don't include a status code. Is that right? > >> Note that perhaps a question exists as to which behavior to >> document for the Reply in this case: 1. Return the IA_* option, >> empty. 2. Do not return the IA_* option. Either approach would >> work. 1 may provide more information to the client (but client >> implementers may prefer 2) -- it is also sending back what the >> client sent (since it had no IAADDR/IAPREFIXes to include). > > (1) makes more sense to me because the server is explicitly > acknowledging the IA_*. > > - Bud > >> Regarding 4.5, ok one of those edits can be done in a -04 (after >> 28th when WGLC ends). Usually the RFC-Editor also catches things >> like this, but best to give them a better document to start with. >> >> - Bernie >> >> -----Original Message----- From: dhcwg-bounces@ietf.org >> [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bud Millwood Sent: >> Monday, January 21, 2013 10:28 AM To: Gaurav Halwasia (ghalwasi) >> Cc: dhc WG; Bernie Volz (volz); Ted Lemon Subject: Re: [dhcwg] >> WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >> >> 4.2: Proposed solution: No change. For backwards compatibility, >> the NoAddrsAvail Status Code option when no addresses are available >> will be kept in the global scope for Advertise messages. >> >> Question: Does it need to be further clarified that in Advertise, >> "NoAddrsAvail" now may mean "SomeAddrsAvail"? >> >> 4.4: Note that clients that communicate with servers that do not >> support this updated Renew processing will receive the NoBinding >> status for the IA which had no bindings. >> >> Question: isn't this also a valid response if the server does >> support updated Renew processing, but cannot fulfill the binding >> for the IA? >> >> 4.5: It lets a server without a binding to reply to the message, >> under the assumption that the server only needs knowledge about the >> prefix(es) on the link, to inform the client that the address is >> likely valid or not. >> >> - Change "lets" to "enables" or "allows", alt. remove "to" between >> "binding" and "reply". >> >> - Bud >> >> >> On Wed, Jan 16, 2013 at 5:43 AM, Gaurav Halwasia (ghalwasi) >> wrote: >>> Thanks for taking care of comments. I agree with you point >>> regarding point (3). >>> >>> -Gaurav >>> >>> -----Original Message----- From: Bernie Volz (volz) Sent: >>> Wednesday, January 16, 2013 2:38 AM To: Gaurav Halwasia >>> (ghalwasi); Ted Lemon; dhc WG Subject: RE: WGLC: >>> draft-ietf-dhc-dhcpv6-stateful-issues-03 >>> >>> Hi: >>> >>> Thanks for the comments, I've made some comments below (BV>). >>> >>> Let's wait until the 28th before I draft the -04 version. >>> Hopefully there will be more comments! >>> >>> - Bernie >>> >>> -----Original Message----- From: dhcwg-bounces@ietf.org >>> [mailto:dhcwg-bounces@ietf.org] On Behalf Of Gaurav Halwasia >>> (ghalwasi) Sent: Monday, January 14, 2013 10:47 PM To: Ted Lemon; >>> dhc WG Subject: Re: [dhcwg] WGLC: >>> draft-ietf-dhc-dhcpv6-stateful-issues-03 >>> >>> I read/reviewed this document and I support this document to move >>> forward. >>> >>> I do have some comments and it would be good if authors can >>> consider them. Even otherwise I support this document. >>> >>> 1.) In Abstract :- >>> >>> "Implementation experience of the CPE model described in has >>> shown multiple issues" I think you wanted to specify RFC6204 >>> after "described in" >>> >>> BV> Yes. >>> >>> 2.) Section 4.2 Placement of Status codes. In Reply messages IA >>> specific status codes (NoAddrsAvail, NotOnlink, NoBinding) are >>> encapsulated in the IA option. I think we should include >>> "NoPrefixAvail" as well in the above line. I see no reason why it >>> should not be. >>> >>> BV> Yes. Might be best to use (i.e.) too so that it is clear that >>> this is just a partial list. >>> >>> 3.) For Confirm message. As I understand, we are now allowing >>> CONFIRM message for IA_PD. I think we should update the >>> definition of CONFIRM message in RFC3315 which currently only >>> talks about *address* >>> >>> CONFIRM (4) A client sends a Confirm message to >>> any available server to determine whether the addresses it was >>> assigned are still appropriate to the link to which the client is >>> connected. >>> >>> BV> Well this is a bit tricky as RFC 3315 knows nothing of prefix >>> allocation. A RFC 3315bis would definitely want to reword it as >>> such (as I would expect it to combine 3315 and 3633). This really >>> falls into the changes to RFC 3633 that it would extend Confirm >>> to include prefixes. We tried (I hope) to keep the RFC 3315 >>> changes consistent with what RFC 3315 contained and PD changes to >>> RFC 3633. There might be more we could add to RFC 3633, but do we >>> really think that is necessary? I guess we could replace >>> "addresses" with something more generic ("configuration >>> information explicitly assigned to the client", which comes from >>> the definition of binding in RFC 3315), but I think that doesn't >>> really improve anything. >>> >>> BV> Thus, I will not make this change. >>> >>> >>> Thanks, Gaurav -----Original Message----- From: >>> dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf >>> Of Ted Lemon Sent: Tuesday, January 15, 2013 1:04 AM To: dhc WG >>> Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >>> >>> On Jan 14, 2013, at 2:15 PM, Bernie Volz (volz) >>> wrote: >>>> A 2nd Query regarding this as I heard nothing since the first. >>> >>> Oops, sorry about that, Bernie. >>> >>> Folks, the authors of this draft feel it's ready for a WGLC. >>> There's been substantial discussion and comment already. This >>> is pretty important IPv6 deployment work, so more eyes are >>> better. Please review the draft and indicate whether or not you >>> feel it is ready to be published. We have been getting very >>> anemic responses to working group messages recently. Your >>> response matters, so please do respond. >>> >>> We will evaluate consensus after January 28. Thanks! >>> >>> _______________________________________________ dhcwg mailing >>> list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >>> _______________________________________________ dhcwg mailing >>> list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >>> _______________________________________________ dhcwg mailing >>> list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ dhcwg mailing list >> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ dhcwg mailing list >> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list > dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list > dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg > From tomasz.mrugalski@gmail.com Fri Feb 22 08:49:44 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F201121F8E5D for ; Fri, 22 Feb 2013 08:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.133 X-Spam-Level: X-Spam-Status: No, score=-3.133 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MUG1SiNs7vX for ; Fri, 22 Feb 2013 08:49:43 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2809421F8E3C for ; Fri, 22 Feb 2013 08:49:43 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hq4so1173703wib.6 for ; Fri, 22 Feb 2013 08:49:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=/GxXLdzOAPMxULHw3QjtExMREwplyiIeFht0bgH4ybU=; b=0ibmPUqKD1+Y/1WE5Bb0UYmbGs+AGQLYk6tDSd/aomfN/T8emDb4V6V3JHIeRJpOM6 UnBfUBvCIwYNX1pkdXG3NIgLMilqPrBGUTHWvix8SkMCITPEYPMC2HmKPlp3/jjBUV9s rpbZ9bDn+Acea4p3yGvQ0J3W+iNmzI6PZWWb0EnRriOnYL65ExotMNRSzOJjebemMuGm hDc0+xaj6A7GT2+VMHVpG6/WB1fxVSXhc+Iqnra226KabxqF6YOfwbRKTj2n/sp6TzGf 8GfsaG7NqBg+xiV9MipC1eheYdJvDoPo6iBBXJDxgxDq9eTXaxad2M7sT/asfu24KvNB uRDg== X-Received: by 10.194.81.40 with SMTP id w8mr4859049wjx.14.1361551782140; Fri, 22 Feb 2013 08:49:42 -0800 (PST) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id fv2sm4635959wib.6.2013.02.22.08.49.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Feb 2013 08:49:41 -0800 (PST) Message-ID: <5127A1A2.4000801@gmail.com> Date: Fri, 22 Feb 2013 17:49:38 +0100 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: dhcwg@ietf.org References: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> X-TagToolbar-Keys: D20130222174938575 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-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, 22 Feb 2013 16:49:44 -0000 On 14.01.2013 20:34, Ted Lemon wrote: > On Jan 14, 2013, at 2:15 PM, Bernie Volz (volz) > wrote: >> A 2nd Query regarding this as I heard nothing since the first. > > We will evaluate consensus after January 28. Thanks! Oh, I forgot one minor comment. The draft should clarify that IAID values are distinct number spaces for each IA type, so IA_NA and IA_PD may both have iaid=1 and they are definitely different. That is a common understanding, but there are questions about that occasionally, so it would be nice to have a clear text to point to. Tomek From tomasz.mrugalski@gmail.com Fri Feb 22 13:06:49 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A0721E808C for ; Fri, 22 Feb 2013 13:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.226 X-Spam-Level: X-Spam-Status: No, score=-3.226 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-Y-WcNkRVpY for ; Fri, 22 Feb 2013 13:06:49 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 9D38A21E8088 for ; Fri, 22 Feb 2013 13:06:48 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id o1so1253511wic.17 for ; Fri, 22 Feb 2013 13:06:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=WrbfWtO71FWmXKLqIJt8wqjZXJ2qqfSZNIXLntIEjQA=; b=g4fb+sXTMqjAjGt/KrR5vYxzPh9o/qnJs5crmKA6TQF0dqiTj9SoB4pXeuZhgBMK+p zQNZaYTH9GwIhXqRqE8/J01+yOB6bGEPYrnYHzuxNEvhDrExhFdBc0Cwx6Um+fFeetCX oX4M0STP/CgcAG2PKV8g8/yY+FNL3HEBUxzBJB63xAeBWUyFXDNwrbi9eDMvtDVrjyKn 40POXWYdsGXm39gLzCbmRQqfU/DhOJh2RaotQ+cBK9RtmmEvOYmaULpBEcIYrKITT7yk X/0T4cNVt7fwjDL4mH61cFwpdJDpAOAJEWbIEnQC+apHwxDoW9OGPrjtfvz35baxVk+H mhUQ== X-Received: by 10.194.122.131 with SMTP id ls3mr6141893wjb.55.1361567207810; Fri, 22 Feb 2013 13:06:47 -0800 (PST) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id t7sm607578wiy.2.2013.02.22.13.06.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Feb 2013 13:06:46 -0800 (PST) Message-ID: <5127DDE0.4000706@gmail.com> Date: Fri, 22 Feb 2013 22:06:40 +0100 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: dhcwg@ietf.org References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748F074@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074748F074@mbx-01.win.nominum.com> X-TagToolbar-Keys: D20130222220640006 Content-Type: text/plain; charset=gb18030 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Comments on draft-rajtar-dhc-v4configuration-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, 22 Feb 2013 21:06:49 -0000 On 15.02.2013 15:26, Ted Lemon wrote: > So I'd like to propose that we stop the call for adoption on this > version of the document now, and that the authors reissue the > document, without the recommendation section, and with the addition > of Roberta's argument in favor of a DHCPv6-only solution, which I > think captures the real issue best. What is the plan with this work? I suppose it will be presented/discussed in Orlando, updated version will be published and second adoption call will be issued? Ted said that this is adoption thread, not a technical comments thread, but since the adoption call was cancelled, I hope it is ok to post my comments on it. I noted that -01 version does not include specific conclusion, merely a note that this conclusion will emerge as a group consensus. This is a step in right direction. My suggestion for the work forward would be to decide what are the changes needed (if we want to be more specific about requirements, what inside and what outside of scope, what the conclusion should be) and then adopt it, not the other way around. At first, this may be counter-intuitive, but there's a very good reason to do this in that order. There was (still is, but it seems to be dying slowly and being revived constantly) a draft about DHCPv6 routing configuration in MIF wg. The draft was adopted a long time ago, but the group didn't have consensus how it really should work. This is a hot controversial topic with many participants having strong opinions, similar to what we have here with draft-rajtar-dhc-v4configuration. If you attend MIF meetings, you'll notice that discussion about this takes a significant amount of time of every single MIF meeting, without much work going forward. I would very much like to avoid similar case in DHC. This draft has similar potential for endless pro and cons discussions as was demonstrated many times in Softwires. I agree with Woj's and Med's comments about a need to define what are the requirements (or preferences as Ted calls some of them). Depending on them, some pros/cons become very important or not important at all. Ok, here are my comments specific to the text: It would be helpful to add a stack description in sections 2.1, 2.2 and 2.3 (omething like DHCPv4/UDPv6/IPv6, DHCPv6/UDPv6/IPv6, and DHCPv4/UDPv4/IPv4/IPv6). Section 2.1: "The DHCPv4o6 server needs to be extended to support the new functionality, such as storing the IPv6 address of DHCPv4o6 clients." Is this really true? My undestanding is that the server needs to remember IPv6 address of the source packet to respond to it, but once the response is sent there is no need to store it further. Section 2.2 is overly simplistic. DHCPv6 based provisioning aims to provide only bare minimum to configure IPv4 stack, not the whole multitude of options that DHCPv4 has. Section 2.2 refers to I-D.mdt-softwire-map-dhcp-option, which is obsolete. It was adopted as I-D.softwire-map-dhcp. Section 2.3. Is there a draft available that proposes that architecture? Section 3.1.1, bullet 1: Remove extra "be". It should be mentioned that there's existing software that was proven to work (other pro/con sections mention existence or lack of suitable software). Section 3.1.2, bullet 1: can you elaborate? CRA is the only new element required. You can integrate it with client if you want to minimize number of new elements. Bullet 2 could possibly reference draft-mrugalski-softwire-dhcpv4-over-v6-option-01. Bullet 3 "DHCPv4 clients needs to be updated to implement the IPv6 encapsulation and decapsulation function." My understanding is that it is not always true. CRA can be a separate entity, you don't have to modify DHCPv4 client code. Bullet 4 "The DHCPv4 server needs to be updated to implement new DHCPv4o6 functionality.". I think that is not always true, as you can deploy Transport Relay Agent, right? You should add "requires DHCPv4 server to be deployed and maintained" to cons. Section 3.2.1 should mention that some solutions (MAP for sure. 4rd used to, I'm not sure if it still does) reuse parts of the IPv6 configuration (e.g. parts of PD) to provide IPv4 configuration. Section 3.2.2, bullet 1 suggests that there are many DHCPv4 options that would need to be ported, but in fact there are few (or even none) in most cases. I assume that bullet 2 discusses a new DHCPv6 options that are used to configure IPv4 transition technology, e.g. MAP. It raises an interesting point, which is considered a strong argument against that solution. Here's an idea to consider that could largely mitigate it. We could define a special range in DHCPv6 option space reserved for transition technologies, similar to what we have in DHCPv4 option space for reserved or private use. Any DHCPv6 options that would become useless after IPv4 goes away, would be assigned from that range. Once a vendor wants to go IPv6-only, it's just a matter of not supporting specific range of options. Bullet 3: I'm not sure where did you get the idea that DHCPv4 legacy options would be ported to DHCPv6? Such a thing is unreasonable to say the least. Can you point out specific draft or comment that suggested that? Section 3.3.1 "Uses the existing DHCPv4 and DHCPv6 architectures in order to provide IPv4 configuration in an IPv6 only environment.". If you reword to "requires..." instead of "uses...", it suddenly may be considered a con in many deployments that do not have DHCPv4 deployed. Section 3.3.2, bullet 4 mentions ietf-dhc-dhcpinform-clarify. This draft is dead for over 2 years and David, its author, is unlikely to revive it. You should add "requires DHCPv4 server to be deployed and maintained" to cons. You should add "no existing software available yet" to cons. My personal observation is that this is not a completely solvable problem and there won't be a single conclusion, like "use DHCPv4" or "use DHCPv6" that would satisfy everyone (or at least a large majority). I think the way forward here would be to do something similar as we did in dhc-option-guidelines: define a set of guidelines, not "you must always use X". Hope that helps, Tomek From volz@cisco.com Sun Feb 24 11:38:07 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E487221F84B1 for ; Sun, 24 Feb 2013 11:38:07 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzVSePbM6Y-e for ; Sun, 24 Feb 2013 11:38:03 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id CB7BB21F84B0 for ; Sun, 24 Feb 2013 11:38:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7557; q=dns/txt; s=iport; t=1361734682; x=1362944282; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=gMR6Y+bi+r+0LLWlF/koxgqr3fn3+0+7tOI1dHULBJQ=; b=ms8vg9SjzWn/yQZiDmfPxDSWFPK4IIN8ltl+rsiOWb33GQuKAmNpJPGo A79+5EILTv/2vAIN2ByfOhtYgrDDoSE+3MOUCdsbyLpns7eIlZG/HJVHL Qk3LJ5Qv7VaoycwtJPPtQgX8U6vRLh1yrif6GtOThzfcH4Fxm52W35KlN w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANdqKlGtJXG//2dsb2JhbABFwVCBEBZzgh8BAQEEAQEBGh00FwQCAQgOAwEDAQEBChQJBycLFAMGCAIEARIIE4d4DLxEBI5dOAaCWWEDkkI6lCaDB4FpBDo X-IronPort-AV: E=Sophos;i="4.84,730,1355097600"; d="scan'208";a="180374606" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 24 Feb 2013 19:38:02 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1OJc271015008 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 24 Feb 2013 19:38:02 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Sun, 24 Feb 2013 13:38:01 -0600 From: "Bernie Volz (volz)" To: Tomek Mrugalski , "dhcwg@ietf.org" Thread-Topic: [dhcwg] Comments on draft-rajtar-dhc-v4configuration-01 Thread-Index: AQHOEUCKVlrfSKYsskGH4YThn1NhjJiJZ91A Date: Sun, 24 Feb 2013 19:38:01 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1847B8CA@xmb-rcd-x04.cisco.com> References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748F074@mbx-01.win.nominum.com> <5127DDE0.4000706@gmail.com> In-Reply-To: <5127DDE0.4000706@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.66] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Comments on draft-rajtar-dhc-v4configuration-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: Sun, 24 Feb 2013 19:38:08 -0000 I think comments are always welcome :). One concern I have (WG co-chair hat mostly off) with this whole area is tha= t I don't really have a clear sense for what is required of the players - o= perator/service provider (in its network, for its devices) and what is requ= ired by the subscriber (client side) or OS provider. While I understand that there may be situations where operators have no cho= ice (because they have few IPv4 addresses), but I think it is important for= us to understand what the tradeoffs are as there may be some operators tha= t will continue to prefer providing IPv4. Note that this isn't necessarily something that this particular draft has t= o provide, but it more of a general comment for all of the drafts in this s= pace. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= omek Mrugalski Sent: Friday, February 22, 2013 4:07 PM To: dhcwg@ietf.org Subject: [dhcwg] Comments on draft-rajtar-dhc-v4configuration-01 On 15.02.2013 15:26, Ted Lemon wrote: > So I'd like to propose that we stop the call for adoption on this=20 > version of the document now, and that the authors reissue the=20 > document, without the recommendation section, and with the addition of=20 > Roberta's argument in favor of a DHCPv6-only solution, which I think=20 > captures the real issue best. What is the plan with this work? I suppose it will be presented/discussed i= n Orlando, updated version will be published and second adoption call will = be issued? Ted said that this is adoption thread, not a technical comments thread, but= since the adoption call was cancelled, I hope it is ok to post my comments= on it. I noted that -01 version does not include specific conclusion, merely a not= e that this conclusion will emerge as a group consensus. This is a step in = right direction. My suggestion for the work forward would be to decide what= are the changes needed (if we want to be more specific about requirements,= what inside and what outside of scope, what the conclusion should be) and = then adopt it, not the other way around. At first, this may be counter-intu= itive, but there's a very good reason to do this in that order. There was (= still is, but it seems to be dying slowly and being revived constantly) a d= raft about DHCPv6 routing configuration in MIF wg. The draft was adopted a = long time ago, but the group didn't have consensus how it really should wor= k. This is a hot controversial topic with many participants having strong o= pinions, similar to what we have here with draft-rajtar-dhc-v4configuration= . If you attend MIF meetings, you'll notice that discussion about this take= s a significant amount of time of every single MIF meeting, without much wo= rk going forward. I would very much like to avoid similar case in DHC. This= draft has similar potential for endless pro and cons discussions as was de= monstrated many times in Softwires. I agree with Woj's and Med's comments about a need to define what are the r= equirements (or preferences as Ted calls some of them). Depending on them, = some pros/cons become very important or not important at all. Ok, here are my comments specific to the text: It would be helpful to add a stack description in sections 2.1, 2.2 and 2.3 (omething like DHCPv4/UDPv6/IPv6, DHCPv6/UDPv6/IPv6, and DHCPv4/UDPv4/I= Pv4/IPv6). Section 2.1: "The DHCPv4o6 server needs to be extended to support the new f= unctionality, such as storing the IPv6 address of DHCPv4o6 clients." Is thi= s really true? My undestanding is that the server needs to remember IPv6 address of the source packet to respond to it, but once the response i= s sent there is no need to store it further. Section 2.2 is overly simplistic. DHCPv6 based provisioning aims to provide= only bare minimum to configure IPv4 stack, not the whole multitude of opti= ons that DHCPv4 has. Section 2.2 refers to I-D.mdt-softwire-map-dhcp-option, which is obsolete. = It was adopted as I-D.softwire-map-dhcp. Section 2.3. Is there a draft available that proposes that architecture? Section 3.1.1, bullet 1: Remove extra "be". It should be mentioned that there's existing software that was proven to wo= rk (other pro/con sections mention existence or lack of suitable software). Section 3.1.2, bullet 1: can you elaborate? CRA is the only new element req= uired. You can integrate it with client if you want to minimize number of n= ew elements. Bullet 2 could possibly reference draft-mrugalski-softwire-dhcpv4-over-v6-option-01. Bullet 3 "DHCPv4 clients needs to be updated to implement the IPv6 encapsul= ation and decapsulation function." My understanding is that it is not alway= s true. CRA can be a separate entity, you don't have to modify DHCPv4 clien= t code. Bullet 4 "The DHCPv4 server needs to be updated to implement new DHCPv4o6 functionality.". I think that is not always true, as you can deplo= y Transport Relay Agent, right? You should add "requires DHCPv4 server to be deployed and maintained" to co= ns. Section 3.2.1 should mention that some solutions (MAP for sure. 4rd used to= , I'm not sure if it still does) reuse parts of the IPv6 configuration (e.g= . parts of PD) to provide IPv4 configuration. Section 3.2.2, bullet 1 suggests that there are many DHCPv4 options that wo= uld need to be ported, but in fact there are few (or even none) in most cas= es. I assume that bullet 2 discusses a new DHCPv6 options that are used to conf= igure IPv4 transition technology, e.g. MAP. It raises an interesting point,= which is considered a strong argument against that solution. Here's an ide= a to consider that could largely mitigate it. We could define a special ran= ge in DHCPv6 option space reserved for transition technologies, similar to = what we have in DHCPv4 option space for reserved or private use. Any DHCPv6= options that would become useless after IPv4 goes away, would be assigned = from that range. Once a vendor wants to go IPv6-only, it's just a matter of= not supporting specific range of options. Bullet 3: I'm not sure where did you get the idea that DHCPv4 legacy option= s would be ported to DHCPv6? Such a thing is unreasonable to say the least.= Can you point out specific draft or comment that suggested that? Section 3.3.1 "Uses the existing DHCPv4 and DHCPv6 architectures in order to provide IPv4 configuration in an IPv6 only environment.". If you reword to "require= s..." instead of "uses...", it suddenly may be considered a con in many dep= loyments that do not have DHCPv4 deployed. Section 3.3.2, bullet 4 mentions ietf-dhc-dhcpinform-clarify. This draft is= dead for over 2 years and David, its author, is unlikely to revive it. You should add "requires DHCPv4 server to be deployed and maintained" to co= ns. You should add "no existing software available yet" to cons. My personal observation is that this is not a completely solvable problem a= nd there won't be a single conclusion, like "use DHCPv4" or "use DHCPv6" th= at would satisfy everyone (or at least a large majority). I think the way forward here would be to do something similar as we did in = dhc-option-guidelines: define a set of guidelines, not "you must always use= X". Hope that helps, Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Sun Feb 24 19:55:50 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8657321F91B9 for ; Sun, 24 Feb 2013 19:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0ao3xL6-Obs for ; Sun, 24 Feb 2013 19:55:49 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD4821F919B for ; Sun, 24 Feb 2013 19:55:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3880; q=dns/txt; s=iport; t=1361764549; x=1362974149; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=Titd+GPiDPzZdpL6a0T9ZKP2NolN6GZGlZjWPVoRfO0=; b=gqyrSNGBSSMkxbIGNmSsDlseV98qTue6Ke7anw5vhncDhs/DOnpqqd/t 8N5DcdW0fTyULasjQ9N74VnRtcD5RLduOZYrkEtJSxrRcg0HtL9GdZlgu HIlhzTaVTOi6UOuiORBcVwWKur1kP8QXk3DF+Dyuny7OMZwRM6yVfUCdr c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAMnfKlGtJV2c/2dsb2JhbABFwVKBEhZzgh8BAQEEAQEBGh00CwwGAQgQAQQBAQsUCS4LFAkJAQQOBQiICwy9IQSOXSYLDYJZYQOnIoMHgic X-IronPort-AV: E=Sophos;i="4.84,731,1355097600"; d="scan'208";a="180643431" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 25 Feb 2013 03:55:49 +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 r1P3tmJA011378 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Feb 2013 03:55:48 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Sun, 24 Feb 2013 21:55:48 -0600 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] Call for agenda items for DHC working group meeting in Orlando Thread-Index: Ac4TC1wND0Df3aZnT1KHVKc6JdYpwA== Date: Mon, 25 Feb 2013 03:55:47 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1847C244@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.66] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " Chairs" Subject: Re: [dhcwg] Call for agenda items for DHC working group meeting in Orlando X-BeenThere: dhcwg@ietf.org 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, 25 Feb 2013 03:55:50 -0000 Hi: Just another reminder to submit agenda items (I've taken over collecting th= ese from Ted and best to send to dhc-chairs or dhcwg). I am working up the WG status (thanks to Ted for an initial pass) and here'= s a rough draft which might remind people about things they may want to tal= k about. Also, please point out any errors or omissions!! (In many cases t= he "??" are just because I haven't gone back to look over the mailing list = and docs.) In the IESG: draft-ietf-dhc-dhcpv6-redundancy-consider - published as RFC 6853. draft-ietf-dhc-dhcpv4-bulk-leasequery-07 - waiting on the draft-ietf-dhc-relay-id-suboption-13 draft draft-ietf-dhc-relay-id-suboption-13 - updated document to be reviewed by IESG to clear discusses draft-ietf-dhc-client-id - published as RFC 6842 draft-ietf-dhc-relay-id-13 - Updated to address concerns raised in IESG; hopefully this will clear outstanding DISCUSSes draft-ietf-dhc-secure-dhcpv6-07 - writeup done, document sent to IESG - Ralph voted yes in the Feb. 25 telechat, no review has happened at the IESG yet. - Francis Dupont (Gen-ART reviewer for draft) provided comments (2/24/2013) and feels this work is NOT READY. draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04 - document is being evaluated by the IESG. In the working group: draft-ietf-dhc-dhcpv6-tunnel-01 [EXPIRED] - Does anybody have plans for what to do next? draft-ietf-dhc-failover-requirements-02 draft-ietf-dhc-dhcpv6-failover-design-02 - Tomek? draft-ietf-dhc-addr-registration-01 - new version expected? - good opportunity to address DNS registration issue? draft-bhandari-dhc-class-based-prefix-01 - authors would like wg to adopt - there's some hope that some interested parties will help to make the document more broadly applicable - Ian, Schwetha, Sri, what's happening with that? draft-ietf-dhc-dhcpv6-radius-opt-04 - Bernie to evaluate consensus - If consensus, Bernie will do shepherd doc with help from Ted =20 draft-ietf-dhc-container-opt-06 - Reinaldo Penno has taken on this work draft-ietf-dhc-dhcpv4-over-ipv6-01 - ?? =20 draft-rajtar-dhc-v4configuration-01 - Roberta's text added, conclusion removed - New call for adoption? draft-lemon-dhc-dns-pd-00 - call for adoption sent - waiting on consensus eval =20 draft-ietf-dhc-dhcpv6-solmaxrt-update - question about spanning tree nd dropping initial packet draft-ietf-dhc-dhcpv6-stateful-issues-03 - Last call had plenty of good comments, mostly nits and clarifications. - 04 will be required draft-ietf-dhc-triggered-reconfigure-03 - In WGLC until 28th draft-mrugalski-softwire-dhcpv4-over-v6-option-01 - ?? draft-ietf-dhc-cga-config-dhcpv6-04 - ?? draft-ietf-dhc-dhcpv6-load-balancing-00 - ?? draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 - ?? draft-ietf-dhc-option-guidelines-09 - ?? draft-ietf-dhc-host-gen-id-04 - Expiring (3/3/2013) -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Wednesday, February 13, 2013 9:36 AM To: dhcwg@ietf.org WG Cc: Chairs Subject: [dhcwg] Call for agenda items for DHC working group meeting in Orl= ando Folks, it's that time again. If you have anything you'd like to present i= n Orlando, please send agenda requests to dhc-chairs@ietf.org. The meetin= g is Thursday afternoon, and we have a two-hour slot. Does anybody want us to set up Meetecho? This would allow some degree of = online participation for working group members who cannot get to Orlando. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Sun Feb 24 19:58:15 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84F921F9079 for ; Sun, 24 Feb 2013 19:58:15 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDbSus1flK75 for ; Sun, 24 Feb 2013 19:58:15 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2A21021F8713 for ; Sun, 24 Feb 2013 19:58:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=877; q=dns/txt; s=iport; t=1361764695; x=1362974295; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=w5NLC8mbi35uPMQh04bmzwUg99mU3rV/cnwFnYLCwkw=; b=dhZR8Czd4AglMqZOUGxZybDW5b8dcSinRx+1oVJn+5uW3upq8gZPgZLn 5pVSRtdbJ6BN09rGYvtu3r4lrGWRLJpoepFNfDtyUsa9i9YkXGj9tmpzo APXQgyB6STJ8aK/k2BUb+1Z146OIZqIL3z857ge3LQeb5FuU3ktIXsHYM 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAAHgKlGtJXHB/2dsb2JhbABFhgi7SoESFnOCHwEBAQQBAQE3NBcGARkEAQELCwkJLgsUCQkBBBMIiAsMnH2gJQSOXSYYBIJVYQOnIoMHgic X-IronPort-AV: E=Sophos;i="4.84,731,1355097600"; d="scan'208";a="180649792" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 25 Feb 2013 03:58:14 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r1P3wEnV026307 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 25 Feb 2013 03:58:14 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Sun, 24 Feb 2013 21:58:14 -0600 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org WG" Thread-Topic: Reminder - [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-03 Thread-Index: Ac4TDC56G0zq8cNJS9i4XtVynMwIbA== Date: Mon, 25 Feb 2013 03:58:14 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1847C264@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.66] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] Reminder - WGLC: draft-ietf-dhc-triggered-reconfigure-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, 25 Feb 2013 03:58:15 -0000 Just a reminder that this WGLC is coming to a close (Feb 28) and I believe = there's only been one response so far. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Thursday, February 14, 2013 11:16 AM To: dhcwg@ietf.org WG Subject: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-03 Med has updated the draft to account for comments made during the working g= roup last call. This is a new WGLC: if you had comments on the previous d= raft, please review the changes. If you are in favor of advancing the dra= ft, please say so. If you oppose advancing the draft, please say so. We will determine consensus on February 28. Thanks! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Sun Feb 24 20:10:21 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38A521F91CA for ; Sun, 24 Feb 2013 20:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TucmbxaXH8AY for ; Sun, 24 Feb 2013 20:10:20 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 4589021F91CB for ; Sun, 24 Feb 2013 20:10:20 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUSrkJbl/tKZty7scRE8lRbbl5AYuPrul@postini.com; Sun, 24 Feb 2013 20:10:20 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E46571B8386 for ; Sun, 24 Feb 2013 20:10:12 -0800 (PST) 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 D8292190043; Sun, 24 Feb 2013 20:10:12 -0800 (PST) (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.0318.004; Sun, 24 Feb 2013 20:10:12 -0800 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] Reminder - WGLC: draft-ietf-dhc-triggered-reconfigure-03 Thread-Index: Ac4TDC56G0zq8cNJS9i4XtVynMwIbAARODOA Date: Mon, 25 Feb 2013 04:10:12 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074749E240@mbx-01.win.nominum.com> References: <489D13FBFA9B3E41812EA89F188F018E1847C264@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1847C264@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <0154B86E9D68C64C86716F3E2375CA65@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Reminder - WGLC: draft-ietf-dhc-triggered-reconfigure-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, 25 Feb 2013 04:10:21 -0000 On Feb 24, 2013, at 10:58 PM, Bernie Volz (volz) wrote: > Just a reminder that this WGLC is coming to a close (Feb 28) and I believ= e there's only been one response so far. Chair/AD hat off, I think the draft is a good idea and we should publish it= . From ghalwasi@cisco.com Sun Feb 24 20:18:30 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826DF21F90F8 for ; Sun, 24 Feb 2013 20:18:30 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCTaSZuiG6gH for ; Sun, 24 Feb 2013 20:18:29 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3BC21F9099 for ; Sun, 24 Feb 2013 20:18:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1352; q=dns/txt; s=iport; t=1361765909; x=1362975509; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=JVfjX14Ifs9UVm3JRGVQzoNbr/POjd4GKsno82jkSbM=; b=Y96lkpQgwsUo180eed0tVaeigHGRmnzAIS9BPvUD2dRlhhGku3rzmVlv 4/hGLtxYqvmLVWCzKJH19bZs6rx/qCqXMN0C7LMwUwtC5sLdU8S8vM0wT uOrvjpeQJLJWhRuHJnpsIzw+UHGNMoBYv238r60vzQlfC2ioQO/puk1My k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABzlKlGtJXHA/2dsb2JhbABFwVKBExZzgh8BAQEEAQEBNzQXBAIBCBEEAQELCwkJBycLFAkIAQEEARIIiAsMvSMEjl0mEgYEglVhA6cigweCJw X-IronPort-AV: E=Sophos;i="4.84,731,1355097600"; d="scan'208";a="180647045" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 25 Feb 2013 04:18:29 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1P4ISj0011277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 25 Feb 2013 04:18:28 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.248]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Sun, 24 Feb 2013 22:18:28 -0600 From: "Gaurav Halwasia (ghalwasi)" To: "Bernie Volz (volz)" , "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] Reminder - WGLC: draft-ietf-dhc-triggered-reconfigure-03 Thread-Index: Ac4TDC56G0zq8cNJS9i4XtVynMwIbAAAvV0w Date: Mon, 25 Feb 2013 04:18:27 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB22E6F6FF@xmb-aln-x06.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E1847C264@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1847C264@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.142.100.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Reminder - WGLC: draft-ietf-dhc-triggered-reconfigure-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, 25 Feb 2013 04:18:30 -0000 I support the advancement of this draft. It should move forward. -Gaurav -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ernie Volz (volz) Sent: Monday, February 25, 2013 9:28 AM To: dhcwg@ietf.org WG Subject: [dhcwg] Reminder - WGLC: draft-ietf-dhc-triggered-reconfigure-03 Just a reminder that this WGLC is coming to a close (Feb 28) and I believe = there's only been one response so far. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Thursday, February 14, 2013 11:16 AM To: dhcwg@ietf.org WG Subject: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-03 Med has updated the draft to account for comments made during the working g= roup last call. This is a new WGLC: if you had comments on the previous d= raft, please review the changes. If you are in favor of advancing the dra= ft, please say so. If you oppose advancing the draft, please say so. We will determine consensus on February 28. Thanks! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From internet-drafts@ietf.org Mon Feb 25 01:39:55 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7153221F926C; Mon, 25 Feb 2013 01:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5YMjv7+YcZI; Mon, 25 Feb 2013 01:39:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE4521F926D; Mon, 25 Feb 2013 01:39:54 -0800 (PST) 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.40 Message-ID: <20130225093954.7875.53413.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 01:39:54 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-addr-registration-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: Mon, 25 Feb 2013 09:39:55 -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 : A Generic IPv6 Addresses Registration Solution Using DHC= Pv6 Author(s) : Sheng Jiang Gang Chen Suresh Krishnan Filename : draft-ietf-dhc-addr-registration-02.txt Pages : 9 Date : 2013-02-25 Abstract: In networks that are centrally managed, self-generated addresses cause traceability issues due to their decentralized nature. To minimize the issues due to lack of traceability, these self-generated addresses can be registered with the network for allowing centralized address administration. This document defines a generic address registration solution using DHCPv6, using a new ND option and a new DHCPv6 option in order to communicate the use of self-generated addresses. A new Addr-registration-request message type is defined for initiate the address registration request, among with two new Status codes to indicate registration errors on the server side. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-addr-registration-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Feb 25 01:47:51 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC0221F8EB4; Mon, 25 Feb 2013 01:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gVYG7AIkAQF; Mon, 25 Feb 2013 01:47:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77C121F8EB2; Mon, 25 Feb 2013 01:47:50 -0800 (PST) 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.40 Message-ID: <20130225094750.6207.64542.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 01:47:50 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-host-gen-id-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 09:47:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : Prefix Assignment in DHCPv6 Author(s) : Sheng Jiang Frank Xia Behcet Sarikaya Filename : draft-ietf-dhc-host-gen-id-05.txt Pages : 11 Date : 2013-02-25 Abstract: This document introduces a generic host-oriented prefix assignment mechanism using DHCPv6. In this new address configuration procedure, the prefix is assigned from a DHCPv6 server to hosts through DHCPv6 message exchanging while the interface identifiers are independently generated by the hosts. It enables both integral address assignment and self-generated addresses in one single mechanism, DHCPv6. It also enables stateless address configuration without RA attendance. The technique described in this document can be used in networks which assign IPv6 addresses using DHCPv6, e.g. WiMAX. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-host-gen-id There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-host-gen-id-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-host-gen-id-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Feb 25 02:14:43 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7A321F9227; Mon, 25 Feb 2013 02:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbrE0dMN+3Hk; Mon, 25 Feb 2013 02:14:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321E921F8FCE; Mon, 25 Feb 2013 02:14:43 -0800 (PST) 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.40 Message-ID: <20130225101443.6197.88099.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 02:14:43 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-09.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, 25 Feb 2013 10:14:44 -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 Agent on the Broadband Ac= cess Servers Author(s) : Leaf Y. Yeh Mohamed Boucadair Filename : draft-ietf-dhc-dhcpv6-radius-opt-09.txt Pages : 11 Date : 2013-02-25 Abstract: The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between the DHCPv6 relay agent and the DHCPv6 server. This mechanism is meant for the centralized DHCPv6 server to select the right configuration for the requesting DHCPv6 client based on the authorization information received from the RADIUS server, which is not co-located with the DHCPv6 server. The Network Access Server (NAS) acts as DHCPv6 relay agent and RADIUS client simultaneously in this document. 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-radius-opt-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Branimir.Rajtar@t.ht.hr Mon Feb 25 03:00:56 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A794721F925A for ; Mon, 25 Feb 2013 03:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=0.712, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZhOQ+rZ3O7S for ; Mon, 25 Feb 2013 03:00:55 -0800 (PST) Received: from mx02.t.ht.hr (mx02.t.ht.hr [195.29.161.89]) by ietfa.amsl.com (Postfix) with SMTP id 693A721F913F for ; Mon, 25 Feb 2013 03:00:53 -0800 (PST) Received: from no.name.available by mx02.t.ht.hr via smtpd (for mail.ietf.org [64.170.98.30]) with ESMTP; Mon, 25 Feb 2013 11:28:48 +0100 Received: from (unknown [172.17.66.76]) by scmg2.t.ht.hr with smtp id 2fda_4d3c_9deee8a6_7f3a_11e2_880b_00219b931f47; Mon, 25 Feb 2013 12:00:50 +0100 Received: (private information removed) Mon, 25 Feb 2013 12:00:51 +0100 Received: (private information removed) S2010EXCHCA1.ad.local ([::1]) with mapi id 14.02.0328.009; Mon, 25 Feb 2013 12:00:50 +0100 From: Branimir Rajtar To: "Bernie Volz (volz)" , Tomek Mrugalski , "dhcwg@ietf.org" Thread-Topic: [dhcwg] Comments on draft-rajtar-dhc-v4configuration-01 Thread-Index: AQHOEUCMyYdKhKQolU6vqqlnhbdJGJiJWaSAgAEPjoA= Date: Mon, 25 Feb 2013 11:00:50 +0000 Message-ID: <786F13AA11E69F4DB2CCA23F7400C2FB0661FF@S2010EXCH1.ad.local> References: <8D23D4052ABE7A4490E77B1A012B630747487A63@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074748F074@mbx-01.win.nominum.com> <5127DDE0.4000706@gmail.com> <489D13FBFA9B3E41812EA89F188F018E1847B8CA@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1847B8CA@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.5.14] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 25 Feb 2013 11:00:51.0003 (UTC) FILETIME=[5FBB28B0:01CE1347] X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Subject: Re: [dhcwg] Comments on draft-rajtar-dhc-v4configuration-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, 25 Feb 2013 11:00:56 -0000 SGkgYWxsLAoKRmlyc3Qgb2YgYWxsLCBJIHdhbnRlZCB0byB0aGFuayB5b3UgZm9yIHRoZSBjb21t ZW50cyB0aGF0IHdlcmUgZ2l2ZW4gLSBJIGZvdW5kIHRoZW0gdmVyeSB1c2VmdWwuIAoKSG93ZXZl ciwgYmVmb3JlIEkgc3RhcnQgZ29pbmcgdGhyb3VnaCB0aGVtLCBJIHdvdWxkIGxpa2UgdG8gZ2V0 IGluZm9ybWF0aW9uIGZyb20gQmVybmllIG9uIGhvdyBoZSB3YW50cyB0byBwcm9jZWVkIHdpdGgg dGhpcyBkcmFmdC4gQWNjb3JkaW5nIHRvIFRlZCBMZW1vbidzIGlkZWEsIHdlIHdlcmUgZ29pbmcg dG8gZ2V0IGl0IGFwcHJvdmVkIGFuZCBhZnRlcndhcmRzIHdvcmsgb24gdGhlIGRldGFpbHMuIElu IG15IG9waW5pb24sIGl0J3MgYSB2YWxpZCBhcHByb2FjaCBzaW5jZSB3ZSBkb24ndCB3YW50IHRv IHdvcmsgb24gaXQgYW5kIGluIHRoZSBlbmQgaXQgdHVybnMgb3V0IHRoYXQgdGhlIFdHIGRvZXNu J3QgaGF2ZSBhbnkgbmVlZCBmb3IgaXQuCgpCUiwKQnJhbmltaXIgUmFqdGFyCgoKLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0KRnJvbTogZGhjd2ctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRo Y3dnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCZXJuaWUgVm9seiAodm9seikKU2Vu dDogU3VuZGF5LCBGZWJydWFyeSAyNCwgMjAxMyA4OjM4IFBNClRvOiBUb21layBNcnVnYWxza2k7 IGRoY3dnQGlldGYub3JnClN1YmplY3Q6IFJlOiBbZGhjd2ddIENvbW1lbnRzIG9uIGRyYWZ0LXJh anRhci1kaGMtdjRjb25maWd1cmF0aW9uLTAxCgpJIHRoaW5rIGNvbW1lbnRzIGFyZSBhbHdheXMg d2VsY29tZSA6KS4KCk9uZSBjb25jZXJuIEkgaGF2ZSAoV0cgY28tY2hhaXIgaGF0IG1vc3RseSBv ZmYpIHdpdGggdGhpcyB3aG9sZSBhcmVhIGlzIHRoYXQgSSBkb24ndCByZWFsbHkgaGF2ZSBhIGNs ZWFyIHNlbnNlIGZvciB3aGF0IGlzIHJlcXVpcmVkIG9mIHRoZSBwbGF5ZXJzIC0gb3BlcmF0b3Iv c2VydmljZSBwcm92aWRlciAoaW4gaXRzIG5ldHdvcmssIGZvciBpdHMgZGV2aWNlcykgYW5kIHdo YXQgaXMgcmVxdWlyZWQgYnkgdGhlIHN1YnNjcmliZXIgKGNsaWVudCBzaWRlKSBvciBPUyBwcm92 aWRlci4KCldoaWxlIEkgdW5kZXJzdGFuZCB0aGF0IHRoZXJlIG1heSBiZSBzaXR1YXRpb25zIHdo ZXJlIG9wZXJhdG9ycyBoYXZlIG5vIGNob2ljZSAoYmVjYXVzZSB0aGV5IGhhdmUgZmV3IElQdjQg YWRkcmVzc2VzKSwgYnV0IEkgdGhpbmsgaXQgaXMgaW1wb3J0YW50IGZvciB1cyB0byB1bmRlcnN0 YW5kIHdoYXQgdGhlIHRyYWRlb2ZmcyBhcmUgYXMgdGhlcmUgbWF5IGJlIHNvbWUgb3BlcmF0b3Jz IHRoYXQgd2lsbCBjb250aW51ZSB0byBwcmVmZXIgcHJvdmlkaW5nIElQdjQuCgpOb3RlIHRoYXQg dGhpcyBpc24ndCBuZWNlc3NhcmlseSBzb21ldGhpbmcgdGhhdCB0aGlzIHBhcnRpY3VsYXIgZHJh ZnQgaGFzIHRvIHByb3ZpZGUsIGJ1dCBpdCBtb3JlIG9mIGEgZ2VuZXJhbCBjb21tZW50IGZvciBh bGwgb2YgdGhlIGRyYWZ0cyBpbiB0aGlzIHNwYWNlLgoKLSBCZXJuaWUKCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tCkZyb206IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaGN3Zy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVG9tZWsgTXJ1Z2Fsc2tpClNlbnQ6IEZyaWRh eSwgRmVicnVhcnkgMjIsIDIwMTMgNDowNyBQTQpUbzogZGhjd2dAaWV0Zi5vcmcKU3ViamVjdDog W2RoY3dnXSBDb21tZW50cyBvbiBkcmFmdC1yYWp0YXItZGhjLXY0Y29uZmlndXJhdGlvbi0wMQoK T24gMTUuMDIuMjAxMyAxNToyNiwgVGVkIExlbW9uIHdyb3RlOgo+IFNvIEknZCBsaWtlIHRvIHBy b3Bvc2UgdGhhdCB3ZSBzdG9wIHRoZSBjYWxsIGZvciBhZG9wdGlvbiBvbiB0aGlzIAo+IHZlcnNp b24gb2YgdGhlIGRvY3VtZW50IG5vdywgYW5kIHRoYXQgdGhlIGF1dGhvcnMgcmVpc3N1ZSB0aGUg Cj4gZG9jdW1lbnQsIHdpdGhvdXQgdGhlIHJlY29tbWVuZGF0aW9uIHNlY3Rpb24sIGFuZCB3aXRo IHRoZSBhZGRpdGlvbiBvZiAKPiBSb2JlcnRhJ3MgYXJndW1lbnQgaW4gZmF2b3Igb2YgYSBESENQ djYtb25seSBzb2x1dGlvbiwgd2hpY2ggSSB0aGluayAKPiBjYXB0dXJlcyB0aGUgcmVhbCBpc3N1 ZSBiZXN0LgpXaGF0IGlzIHRoZSBwbGFuIHdpdGggdGhpcyB3b3JrPyBJIHN1cHBvc2UgaXQgd2ls bCBiZSBwcmVzZW50ZWQvZGlzY3Vzc2VkIGluIE9ybGFuZG8sIHVwZGF0ZWQgdmVyc2lvbiB3aWxs IGJlIHB1Ymxpc2hlZCBhbmQgc2Vjb25kIGFkb3B0aW9uIGNhbGwgd2lsbCBiZSBpc3N1ZWQ/CgpU ZWQgc2FpZCB0aGF0IHRoaXMgaXMgYWRvcHRpb24gdGhyZWFkLCBub3QgYSB0ZWNobmljYWwgY29t bWVudHMgdGhyZWFkLCBidXQgc2luY2UgdGhlIGFkb3B0aW9uIGNhbGwgd2FzIGNhbmNlbGxlZCwg SSBob3BlIGl0IGlzIG9rIHRvIHBvc3QgbXkgY29tbWVudHMgb24gaXQuCgpJIG5vdGVkIHRoYXQg LTAxIHZlcnNpb24gZG9lcyBub3QgaW5jbHVkZSBzcGVjaWZpYyBjb25jbHVzaW9uLCBtZXJlbHkg YSBub3RlIHRoYXQgdGhpcyBjb25jbHVzaW9uIHdpbGwgZW1lcmdlIGFzIGEgZ3JvdXAgY29uc2Vu c3VzLiBUaGlzIGlzIGEgc3RlcCBpbiByaWdodCBkaXJlY3Rpb24uIE15IHN1Z2dlc3Rpb24gZm9y IHRoZSB3b3JrIGZvcndhcmQgd291bGQgYmUgdG8gZGVjaWRlIHdoYXQgYXJlIHRoZSBjaGFuZ2Vz IG5lZWRlZCAoaWYgd2Ugd2FudCB0byBiZSBtb3JlIHNwZWNpZmljIGFib3V0IHJlcXVpcmVtZW50 cywgd2hhdCBpbnNpZGUgYW5kIHdoYXQgb3V0c2lkZSBvZiBzY29wZSwgd2hhdCB0aGUgY29uY2x1 c2lvbiBzaG91bGQgYmUpIGFuZCB0aGVuIGFkb3B0IGl0LCBub3QgdGhlIG90aGVyIHdheSBhcm91 bmQuIEF0IGZpcnN0LCB0aGlzIG1heSBiZSBjb3VudGVyLWludHVpdGl2ZSwgYnV0IHRoZXJlJ3Mg YSB2ZXJ5IGdvb2QgcmVhc29uIHRvIGRvIHRoaXMgaW4gdGhhdCBvcmRlci4gVGhlcmUgd2FzIChz dGlsbCBpcywgYnV0IGl0IHNlZW1zIHRvIGJlIGR5aW5nIHNsb3dseSBhbmQgYmVpbmcgcmV2aXZl ZCBjb25zdGFudGx5KSBhIGRyYWZ0IGFib3V0IERIQ1B2NiByb3V0aW5nIGNvbmZpZ3VyYXRpb24g aW4gTUlGIHdnLiBUaGUgZHJhZnQgd2FzIGFkb3B0ZWQgYSBsb25nIHRpbWUgYWdvLCBidXQgdGhl IGdyb3VwIGRpZG4ndCBoYXZlIGNvbnNlbnN1cyBob3cgaXQgcmVhbGx5IHNob3VsZCB3b3JrLiBU aGlzIGlzIGEgaG90IGNvbnRyb3ZlcnNpYWwgdG9waWMgd2l0aCBtYW55IHBhcnRpY2lwYW50cyBo YXZpbmcgc3Ryb25nIG9waW5pb25zLCBzaW1pbGFyIHRvIHdoYXQgd2UgaGF2ZSBoZXJlIHdpdGgg ZHJhZnQtcmFqdGFyLWRoYy12NGNvbmZpZ3VyYXRpb24uIElmIHlvdSBhdHRlbmQgTUlGIG1lZXRp bmdzLCB5b3UnbGwgbm90aWNlIHRoYXQgZGlzY3Vzc2lvbiBhYm91dCB0aGlzIHRha2VzIGEgc2ln bmlmaWNhbnQKICBhbW91bnQgb2YgdGltZSBvZiBldmVyeSBzaW5nbGUgTUlGIG1lZXRpbmcsIHdp dGhvdXQgbXVjaCB3b3JrIGdvaW5nIGZvcndhcmQuIEkgd291bGQgdmVyeSBtdWNoIGxpa2UgdG8g YXZvaWQgc2ltaWxhciBjYXNlIGluIERIQy4gVGhpcyBkcmFmdCBoYXMgc2ltaWxhciBwb3RlbnRp YWwgZm9yIGVuZGxlc3MgcHJvIGFuZCBjb25zIGRpc2N1c3Npb25zIGFzIHdhcyBkZW1vbnN0cmF0 ZWQgbWFueSB0aW1lcyBpbiBTb2Z0d2lyZXMuCgpJIGFncmVlIHdpdGggV29qJ3MgYW5kIE1lZCdz IGNvbW1lbnRzIGFib3V0IGEgbmVlZCB0byBkZWZpbmUgd2hhdCBhcmUgdGhlIHJlcXVpcmVtZW50 cyAob3IgcHJlZmVyZW5jZXMgYXMgVGVkIGNhbGxzIHNvbWUgb2YgdGhlbSkuIERlcGVuZGluZyBv biB0aGVtLCBzb21lIHByb3MvY29ucyBiZWNvbWUgdmVyeSBpbXBvcnRhbnQgb3Igbm90IGltcG9y dGFudCBhdCBhbGwuCgpPaywgaGVyZSBhcmUgbXkgY29tbWVudHMgc3BlY2lmaWMgdG8gdGhlIHRl eHQ6CgpJdCB3b3VsZCBiZSBoZWxwZnVsIHRvIGFkZCBhIHN0YWNrIGRlc2NyaXB0aW9uIGluIHNl Y3Rpb25zIDIuMSwgMi4yIGFuZAoyLjMgKG9tZXRoaW5nIGxpa2UgREhDUHY0L1VEUHY2L0lQdjYs IERIQ1B2Ni9VRFB2Ni9JUHY2LCBhbmQgREhDUHY0L1VEUHY0L0lQdjQvSVB2NikuCgpTZWN0aW9u IDIuMTogIlRoZSBESENQdjRvNiBzZXJ2ZXIgbmVlZHMgdG8gYmUgZXh0ZW5kZWQgdG8gc3VwcG9y dCB0aGUgbmV3IGZ1bmN0aW9uYWxpdHksIHN1Y2ggYXMgc3RvcmluZyB0aGUgSVB2NiBhZGRyZXNz IG9mIERIQ1B2NG82IGNsaWVudHMuIiBJcyB0aGlzIHJlYWxseSB0cnVlPyBNeSB1bmRlc3RhbmRp bmcgaXMgdGhhdCB0aGUgc2VydmVyIG5lZWRzIHRvIHJlbWVtYmVyCklQdjYgYWRkcmVzcyBvZiB0 aGUgc291cmNlIHBhY2tldCB0byByZXNwb25kIHRvIGl0LCBidXQgb25jZSB0aGUgcmVzcG9uc2Ug aXMgc2VudCB0aGVyZSBpcyBubyBuZWVkIHRvIHN0b3JlIGl0IGZ1cnRoZXIuCgpTZWN0aW9uIDIu MiBpcyBvdmVybHkgc2ltcGxpc3RpYy4gREhDUHY2IGJhc2VkIHByb3Zpc2lvbmluZyBhaW1zIHRv IHByb3ZpZGUgb25seSBiYXJlIG1pbmltdW0gdG8gY29uZmlndXJlIElQdjQgc3RhY2ssIG5vdCB0 aGUgd2hvbGUgbXVsdGl0dWRlIG9mIG9wdGlvbnMgdGhhdCBESENQdjQgaGFzLgoKU2VjdGlvbiAy LjIgcmVmZXJzIHRvIEktRC5tZHQtc29mdHdpcmUtbWFwLWRoY3Atb3B0aW9uLCB3aGljaCBpcyBv YnNvbGV0ZS4gSXQgd2FzIGFkb3B0ZWQgYXMgSS1ELnNvZnR3aXJlLW1hcC1kaGNwLgoKU2VjdGlv biAyLjMuIElzIHRoZXJlIGEgZHJhZnQgYXZhaWxhYmxlIHRoYXQgcHJvcG9zZXMgdGhhdCBhcmNo aXRlY3R1cmU/CgpTZWN0aW9uIDMuMS4xLCBidWxsZXQgMTogUmVtb3ZlIGV4dHJhICJiZSIuCgpJ dCBzaG91bGQgYmUgbWVudGlvbmVkIHRoYXQgdGhlcmUncyBleGlzdGluZyBzb2Z0d2FyZSB0aGF0 IHdhcyBwcm92ZW4gdG8gd29yayAob3RoZXIgcHJvL2NvbiBzZWN0aW9ucyBtZW50aW9uIGV4aXN0 ZW5jZSBvciBsYWNrIG9mIHN1aXRhYmxlIHNvZnR3YXJlKS4KClNlY3Rpb24gMy4xLjIsIGJ1bGxl dCAxOiBjYW4geW91IGVsYWJvcmF0ZT8gQ1JBIGlzIHRoZSBvbmx5IG5ldyBlbGVtZW50IHJlcXVp cmVkLiBZb3UgY2FuIGludGVncmF0ZSBpdCB3aXRoIGNsaWVudCBpZiB5b3Ugd2FudCB0byBtaW5p bWl6ZSBudW1iZXIgb2YgbmV3IGVsZW1lbnRzLgoKQnVsbGV0IDIgY291bGQgcG9zc2libHkgcmVm ZXJlbmNlCmRyYWZ0LW1ydWdhbHNraS1zb2Z0d2lyZS1kaGNwdjQtb3Zlci12Ni1vcHRpb24tMDEu CgpCdWxsZXQgMyAiREhDUHY0IGNsaWVudHMgbmVlZHMgdG8gYmUgdXBkYXRlZCB0byBpbXBsZW1l bnQgdGhlIElQdjYgZW5jYXBzdWxhdGlvbiBhbmQgZGVjYXBzdWxhdGlvbiBmdW5jdGlvbi4iIE15 IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBpdCBpcyBub3QgYWx3YXlzIHRydWUuIENSQSBjYW4gYmUg YSBzZXBhcmF0ZSBlbnRpdHksIHlvdSBkb24ndCBoYXZlIHRvIG1vZGlmeSBESENQdjQgY2xpZW50 IGNvZGUuCgpCdWxsZXQgNCAiVGhlIERIQ1B2NCBzZXJ2ZXIgbmVlZHMgdG8gYmUgdXBkYXRlZCB0 byBpbXBsZW1lbnQgbmV3CkRIQ1B2NG82IGZ1bmN0aW9uYWxpdHkuIi4gSSB0aGluayB0aGF0IGlz IG5vdCBhbHdheXMgdHJ1ZSwgYXMgeW91IGNhbiBkZXBsb3kgVHJhbnNwb3J0IFJlbGF5IEFnZW50 LCByaWdodD8KCllvdSBzaG91bGQgYWRkICJyZXF1aXJlcyBESENQdjQgc2VydmVyIHRvIGJlIGRl cGxveWVkIGFuZCBtYWludGFpbmVkIiB0byBjb25zLgoKU2VjdGlvbiAzLjIuMSBzaG91bGQgbWVu dGlvbiB0aGF0IHNvbWUgc29sdXRpb25zIChNQVAgZm9yIHN1cmUuIDRyZCB1c2VkIHRvLCBJJ20g bm90IHN1cmUgaWYgaXQgc3RpbGwgZG9lcykgcmV1c2UgcGFydHMgb2YgdGhlIElQdjYgY29uZmln dXJhdGlvbiAoZS5nLiBwYXJ0cyBvZiBQRCkgdG8gcHJvdmlkZSBJUHY0IGNvbmZpZ3VyYXRpb24u CgpTZWN0aW9uIDMuMi4yLCBidWxsZXQgMSBzdWdnZXN0cyB0aGF0IHRoZXJlIGFyZSBtYW55IERI Q1B2NCBvcHRpb25zIHRoYXQgd291bGQgbmVlZCB0byBiZSBwb3J0ZWQsIGJ1dCBpbiBmYWN0IHRo ZXJlIGFyZSBmZXcgKG9yIGV2ZW4gbm9uZSkgaW4gbW9zdCBjYXNlcy4KCkkgYXNzdW1lIHRoYXQg YnVsbGV0IDIgZGlzY3Vzc2VzIGEgbmV3IERIQ1B2NiBvcHRpb25zIHRoYXQgYXJlIHVzZWQgdG8g Y29uZmlndXJlIElQdjQgdHJhbnNpdGlvbiB0ZWNobm9sb2d5LCBlLmcuIE1BUC4gSXQgcmFpc2Vz IGFuIGludGVyZXN0aW5nIHBvaW50LCB3aGljaCBpcyBjb25zaWRlcmVkIGEgc3Ryb25nIGFyZ3Vt ZW50IGFnYWluc3QgdGhhdCBzb2x1dGlvbi4gSGVyZSdzIGFuIGlkZWEgdG8gY29uc2lkZXIgdGhh dCBjb3VsZCBsYXJnZWx5IG1pdGlnYXRlIGl0LiBXZSBjb3VsZCBkZWZpbmUgYSBzcGVjaWFsIHJh bmdlIGluIERIQ1B2NiBvcHRpb24gc3BhY2UgcmVzZXJ2ZWQgZm9yIHRyYW5zaXRpb24gdGVjaG5v bG9naWVzLCBzaW1pbGFyIHRvIHdoYXQgd2UgaGF2ZSBpbiBESENQdjQgb3B0aW9uIHNwYWNlIGZv ciByZXNlcnZlZCBvciBwcml2YXRlIHVzZS4gQW55IERIQ1B2NiBvcHRpb25zIHRoYXQgd291bGQg YmVjb21lIHVzZWxlc3MgYWZ0ZXIgSVB2NCBnb2VzIGF3YXksIHdvdWxkIGJlIGFzc2lnbmVkIGZy b20gdGhhdCByYW5nZS4gT25jZSBhIHZlbmRvciB3YW50cyB0byBnbyBJUHY2LW9ubHksIGl0J3Mg anVzdCBhIG1hdHRlciBvZiBub3Qgc3VwcG9ydGluZyBzcGVjaWZpYyByYW5nZSBvZiBvcHRpb25z LgoKQnVsbGV0IDM6IEknbSBub3Qgc3VyZSB3aGVyZSBkaWQgeW91IGdldCB0aGUgaWRlYSB0aGF0 IERIQ1B2NCBsZWdhY3kgb3B0aW9ucyB3b3VsZCBiZSBwb3J0ZWQgdG8gREhDUHY2PyBTdWNoIGEg dGhpbmcgaXMgdW5yZWFzb25hYmxlIHRvIHNheSB0aGUgbGVhc3QuIENhbiB5b3UgcG9pbnQgb3V0 IHNwZWNpZmljIGRyYWZ0IG9yIGNvbW1lbnQgdGhhdCBzdWdnZXN0ZWQgdGhhdD8KClNlY3Rpb24g My4zLjEKIlVzZXMgdGhlIGV4aXN0aW5nIERIQ1B2NCBhbmQgREhDUHY2IGFyY2hpdGVjdHVyZXMg aW4gb3JkZXIgdG8gcHJvdmlkZQpJUHY0IGNvbmZpZ3VyYXRpb24gaW4gYW4gSVB2NiBvbmx5IGVu dmlyb25tZW50LiIuIElmIHlvdSByZXdvcmQgdG8gInJlcXVpcmVzLi4uIiBpbnN0ZWFkIG9mICJ1 c2VzLi4uIiwgaXQgc3VkZGVubHkgbWF5IGJlIGNvbnNpZGVyZWQgYSBjb24gaW4gbWFueSBkZXBs b3ltZW50cyB0aGF0IGRvIG5vdCBoYXZlIERIQ1B2NCBkZXBsb3llZC4KClNlY3Rpb24gMy4zLjIs IGJ1bGxldCA0IG1lbnRpb25zIGlldGYtZGhjLWRoY3BpbmZvcm0tY2xhcmlmeS4gVGhpcyBkcmFm dCBpcyBkZWFkIGZvciBvdmVyIDIgeWVhcnMgYW5kIERhdmlkLCBpdHMgYXV0aG9yLCBpcyB1bmxp a2VseSB0byByZXZpdmUgaXQuCgpZb3Ugc2hvdWxkIGFkZCAicmVxdWlyZXMgREhDUHY0IHNlcnZl ciB0byBiZSBkZXBsb3llZCBhbmQgbWFpbnRhaW5lZCIgdG8gY29ucy4KCllvdSBzaG91bGQgYWRk ICJubyBleGlzdGluZyBzb2Z0d2FyZSBhdmFpbGFibGUgeWV0IiB0byBjb25zLgoKTXkgcGVyc29u YWwgb2JzZXJ2YXRpb24gaXMgdGhhdCB0aGlzIGlzIG5vdCBhIGNvbXBsZXRlbHkgc29sdmFibGUg cHJvYmxlbSBhbmQgdGhlcmUgd29uJ3QgYmUgYSBzaW5nbGUgY29uY2x1c2lvbiwgbGlrZSAidXNl IERIQ1B2NCIgb3IgInVzZSBESENQdjYiIHRoYXQgd291bGQgc2F0aXNmeSBldmVyeW9uZSAob3Ig YXQgbGVhc3QgYSBsYXJnZSBtYWpvcml0eSkuCkkgdGhpbmsgdGhlIHdheSBmb3J3YXJkIGhlcmUg d291bGQgYmUgdG8gZG8gc29tZXRoaW5nIHNpbWlsYXIgYXMgd2UgZGlkIGluIGRoYy1vcHRpb24t Z3VpZGVsaW5lczogZGVmaW5lIGEgc2V0IG9mIGd1aWRlbGluZXMsIG5vdCAieW91IG11c3QgYWx3 YXlzIHVzZSBYIi4KCkhvcGUgdGhhdCBoZWxwcywKVG9tZWsKCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCmRoY3dnIG1haWxpbmcgbGlzdApkaGN3Z0BpZXRm Lm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRoY3dnIG1haWxpbmcgbGlz dApkaGN3Z0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Ro Y3dnCgoKPEhUTUw+PFA+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jOTk5OTk5IHNpemU9MT4NCg0K SVpKQVZBIE8gT0RSSUNBTkpVIE9ER09WT1JOT1NUSTogU2FkcsW+YWogb3ZlIHBvcnVrZSBpIGV2 ZW50dWFsbm8gcHJpbG/FvmVuaWggZGF0b3Rla2EgamUgcG92amVybGppdiBpIG5hbWlqZW5qZW4g amUgc2FtbyBvc29iYW1hIGlsaSBzdWJqZWt0aW1hIGtvamkgc3UgbmF2ZWRlbmkgdSBhZHJlc2ku IFVrb2xpa28gc3RlIHByaW1pbGkgb3Z1IHBvcnVrdSBncmXFoWtvbSwgbW9saW1vIFZhcywgb2Jh dmlqZXN0aXRlIHBvxaFpbGphdGVsamEsIGEgcG9ydWt1IGkgc3ZlIG5qZW5lIHByaXZpdGtlIG9k bWFoLCBiZXogxI1pdGFuamEsIHRyYWpubyB1a2xvbml0ZSBzIHJhxI11bmFsYS4gQmlsbyBrYWt2 byBwcmVub8WhZW5qZSwga29waXJhbmplIGlsaSBkaXN0cmlidWNpamEgaW5mb3JtYWNpamEgc2Fk csW+YW5paCB1IHBvcnVjaSB0cmXEh2ltIG9zb2JhbWEgamUgemFicmFuamVubyBpIG1vxb5lIGJp dGkgemFrb25za2kga2HFvm5qaXZvLiBTYWRyxb5haiwgc3Rhdm92aSBpIG1pxaFsamVuamEgaXpu ZXNlbmkgdSBwb3J1Y2kgc3UgYXV0b3JvdmkgaSBuZSBwcmVkc3RhdmxqYWp1IG51xb5ubyBzdGF2 b3ZlIEhUIC0gSHJ2YXRza2loIHRlbGVrb211bmlrYWNpamEgZC5kLiBIVCBuZSBwcmlodmHEh2Eg bmlrYWt2dSBvZGdvdm9ybm9zdCB6YSBldmVudHVhbG51IMWhdGV0dSBuYXN0YWx1IHByaW1pdGtv bSBvdmUgcG9ydWtlIGkgcHJpbG9nYSBzYWRyxb5hbmloIHUgcG9ydWNpLg0KDQo8L0ZPTlQ+PC9Q PjxQPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Izk5OTk5OSBzaXplPTE+DQoNCiBESVNDTEFJTUVS OlRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFzIHdlbGwgYXMgYW55IGZpbGVzIGF0dGFjaGVk IHRvIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgaW5kaXZpZHVh bHMgb3IgZW50aXRpZXMgd2hpY2ggdGhleSBhcmUgYWRkcmVzc2VkIHRvLiBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBhbmQgcGVybWFuZW50bHkgcmVtb3ZlIHRoZSBtZXNzYWdlIGFuZCBhbGwgYXR0YWNoZWQg ZmlsZXMgZnJvbSB0aGUgY29tcHV0ZXIuIEFueSBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIGRpc3Ry aWJ1dGlvbiBvZiBhbGwgb3IgYSBwYXJ0IG9mIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4g dG8gb3IgYnkgdGhpcmQgcGFydGllcyBpcyBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwu IFBsZWFzZSBub3RlIHRoYXQgYW55IHZpZXdzIG9yIG9waW5pb25zIHByZXNlbnRlZCBpbiB0aGlz IG1lc3NhZ2UgYXJlIHNvbGVseSB0aG9zZSBvZiB0aGUgYXV0aG9yIGFuZCBkbyBub3QgbmVjZXNz YXJpbHkgcmVwcmVzZW50IHRoZSB2aWV3cyBhbmQgb3BpbmlvbnMgb2YgQ3JvYXRpYW4gVGVsZWNv bSBJbmMuIENyb2F0aWFuIFRlbGVjb20gSW5jLiBhY2NlcHRzIG5vIGxpYWJpbGl0eSBmb3IgYW55 IHBvdGVudGlhbCBkYW1hZ2UgY2F1c2VkIGJ5IHRoaXMgbWVzc2FnZSBhbmQgZmlsZXMgYXR0YWNo ZWQgdG8gaXQuDQoNCjwvRk9OVD48L1A+PC9IVE1MPgo= From akostur@incognito.com Mon Feb 25 09:32:42 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A95D21E8037 for ; Mon, 25 Feb 2013 09:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKhiWgE3YBg1 for ; Mon, 25 Feb 2013 09:32:41 -0800 (PST) Received: from na3sys010aog106.obsmtp.com (na3sys010aog106.obsmtp.com [74.125.245.80]) by ietfa.amsl.com (Postfix) with SMTP id 8EBB921E8034 for ; Mon, 25 Feb 2013 09:32:40 -0800 (PST) Received: from mail-gg0-f198.google.com ([209.85.161.198]) (using TLSv1) by na3sys010aob106.postini.com ([74.125.244.12]) with SMTP ID DSNKUSugOHNcFk+e2MTt3FTy62FctmCauZwR@postini.com; Mon, 25 Feb 2013 09:32:41 PST Received: by mail-gg0-f198.google.com with SMTP id a5so4762289ggn.1 for ; Mon, 25 Feb 2013 09:32:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=hIIWehGNqj5ylidUNJA5WDhTg05kCnFK8LBKk+6nbXY=; b=JwLtXNcrHZVAUKnmVRpYiDvsHjeRYXGqRRRJzViIxshwlMYa3R8ITCZ+vDrbTVrDrs 97ihWiX4nkkkyIYQkBV6g3oqYp7TZt5sGr1RGzyx3KZB7bphtCiX7MfgfAi8q7DIW4W4 ahlvndE2IrVMn9nbf/IwIkdM05RSOi4FUsvniDNMygQqWTfR8l70EPKiC2yZBSce+Y7A Xce8xBXgnjxc6lPq86mdv9RJW6rsRGKhUIPFOyDErXbRRnEdyoEXfYI1XP6XOWEVcbMV JP7Geoc2TFb1btZjCznAt9mJJfunejbBM/x1MKD99ITHyv0CuoowTLjRiwcLRolmXdrk 8RkA== X-Received: by 10.52.65.147 with SMTP id x19mr9065166vds.27.1361813559853; Mon, 25 Feb 2013 09:32:39 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.52.65.147 with SMTP id x19mr9065163vds.27.1361813559766; Mon, 25 Feb 2013 09:32:39 -0800 (PST) Received: by 10.220.124.69 with HTTP; Mon, 25 Feb 2013 09:32:39 -0800 (PST) In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB22E6F6FF@xmb-aln-x06.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E1847C264@xmb-rcd-x04.cisco.com> <90903C21C73202418A48BFBE80AEE5EB22E6F6FF@xmb-aln-x06.cisco.com> Date: Mon, 25 Feb 2013 09:32:39 -0800 Message-ID: From: Andre Kostur To: "Gaurav Halwasia (ghalwasi)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmupxlp4uI8X4clBohlfZSbkD/8gTodT2bTFiArc5d5CgQXjyyMTEbRS9sXBJue0adJlVxZR1PbWyaslFMKKb8fpP/x1gfH4nQZsWOBJ6TOyna2rixtv1X5eIATDHCEJlpNFcBLsDWqjXjuJpo+9LaW77trIQ== Cc: "dhcwg@ietf.org WG" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Reminder - WGLC: draft-ietf-dhc-triggered-reconfigure-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, 25 Feb 2013 17:32:42 -0000 I support this draft. -- Andre Kostur From internet-drafts@ietf.org Mon Feb 25 10:09:19 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF42921E8098; Mon, 25 Feb 2013 10:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bADqnfjxy1kO; Mon, 25 Feb 2013 10:09:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D579B21E808F; Mon, 25 Feb 2013 10:09:18 -0800 (PST) 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.40 Message-ID: <20130225180918.19119.6324.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 10:09:18 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-option-guidelines-10.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, 25 Feb 2013 18:09:19 -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 : Guidelines for Creating New DHCPv6 Options Author(s) : David W. Hankins Tomasz Mrugalski Marcin Siodelski Sheng Jiang Suresh Krishnan Filename : draft-ietf-dhc-option-guidelines-10.txt Pages : 21 Date : 2013-02-25 Abstract: This document provides guidance to prospective DHCPv6 Option developers to help them creating option formats that are easily adoptable by existing DHCPv6 software. This document updates RFC3315. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-option-guidelines-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tomasz.mrugalski@gmail.com Mon Feb 25 14:01:43 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B34421E80E0 for ; Mon, 25 Feb 2013 14:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.333 X-Spam-Level: X-Spam-Status: No, score=-3.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9TVjJnNCUXJ for ; Mon, 25 Feb 2013 14:01:42 -0800 (PST) Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by ietfa.amsl.com (Postfix) with ESMTP id 591EF21E8096 for ; Mon, 25 Feb 2013 14:01:42 -0800 (PST) Received: by mail-ee0-f53.google.com with SMTP id e53so1779458eek.40 for ; Mon, 25 Feb 2013 14:01:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=fBne1PpGkmGDjhuqYAI3iLfYYB/0aEe9DJtqakOkDu4=; b=vKWWlCi+AYmv6KI6KKYq+LUQ6yYTwFBNPOhf9DGTAReEcmMySfVIqKp8jMYN4stKt9 rDutxClPhSTyvewMD6Qx4CZ8H9aEhQ1ho8bluquwUvroi4vIwnI+EAx91vr6CJvOxM9X KRq4n1erNrnd2+sj6my5RYPCdhUER996qj3rJbqsncpGhthn+9KQZ9STn4aUaeMctZU2 IV2u0JfqPzS1IBYJH8dpYY2fp1sH/pDymKCd+o1Kp1ZFZUrkavMejC+0la/nDR93tYNP Y5kJw2bLxfDBb4Tk7JihuTq+ufC2vJ+RCqU+7IyP8h7Y0LlzL3ka8JIZRa0Yb41aKLbh m7rA== X-Received: by 10.14.216.198 with SMTP id g46mr42846464eep.30.1361829701331; Mon, 25 Feb 2013 14:01:41 -0800 (PST) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id a1sm20483525eep.2.2013.02.25.14.01.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Feb 2013 14:01:40 -0800 (PST) Message-ID: <512BDF3E.3030902@gmail.com> Date: Mon, 25 Feb 2013 23:01:34 +0100 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: dhcwg@ietf.org References: <489D13FBFA9B3E41812EA89F188F018E1847C264@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1847C264@xmb-rcd-x04.cisco.com> X-TagToolbar-Keys: D20130225230134757 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] Reminder - WGLC: draft-ietf-dhc-triggered-reconfigure-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, 25 Feb 2013 22:01:43 -0000 On 25.02.2013 04:58, Bernie Volz (volz) wrote: > Just a reminder that this WGLC is coming to a close (Feb 28) and I > believe there's only been one response so far. I support this work and would like it to move forward. I have some comments on it though. Figure 1 could be updated. The example used in exchange between NAS and Radius server is DS-Lite-Tunnel-Name. I assume that is Radius name of the option for DS-Lite. That is ok. That name is then used in Relay-Forward using that same name. It should be OPTION_AFTR_NAME (DHCPv6 name, not Radius name). It should also be mentioned in Relay-Reply "includes Advertise that includes OPTION_AFTR_NAME" or similar. Otherwise it is difficult to understand how relay gets that option. Figure 1 mentions NAS, without explaining what it means. I presume that it is Network Access Server, but it is not a common term in DHCP world, so it would be good to explain it. Section 2: "Reconfigure message is then sent to the DHCPv6 relay, which in turn will forward the message to the appropriate DHCPv6 client." This reconfigure message will be sent encapsulated in Relay-Reply, so it will look like every other message received from a server and to be processed by the relay, right? There's no text that clarifies that. Last paragraph is section 2 talks about retransmissions, but do not explain how to conduct them if there is no server response. It should point out that the details are explained in section 4.3. Section 4.2.1: "Clients MUST silently discard any received RECONFIGURE-REQUEST messages.". I would add that logging such an event is allowed, though. "The server MUST be configurable to accept or reject RECONFIGURE- REQUEST messages." This should probably be moved to "Server behavior" section. Also, you should specify what is the server default if not explicitly configured. It should be reject in my opinion. "The relay agent MUST be configurable to accept or reject RECONFIGURE- REQUEST messages received from other relay agents.". Reconfigure-Request is not addressed at relay and it merely helps deliver it to server, so instead of "accept or reject" I would use "forward or drop" here. There should be a separate "Relay behavior" section and second to last paragraph in 4.2.1 should be moved to it. There are very good reasons for having separate behavior sections for server, relays and client There should be one for client as well, even if it contains only one sentence about dropping those messages. It makes life of implementors much easier and increases chances of wider adoption of that proposal. The last paragraph in 4.2.1 belongs more in the Server behavior section. Section 4.3 "The relay may receive (Relay-Reply) Reconfigure before..." is awkward. It should be "The relay may receive Reconfigure encapsulated in Relay-Reply before..." "The relay agent MUST include a Client Identifier Option..." => "The relay agent MUST include one or more Client Identifier Options..." Section 4.4 "Upon receipt of a valid Reconfigure-Request message from a DHCPv6 relay agent (see Section 4.2), the server determines the client(s) for which a Reconfigure message is to be sent.". Section 4.4, bullet 2 and 3 contradict each other. When relay requested reconfigure for 2 clients and one succeeds and the other fails, what should be the return status: success or failure code? What if the failure reasons are different for each client? It seems that the status code returning is not very useful for more than one client. Section 4.4, bullet 2 says that server must keep list of client-ids that it couldn't configure, but does not explain what to do with that list. Did you mean "include in reconfigure-ack"? If that is so, please rephrase that sentence. If you meant something else, please clarify as well. Section 7. You should change the text to say that servers MUST discard configure-request unless explicitly configured to accept them (or perhaps this should go into server behavior section). It's better to be safe than sorry. Although DUIDs are typically 14 bytes long, the maximum allowed length is 128, so we can hit fragementation limit with only 10 clients. There should be a short clarification that relay should send separate reconfigure-requests if there are more clients (or some other suggestion what to do if the MTU limit is hit). Reconfigure mechanism is optional. What should the server do if client does not support Reconfigure? There's currently no way for server to signal that to back to relay. UnspecFail doesn't look right. Perhaps NotConfigured would be the right code for it? Excuse my poor understanding of how NAS works, but does it keep DUIDs of all clients connected through it? So from the pure DHCP perspective, this is a stateful relay, right? If that is so, it should be pointed somewhere that the way relay keeps the information about clients is outside of scope for this document. Other than those comments, this draft is in a good shape and I support this work moving forward. Tomek From volz@cisco.com Mon Feb 25 19:00:04 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF6021F9576 for ; Mon, 25 Feb 2013 19:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wo9mjY8J7Te9 for ; Mon, 25 Feb 2013 19:00:04 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 22EEF21F9571 for ; Mon, 25 Feb 2013 19:00:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2326; q=dns/txt; s=iport; t=1361847604; x=1363057204; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=q3hzfSyz1GNZBW2GeD5B9OEzS2wN/QF+zBzvS0N7iYk=; b=UakbydH2QQ5JrpHkGypIJ0L7NoSrTMoYN7cbbNhZ8klUe47KIGJjJUX9 5gkgOewRa2cpSdNCmRbW+vR7LO8XgOfQ9qA9F0xqjqr9KzpfuCzjeatAD r6UH4U6KvajLgJR9Kz+mpvoS21Gglr7I2TlTIJGebY6ndhyVpujEb97gK o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABAkLFGtJV2Z/2dsb2JhbABFwV+BBRZzgh8BAQEEAQEBNzQLDAQCAQgRBAEBCxQJBycLFAkIAgQOBQiICwywBpAFjl0mCwcGgllhA5daj0iCeg2CJw X-IronPort-AV: E=Sophos;i="4.84,736,1355097600"; d="scan'208";a="180886580" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 26 Feb 2013 03:00:03 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1Q3032A020390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Feb 2013 03:00:03 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 21:00:03 -0600 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org WG" Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-08 Thread-Index: AQHOAi8Y6L/mEtMT5UW0fdfJAZ+WqJiLk1wQ Date: Tue, 26 Feb 2013 03:00:03 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1847EE3A@xmb-rcd-x04.cisco.com> References: <8D23D4052ABE7A4490E77B1A012B63074747BF6B@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074747BF6B@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Dhc Chairs \(dhc-chairs@tools.ietf.org\)" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 03:00:05 -0000 Ted and I have determined that there is sufficient consensus within the DHC= WG to move this document forward. The current version is -09 which had a minor typo fixed. While there wasn't an overwhelming response to this latest DHC WG last call= , it has had substantial support both in meetings and in previous messages = on the list and it closely mirrors what is available in DHCPv4 (RFC 4014). I expect to start the process to move it forward shortly. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Sunday, February 03, 2013 11:54 AM To: dhcwg@ietf.org WG Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-08 The authors of this draft have asked for a new working group last call. We= had a WGLC in November, and there were substantial and constructive commen= ts, which are incorporated in the new version. The changes can be seen he= re:=20 http://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-dhc-dhcpv6-radius-opt-05.tx= t&url2=3Ddraft-ietf-dhc-dhcpv6-radius-opt-08.txt This diff includes a number of changes that have occurred since the most re= cent last call-there have been several revisions of the draft. If you haven't read the draft, now would be a good time to do so: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-08 If you think the draft is ready to advance, please indicate your support on= the mailing list. If you think it is not ready, please say so as well. = And of course, additional comments are solicited and welcome. We will ev= aluate consensus on or after February 19. P.S. I asked Leaf to remove me as an author of the draft, because I haven't= actually contributed anything substantial to it, and working group chairs = authoring drafts create various procedural problems. If anybody feels tha= t this is inappropriate, please say so. As a working group participant, I= think the draft is a reasonably good idea, but I have no personal stake in= the advancement or non-advancement of the draft-it doesn't actually relate= to work I do outside of IETF, nor does my IETF work depend on it. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Mon Feb 25 19:12:36 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2240721E80D9 for ; Mon, 25 Feb 2013 19:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.519 X-Spam-Level: X-Spam-Status: No, score=-10.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQ74lMgMk7NK for ; Mon, 25 Feb 2013 19:12:34 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3A521F95A4 for ; Mon, 25 Feb 2013 19:12:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1296; q=dns/txt; s=iport; t=1361848347; x=1363057947; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lOzPs+39/g0jXE81XCW3TgNn1l6GUZDYnT6RYYFhIng=; b=YIgDZsaAONWM468Ywq2uqBPZKlHtYhcUZQ6xGw0sUsZCa1fs2VC4lyk1 fwpMDt3cKQKg6mn0VL2JMo1YYpZyTVy6N3o/a9Uiq0BUii+9h0VO+kvRM q00LxG4VUocdaMTgrhZ7Euw93DG+oNIS82dfkBWeYSKy+MVniu1qUN1ED w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJ8mLFGtJV2b/2dsb2JhbABFwV+BAxZzgh8BAQEEAQEBGh00CwwEAgEIEQQBAQsUCQcnCxQJCAIEDgUIiAsMsA2QAgSOXSYLBwaCWWEDpyKCeg2CJw X-IronPort-AV: E=Sophos;i="4.84,736,1355097600"; d="scan'208";a="181100821" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 26 Feb 2013 03:12:27 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1Q3CQ9M010758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Feb 2013 03:12:26 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 21:12:26 -0600 From: "Bernie Volz (volz)" To: " WG" Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-load-balancing-00 Thread-Index: AQHOAC9e6WOKq1UT9UyI5dVQpbv8HpiLnDvg Date: Tue, 26 Feb 2013 03:12:25 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1847EECF@xmb-rcd-x04.cisco.com> References: <8D23D4052ABE7A4490E77B1A012B6307474782A7@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474782A7@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Dhc Chairs \(dhc-chairs@tools.ietf.org\)" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-load-balancing-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: Tue, 26 Feb 2013 03:12:36 -0000 Ted and I have determined that there is sufficient consensus within the DHC= WG to move this document forward. In favor were Ted Lemon, Andre Kostur (author), Bernie Volz, Tina Tsou, 'pe= rl-list', and Gaurav Halwasia. And no one objected. I expect to start the process to move it forward shortly. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Thursday, January 31, 2013 10:51 PM To: WG Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-load-balancing-00 This document got significant attention during the call for adoption. The= author feels it is ready to publish and have asked for a last call. The = document describes a load balancing algorithm for DHCPv6, similar to the on= e described in RFC3074 for DHCPv4. Please review the document if you haven't already. If you are in favor of= publishing the document, please say so on the mailing list. If you oppos= e publication of the document, please also say so. If you have comments, = please raise them on the mailing list. We will evaluate consensus on February 14. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From mohamed.boucadair@orange.com Tue Feb 26 01:34:25 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC9C21F89AA for ; Tue, 26 Feb 2013 01:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id En4-+BtTpwXp for ; Tue, 26 Feb 2013 01:34:24 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E0BE721F89A6 for ; Tue, 26 Feb 2013 01:34:23 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 5CA28324534; Tue, 26 Feb 2013 10:34:22 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 400454C07D; Tue, 26 Feb 2013 10:34:22 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Tue, 26 Feb 2013 10:34:21 +0100 From: To: Tomek Mrugalski , "dhcwg@ietf.org" Date: Tue, 26 Feb 2013 10:34:21 +0100 Thread-Topic: [dhcwg] Reminder - WGLC: draft-ietf-dhc-triggered-reconfigure-03 Thread-Index: Ac4To7U7gfGbTjfSQxSiL+KAnP+AxQATmaFQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EB3C83288@PUEXCB1B.nanterre.francetelecom.fr> References: <489D13FBFA9B3E41812EA89F188F018E1847C264@xmb-rcd-x04.cisco.com> <512BDF3E.3030902@gmail.com> In-Reply-To: <512BDF3E.3030902@gmail.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: 2013.2.19.124517 Subject: Re: [dhcwg] Reminder - WGLC: draft-ietf-dhc-triggered-reconfigure-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, 26 Feb 2013 09:34:25 -0000 Hi Tomek, Many thanks for the detailed review.=20 Please see inline. Cheers, Med=20 >-----Message d'origine----- >De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De=20 >la part de Tomek Mrugalski >Envoy=E9 : lundi 25 f=E9vrier 2013 23:02 >=C0 : dhcwg@ietf.org >Objet : Re: [dhcwg] Reminder - WGLC:=20 >draft-ietf-dhc-triggered-reconfigure-03 > >On 25.02.2013 04:58, Bernie Volz (volz) wrote: >> Just a reminder that this WGLC is coming to a close (Feb 28) and I >> believe there's only been one response so far. >I support this work and would like it to move forward. > >I have some comments on it though. > >Figure 1 could be updated. The example used in exchange between NAS and >Radius server is DS-Lite-Tunnel-Name. I assume that is Radius name of >the option for DS-Lite. That is ok. That name is then used in >Relay-Forward using that same name. It should be OPTION_AFTR_NAME >(DHCPv6 name, not Radius name). It should also be mentioned in=20 >Relay-Reply >"includes Advertise that includes OPTION_AFTR_NAME" or similar. >Otherwise it is difficult to understand how relay gets that option. Med: Thanks for catching this. The figure is now updated.=20 > >Figure 1 mentions NAS, without explaining what it means. I presume that >it is Network Access Server, but it is not a common term in DHCP world, >so it would be good to explain it. Med: I added this sentence:=20 "Figure 1 shows a broadband network scenario in which the Network Access Se= rver (NAS) embeds a DHCPv6 relay agent." Do you think the document needs to say more? > >Section 2: "Reconfigure message is then sent to the DHCPv6 relay, which >in turn will forward the message to the appropriate DHCPv6=20 >client." This >reconfigure message will be sent encapsulated in Relay-Reply,=20 >so it will >look like every other message received from a server and to be=20 >processed >by the relay, right? There's no text that clarifies that. Med: I added this sentence just after the one you quoted:=20 "Note, the server encapsulates the Reconfigure message in a Relay-reply mes= sage." Better? > >Last paragraph is section 2 talks about retransmissions, but do not >explain how to conduct them if there is no server response. It should >point out that the details are explained in section 4.3. Med: The text is now updated to call out Section 4.3.=20 > >Section 4.2.1: "Clients MUST silently discard any received >RECONFIGURE-REQUEST messages.". I would add that logging such an event >is allowed, though. Med: Is there any value to log such events in the client side? > >"The server MUST be configurable to accept or reject RECONFIGURE- >REQUEST messages." This should probably be moved to "Server behavior" >section.=20 Med: Ok for me. Done. Also, you should specify what is the server default if not >explicitly configured. It should be reject in my opinion. Med: I added this sentence:=20 "If no indication is explicitly configured to the server, the default behav= iour is to reject RECONFIGURE-REQUEST messages." > >"The relay agent MUST be configurable to accept or reject RECONFIGURE- >REQUEST messages received from other relay agents.".=20 >Reconfigure-Request >is not addressed at relay and it merely helps deliver it to server, so >instead of "accept or reject" I would use "forward or drop" here. Med: I do think both wording would work. "accept" is more generic as forwar= ding the message will be the result of other steps than just accept handlin= g the message. I will maintain the initial wording.=20 > >There should be a separate "Relay behavior" section and second to last >paragraph in 4.2.1 should be moved to it. Med: I added a new section called "Intermediate Relay Agents Behaviour" and= moved that text to the new section. There are very good reasons >for having separate behavior sections for server, relays and client >There should be one for client as well, even if it contains only one >sentence about dropping those messages. It makes life of implementors >much easier and increases chances of wider adoption of that proposal. > >The last paragraph in 4.2.1 belongs more in the Server=20 >behavior section. Med: Agree. > >Section 4.3 "The relay may receive (Relay-Reply) Reconfigure before..." >is awkward. It should be "The relay may receive Reconfigure=20 >encapsulated >in Relay-Reply before..." Med: Fixed. Thanks. > >"The relay agent MUST include a Client Identifier Option..." =3D> "The >relay agent MUST include one or more Client Identifier Options..." Med: Fixed.=20 > >Section 4.4 "Upon receipt of a valid Reconfigure-Request message from a >DHCPv6 relay agent (see Section 4.2), the server determines the >client(s) for which a Reconfigure message is to be sent.". > >Section 4.4, bullet 2 and 3 contradict each other. When relay requested >reconfigure for 2 clients and one succeeds and the other fails, what >should be the return status: success or failure code? Med: bullet 2 is about partial failure (i.e., there is at least a success f= or one client); bullet 3 is when there is failure for all clients. In the p= artial failure case, the list of failed cio are returned also in the Reconf= igure-Ack. What if the >failure reasons are different for each client? It seems that the status >code returning is not very useful for more than one client. > >Section 4.4, bullet 2 says that server must keep list of=20 >client-ids that >it couldn't configure, but does not explain what to do with that list. >Did you mean "include in reconfigure-ack"? If that is so, please >rephrase that sentence. If you meant something else, please=20 >clarify as well. Med: The text is about Reconfigure-Ack. I fixed the text. > >Section 7. You should change the text to say that servers MUST discard >configure-request unless explicitly configured to accept them (or >perhaps this should go into server behavior section). It's better to be >safe than sorry. Med: discarding RECONFIGURE-REQUEST messages + configuration options are al= ready covered in the server behaviour. I prefer > >Although DUIDs are typically 14 bytes long, the maximum allowed length >is 128, so we can hit fragementation limit with only 10 clients. There >should be a short clarification that relay should send separate >reconfigure-requests if there are more clients (or some other=20 >suggestion >what to do if the MTU limit is hit). Med: Isn't this covered in the text of Section 4.3:=20 If including Client Identifier Options of all impacted clients exceeds the maximum message size (see Section 5), the relay MUST generate several RECONFIGURE-REQUEST messages required to carry all Client Identifier Options. Rate-limit considerations are discussed in Section 5. > >Reconfigure mechanism is optional. What should the server do if client >does not support Reconfigure? There's currently no way for server to >signal that to back to relay. UnspecFail doesn't look right. Perhaps >NotConfigured would be the right code for it? Med: If we need to specific, a new error code need to be defined for this c= ase. If you think there is a value in specifying that behaviour, I suggest = we define a new error code for it. =20 > >Excuse my poor understanding of how NAS works, but does it=20 >keep DUIDs of >all clients connected through it? So from the pure DHCP perspective, >this is a stateful relay, right? If that is so, it should be pointed >somewhere that the way relay keeps the information about clients is >outside of scope for this document. Med: Section 2 says:=20 This setup assumes the relay has a record of the client, so that it has enough information to send the Reconfigure-Request message to the server. Means to recover state in failure events must be supported, but are not discussed in this document. I propose to change it to=20 This setup assumes the relay has a record of the client, so that it has enough information to send the Reconfigure-Request message to the server. How the state is recorded in the relay is out of scope. Furtherm= ore, means to recover state in failure events must be supported, but are not discussed in this document. > >Other than those comments, this draft is in a good shape and I support >this work moving forward. Med: Thanks. > >Tomek >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg >= From tomasz.mrugalski@gmail.com Tue Feb 26 02:56:54 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE41521F88E6 for ; Tue, 26 Feb 2013 02:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.366 X-Spam-Level: X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKyN+PXDoA-v for ; Tue, 26 Feb 2013 02:56:53 -0800 (PST) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6176021F895F for ; Tue, 26 Feb 2013 02:56:53 -0800 (PST) Received: by mail-ee0-f48.google.com with SMTP id t10so2218636eei.35 for ; Tue, 26 Feb 2013 02:56:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=XPJ9q362ta8LY3PQolbG9wF3gsshlRM8jmUCttWuO5M=; b=T/fHK0Svk3Zv3HMPkwbLGKC/eGoS6hyOXMeReYz/r32+XyTCGVYoTmJPBHykEzNjiU amQokHOhg0JeZ8Lxg5l5+a7Gbg7n7NTJTdHPgYDhTh4Po4jvTMSqw7q4wX2KYFoPgO9U dwRqz3rEKjQ6TQzjKiCdundGq7pSyIjEMesMG2oteOuOrFqcVa6I3Ujipjh72rEf+ssT EFk9d7pAn7zpcYFTq9vhpRbCjWZpjGTRED7vcz4n4OYUav9GULfESwgmhTzFz+Jv2oB6 c85Sm4MTedI9pjS8zT47M4AGtjsf21JVR9bAJWQLA3jBRrNDD9/qqeg+TtYBROiNS0UK oRrw== X-Received: by 10.14.211.132 with SMTP id w4mr48592792eeo.36.1361876212338; Tue, 26 Feb 2013 02:56:52 -0800 (PST) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id 3sm833215eej.6.2013.02.26.02.56.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Feb 2013 02:56:51 -0800 (PST) Message-ID: <512C94F0.8060106@gmail.com> Date: Tue, 26 Feb 2013 11:56:48 +0100 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <489D13FBFA9B3E41812EA89F188F018E1847C264@xmb-rcd-x04.cisco.com> <512BDF3E.3030902@gmail.com> <94C682931C08B048B7A8645303FDC9F36EB3C83288@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EB3C83288@PUEXCB1B.nanterre.francetelecom.fr> X-TagToolbar-Keys: D20130226115648704 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Reminder - WGLC: draft-ietf-dhc-triggered-reconfigure-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, 26 Feb 2013 10:56:54 -0000 On 26.02.2013 10:34, mohamed.boucadair@orange.com wrote: >> Figure 1 mentions NAS, without explaining what it means. I presume that >> it is Network Access Server, but it is not a common term in DHCP world, >> so it would be good to explain it. > > Med: I added this sentence: > "Figure 1 shows a broadband network scenario in which the Network Access Server (NAS) embeds a DHCPv6 relay agent." > Do you think the document needs to say more? No. That addition is sufficient. >> Section 2: "Reconfigure message is then sent to the DHCPv6 relay, which >> in turn will forward the message to the appropriate DHCPv6 >> client." This >> reconfigure message will be sent encapsulated in Relay-Reply, >> so it will >> look like every other message received from a server and to be >> processed >> by the relay, right? There's no text that clarifies that. > > Med: I added this sentence just after the one you quoted: > > "Note, the server encapsulates the Reconfigure message in a Relay-reply message." > Better? Yes. >> Last paragraph is section 2 talks about retransmissions, but do not >> explain how to conduct them if there is no server response. It should >> point out that the details are explained in section 4.3. > Med: The text is now updated to call out Section 4.3. Thanks. >> Section 4.2.1: "Clients MUST silently discard any received >> RECONFIGURE-REQUEST messages.". I would add that logging such an event >> is allowed, though. > Med: Is there any value to log such events in the client side? Sometimes yes. Some clients (e.g. dibbler) will print out a warning message, when receiving unknown message (basically anything besides advertise or reply). Reception of such a message by a client may mean that your network is seriously broken or there is an attack in progress. This is really a grey area that nobody cares about. Many clients and servers log various things when configured with sufficient log levels. If we want to be strict, this is a violation of RFC3315, but I have serious doubts anyone care about that. So I'm ok if you don't want to do anything here. >> "The server MUST be configurable to accept or reject RECONFIGURE- >> REQUEST messages." This should probably be moved to "Server behavior" >> section. > Med: Ok for me. Done. Thanks. > Also, you should specify what is the server default if not >> explicitly configured. It should be reject in my opinion. > > Med: I added this sentence: > "If no indication is explicitly configured to the server, the default behaviour is to reject RECONFIGURE-REQUEST messages." Ok, great. >> "The relay agent MUST be configurable to accept or reject RECONFIGURE- >> REQUEST messages received from other relay agents.". >> Reconfigure-Request >> is not addressed at relay and it merely helps deliver it to server, so >> instead of "accept or reject" I would use "forward or drop" here. > > Med: I do think both wording would work. "accept" is more generic as forwarding the message will be the result of other steps than just accept handling the message. I will maintain the initial wording. Ok. >> There should be a separate "Relay behavior" section and second to last >> paragraph in 4.2.1 should be moved to it. > > Med: I added a new section called "Intermediate Relay Agents Behaviour" and moved that text to the new section. Thanks. > There are very good reasons >> for having separate behavior sections for server, relays and client >> There should be one for client as well, even if it contains only one >> sentence about dropping those messages. It makes life of implementors >> much easier and increases chances of wider adoption of that proposal. >> >> The last paragraph in 4.2.1 belongs more in the Server >> behavior section. > > Med: Agree. Ok, thanks. >> Section 4.3 "The relay may receive (Relay-Reply) Reconfigure before..." >> is awkward. It should be "The relay may receive Reconfigure >> encapsulated >> in Relay-Reply before..." > > Med: Fixed. Thanks. Thanks. >> "The relay agent MUST include a Client Identifier Option..." => "The >> relay agent MUST include one or more Client Identifier Options..." > Med: Fixed. Thanks a lot. This was confusing without this clarification. >> Section 4.4 "Upon receipt of a valid Reconfigure-Request message from a >> DHCPv6 relay agent (see Section 4.2), the server determines the >> client(s) for which a Reconfigure message is to be sent.". >> >> Section 4.4, bullet 2 and 3 contradict each other. When relay requested >> reconfigure for 2 clients and one succeeds and the other fails, what >> should be the return status: success or failure code? > > Med: bullet 2 is about partial failure (i.e., there is at least a success > for one client); bullet 3 is when there is failure for all clients. In the > partial failure case, the list of failed cio are returned also in the > Reconfigure-Ack. > > What if the >> failure reasons are different for each client? It seems that the status >> code returning is not very useful for more than one client. >> >> Section 4.4, bullet 2 says that server must keep list of >> client-ids that >> it couldn't configure, but does not explain what to do with that list. >> Did you mean "include in reconfigure-ack"? If that is so, please >> rephrase that sentence. If you meant something else, please >> clarify as well. > > Med: The text is about Reconfigure-Ack. I fixed the text. Thanks. >> Section 7. You should change the text to say that servers MUST discard >> configure-request unless explicitly configured to accept them (or >> perhaps this should go into server behavior section). It's better to be >> safe than sorry. > > Med: discarding RECONFIGURE-REQUEST messages + configuration options are already covered in the server behaviour. I prefer Good point. THere's no need to repeat them here. One place is enough. >> Although DUIDs are typically 14 bytes long, the maximum allowed length >> is 128, so we can hit fragementation limit with only 10 clients. There >> should be a short clarification that relay should send separate >> reconfigure-requests if there are more clients (or some other >> suggestion >> what to do if the MTU limit is hit). > > Med: Isn't this covered in the text of Section 4.3: > > If including Client > Identifier Options of all impacted clients exceeds the maximum > message size (see Section 5), the relay MUST generate several > RECONFIGURE-REQUEST messages required to carry all Client Identifier > Options. Rate-limit considerations are discussed in Section 5. Oh, I missed that. Sorry. Yes, the existing text is clear then. >> Reconfigure mechanism is optional. What should the server do if client >> does not support Reconfigure? There's currently no way for server to >> signal that to back to relay. UnspecFail doesn't look right. Perhaps >> NotConfigured would be the right code for it? > > Med: If we need to specific, a new error code need to be defined for this > case. If you think there is a value in specifying that behaviour, > I suggest we define a new error code for it. I don't know. Does the relay can use the information why the reconfigure failed? I suppose there could be some value in making different permanent failures (e.g. the client do not support reconfigure) with some temporary failure that may disappear when repeated reconfigure request is made. But I do not have any strong opinion on that. Can someone else comment on this as well? >> Excuse my poor understanding of how NAS works, but does it >> keep DUIDs of >> all clients connected through it? So from the pure DHCP perspective, >> this is a stateful relay, right? If that is so, it should be pointed >> somewhere that the way relay keeps the information about clients is >> outside of scope for this document. > > Med: Section 2 says: > > This setup assumes the relay has a record of the client, so that it > has enough information to send the Reconfigure-Request message to the > server. Means to recover state in failure events must be supported, > but are not discussed in this document. > > I propose to change it to > > This setup assumes the relay has a record of the client, so that it > has enough information to send the Reconfigure-Request message to the > server. How the state is recorded in the relay is out of scope. Furthermore, means to recover state in failure events must be supported, > but are not discussed in this document. Ok. Ok, great. That deals with all my comments. Let's see if anyone else has additional comments on the status code. I'm ok with leaving it as it is, reusing some of the codes from leasequery or defining a new one. After that I think the draft is good to move forward. Cheers, Tomek From mohamed.boucadair@orange.com Tue Feb 26 04:42:58 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43EB21F8558 for ; Tue, 26 Feb 2013 04:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ql8QrNYpeO3P for ; Tue, 26 Feb 2013 04:42:57 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC0A21F8552 for ; Tue, 26 Feb 2013 04:42:57 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id B22CD22C683; Tue, 26 Feb 2013 13:42:55 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 934C527C066; Tue, 26 Feb 2013 13:42:55 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Tue, 26 Feb 2013 13:42:55 +0100 From: To: Tomek Mrugalski Date: Tue, 26 Feb 2013 13:42:54 +0100 Thread-Topic: [dhcwg] Reminder - WGLC: draft-ietf-dhc-triggered-reconfigure-03 Thread-Index: Ac4UD/2xo75zRJ+GRRqYWj1sXhPhKwADnEvA Message-ID: <94C682931C08B048B7A8645303FDC9F36EB3C833B0@PUEXCB1B.nanterre.francetelecom.fr> References: <489D13FBFA9B3E41812EA89F188F018E1847C264@xmb-rcd-x04.cisco.com> <512BDF3E.3030902@gmail.com> <94C682931C08B048B7A8645303FDC9F36EB3C83288@PUEXCB1B.nanterre.francetelecom.fr> <512C94F0.8060106@gmail.com> In-Reply-To: <512C94F0.8060106@gmail.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: 2013.2.26.105721 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Reminder - WGLC: draft-ietf-dhc-triggered-reconfigure-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, 26 Feb 2013 12:42:58 -0000 Re-, For the error code, I will wait for other opinions.=20 If no preference is expressed, the current text will be maintained as it is= .=20 Thanks again for the review.=20 Cheers, Med >-----Message d'origine----- >De : Tomek Mrugalski [mailto:tomasz.mrugalski@gmail.com]=20 >Envoy=E9 : mardi 26 f=E9vrier 2013 11:57 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : dhcwg@ietf.org >Objet : Re: [dhcwg] Reminder - WGLC:=20 >draft-ietf-dhc-triggered-reconfigure-03 > >On 26.02.2013 10:34, mohamed.boucadair@orange.com wrote: >>> Figure 1 mentions NAS, without explaining what it means. I=20 >presume that >>> it is Network Access Server, but it is not a common term in=20 >DHCP world, >>> so it would be good to explain it. >>=20 >> Med: I added this sentence:=20 >> "Figure 1 shows a broadband network scenario in which the=20 >Network Access Server (NAS) embeds a DHCPv6 relay agent." >> Do you think the document needs to say more? >No. That addition is sufficient. > > >>> Section 2: "Reconfigure message is then sent to the DHCPv6=20 >relay, which >>> in turn will forward the message to the appropriate DHCPv6=20 >>> client." This >>> reconfigure message will be sent encapsulated in Relay-Reply,=20 >>> so it will >>> look like every other message received from a server and to be=20 >>> processed >>> by the relay, right? There's no text that clarifies that. >>=20 >> Med: I added this sentence just after the one you quoted:=20 >>=20 >> "Note, the server encapsulates the Reconfigure message in a=20 >Relay-reply message." >> Better? >Yes. > >>> Last paragraph is section 2 talks about retransmissions, but do not >>> explain how to conduct them if there is no server response.=20 >It should >>> point out that the details are explained in section 4.3. >> Med: The text is now updated to call out Section 4.3.=20 >Thanks. > >>> Section 4.2.1: "Clients MUST silently discard any received >>> RECONFIGURE-REQUEST messages.". I would add that logging=20 >such an event >>> is allowed, though. >> Med: Is there any value to log such events in the client side? >Sometimes yes. Some clients (e.g. dibbler) will print out a warning >message, when receiving unknown message (basically anything besides >advertise or reply). Reception of such a message by a client may mean >that your network is seriously broken or there is an attack in=20 >progress. >This is really a grey area that nobody cares about. Many clients and >servers log various things when configured with sufficient log levels. >If we want to be strict, this is a violation of RFC3315, but I have >serious doubts anyone care about that. So I'm ok if you don't=20 >want to do >anything here. > >>> "The server MUST be configurable to accept or reject RECONFIGURE- >>> REQUEST messages." This should probably be moved to "Server=20 >behavior" >>> section.=20 >> Med: Ok for me. Done. >Thanks. > >> Also, you should specify what is the server default if not >>> explicitly configured. It should be reject in my opinion. >>=20 >> Med: I added this sentence:=20 >> "If no indication is explicitly configured to the server,=20 >the default behaviour is to reject RECONFIGURE-REQUEST messages." >Ok, great. > >>> "The relay agent MUST be configurable to accept or reject=20 >RECONFIGURE- >>> REQUEST messages received from other relay agents.".=20 >>> Reconfigure-Request >>> is not addressed at relay and it merely helps deliver it to=20 >server, so >>> instead of "accept or reject" I would use "forward or drop" here. >>=20 >> Med: I do think both wording would work. "accept" is more=20 >generic as forwarding the message will be the result of other=20 >steps than just accept handling the message. I will maintain=20 >the initial wording.=20 >Ok. > >>> There should be a separate "Relay behavior" section and=20 >second to last >>> paragraph in 4.2.1 should be moved to it. >>=20 >> Med: I added a new section called "Intermediate Relay Agents=20 >Behaviour" and moved that text to the new section. >Thanks. > >> There are very good reasons >>> for having separate behavior sections for server, relays and client >>> There should be one for client as well, even if it contains only one >>> sentence about dropping those messages. It makes life of=20 >implementors >>> much easier and increases chances of wider adoption of that=20 >proposal. >>> >>> The last paragraph in 4.2.1 belongs more in the Server=20 >>> behavior section. >>=20 >> Med: Agree. >Ok, thanks. > > >>> Section 4.3 "The relay may receive (Relay-Reply)=20 >Reconfigure before..." >>> is awkward. It should be "The relay may receive Reconfigure=20 >>> encapsulated >>> in Relay-Reply before..." >>=20 >> Med: Fixed. Thanks. >Thanks. > >>> "The relay agent MUST include a Client Identifier Option..." =3D> "The >>> relay agent MUST include one or more Client Identifier Options..." >> Med: Fixed.=20 >Thanks a lot. This was confusing without this clarification. > >>> Section 4.4 "Upon receipt of a valid Reconfigure-Request=20 >message from a >>> DHCPv6 relay agent (see Section 4.2), the server determines the >>> client(s) for which a Reconfigure message is to be sent.". >>> >>> Section 4.4, bullet 2 and 3 contradict each other. When=20 >relay requested >>> reconfigure for 2 clients and one succeeds and the other fails, what >>> should be the return status: success or failure code? >>=20 >> Med: bullet 2 is about partial failure (i.e., there is at=20 >least a success=20 >> for one client); bullet 3 is when there is failure for all=20 >clients. In >the >> partial failure case, the list of failed cio are returned also in the >> Reconfigure-Ack. >>=20 >> What if the >>> failure reasons are different for each client? It seems=20 >that the status >>> code returning is not very useful for more than one client. >>> >>> Section 4.4, bullet 2 says that server must keep list of=20 >>> client-ids that >>> it couldn't configure, but does not explain what to do with=20 >that list. >>> Did you mean "include in reconfigure-ack"? If that is so, please >>> rephrase that sentence. If you meant something else, please=20 >>> clarify as well. >>=20 >> Med: The text is about Reconfigure-Ack. I fixed the text. >Thanks. > >>> Section 7. You should change the text to say that servers=20 >MUST discard >>> configure-request unless explicitly configured to accept them (or >>> perhaps this should go into server behavior section). It's=20 >better to be >>> safe than sorry. >>=20 >> Med: discarding RECONFIGURE-REQUEST messages + configuration=20 >options are already covered in the server behaviour. I prefer >Good point. THere's no need to repeat them here. One place is enough. > >>> Although DUIDs are typically 14 bytes long, the maximum=20 >allowed length >>> is 128, so we can hit fragementation limit with only 10=20 >clients. There >>> should be a short clarification that relay should send separate >>> reconfigure-requests if there are more clients (or some other=20 >>> suggestion >>> what to do if the MTU limit is hit). >>=20 >> Med: Isn't this covered in the text of Section 4.3:=20 >>=20 >> If including Client >> Identifier Options of all impacted clients exceeds the maximum >> message size (see Section 5), the relay MUST generate several >> RECONFIGURE-REQUEST messages required to carry all Client=20 >Identifier >> Options. Rate-limit considerations are discussed in Section 5. >Oh, I missed that. Sorry. Yes, the existing text is clear then. > >>> Reconfigure mechanism is optional. What should the server=20 >do if client >>> does not support Reconfigure? There's currently no way for=20 >server to >>> signal that to back to relay. UnspecFail doesn't look right. Perhaps >>> NotConfigured would be the right code for it? >>=20 >> Med: If we need to specific, a new error code need to be=20 >defined for this >> case. If you think there is a value in specifying that behaviour, >> I suggest we define a new error code for it. >I don't know. Does the relay can use the information why the=20 >reconfigure >failed? I suppose there could be some value in making different >permanent failures (e.g. the client do not support reconfigure) with >some temporary failure that may disappear when repeated reconfigure >request is made. But I do not have any strong opinion on that. Can >someone else comment on this as well? > >>> Excuse my poor understanding of how NAS works, but does it=20 >>> keep DUIDs of >>> all clients connected through it? So from the pure DHCP perspective, >>> this is a stateful relay, right? If that is so, it should be pointed >>> somewhere that the way relay keeps the information about clients is >>> outside of scope for this document. >>=20 >> Med: Section 2 says:=20 >>=20 >> This setup assumes the relay has a record of the client,=20 >so that it >> has enough information to send the Reconfigure-Request=20 >message to the >> server. Means to recover state in failure events must be=20 >supported, >> but are not discussed in this document. >>=20 >> I propose to change it to=20 >>=20 >> This setup assumes the relay has a record of the client,=20 >so that it >> has enough information to send the Reconfigure-Request=20 >message to the >> server. How the state is recorded in the relay is out of=20 >scope. Furthermore, means to recover state in failure events=20 >must be supported, >> but are not discussed in this document. >Ok. > >Ok, great. That deals with all my comments. Let's see if=20 >anyone else has >additional comments on the status code. I'm ok with leaving it=20 >as it is, >reusing some of the codes from leasequery or defining a new one. > >After that I think the draft is good to move forward. > >Cheers, >Tomek > >= From gvithal@gmail.com Tue Feb 26 10:42:27 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F354621F89CE for ; Tue, 26 Feb 2013 10:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2ad27qD3xMW for ; Tue, 26 Feb 2013 10:42:25 -0800 (PST) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2734921F8984 for ; Tue, 26 Feb 2013 10:42:25 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id d7so3739147wer.8 for ; Tue, 26 Feb 2013 10:42:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=iKDeusKZin4Glz9M4aETf+quF9d575n6Hle2cFl8EBs=; b=zfTi+dksPy+ZUr50ci+J6HO/HcJC83MeBji2BCg00Tsn1B0K7/V9DHmNwV9f05j0rS Ur+VJTToyvE1KK63Y6g/imAM3x/mrjyFDT8avs1b4JFenQejuRE2IikCK7XFRVto1uXi hMGqwnEeCsIMP2UiezfFx3YcoVxmwaHn/1chsVb2PTLpefLV3ASIb0JkCyjsPayZRNI9 q/2/UyR4+HZGkyreg0krTBwnXl5/FfpcyILQCgGYCrzN6b02tmjwXyrCf+pQlZMe1EYi wpr4BffF3MsDDgm3q6B5RKBfDaAZR8TfMBkzSOH3IPkKT1IDKjpyMo+/4+p0e5Qa8OKb thQw== MIME-Version: 1.0 X-Received: by 10.194.83.105 with SMTP id p9mr28558759wjy.56.1361904144246; Tue, 26 Feb 2013 10:42:24 -0800 (PST) Received: by 10.216.234.200 with HTTP; Tue, 26 Feb 2013 10:42:23 -0800 (PST) In-Reply-To: References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> <8D23D4052ABE7A4490E77B1A012B63074747458F@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474754C3@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630747475B92@mbx-01.win.nominum.com> <510A6327.6050506@s-carlsen.dk> <489D13FBFA9B3E41812EA89F188F018E1844B249@xmb-rcd-x04.cisco.com> <1FF595DD-C7F5-475D-93BB-EC7E64428EBD@gmail.com> <93B6C36C-3E9F-4D11-8C08-3BB482C4A470@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1846E736@xmb-rcd-x04.cisco.com> Date: Wed, 27 Feb 2013 00:12:23 +0530 Message-ID: From: VithalPrasad Gaitonde To: Dmitry Anipko Content-Type: multipart/alternative; boundary=047d7bb04ed6bc6fcc04d6a504d4 Cc: "Bernie Volz \(volz\)" , Bud Millwood , Ralph Droms , "dhcwg@ietf.org" , Andre Kostur , Lemon Ted Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-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, 26 Feb 2013 18:42:27 -0000 --047d7bb04ed6bc6fcc04d6a504d4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Agree that 3 has the best merit. In terms of number of retransmissions, it would be preferable to go with as many retransmission (about 8?) as would fit in a 2 minute interval (i.e. the older SOL_MAX_RT value). Since existing deployments work with the 2 minute retransmission cycle, this will ensure that subsequent retransmissions (beyond the first hour) are successful. So the proposal is - the first retransmission cycle is for 1 hour with exponentially increasing time between retransmissions. Every subsequent retransmission cycle which will occur after a gap of 1 hour will last for a 2 minute duration. On Sat, Feb 16, 2013 at 8:41 AM, Dmitry Anipko wrote: > My understanding is that (2) would be against one of the motivations for > the draft =96 reduce load on servers, as you pointed out. **** > > ** ** > > So I agree (3) would be better, if at all something needs to be done for > this issue.**** > > ** ** > > *From:* Bernie Volz (volz) [mailto:volz@cisco.com] > *Sent:* Friday, February 15, 2013 2:45 PM > *To:* VithalPrasad Gaitonde > > *Cc:* Bud Millwood; Dmitry Anipko; Ralph Droms; dhcwg@ietf.org; Andre > Kostur; Lemon Ted > *Subject:* RE: [dhcwg] I-D Action: > draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt**** > > ** ** > > (I guess I should now start saying =93WG co-chair hat off=94 =85)**** > > ** ** > > Interesting points.**** > > ** ** > > The elapsed time option only supports 16-bits and is in 100ths of a > second, so it will max out at 655.35 seconds (under 11 minutes).**** > > ** ** > > As these are a =91retransmission=92 and so the XID would be the same and = the > elapsed time should reflect the time since the client started (obviously > maxing out at a value of 0xffff as documented in RFC 3315).**** > > ** ** > > Regarding the single packet issue =85 I see:**** > > **1. **Let it be. If the original retransmissions up this point > didn=92t work, what=92s the chance that it will work now? And a single pa= cket > should generally be OK. Though there may be some ND implementations that > drop a packet they can=92t send instead of holding onto at least that one > packet and that might cause things to fail =91forever=92 (the server-to-c= lient > or relay-to-client ND entry would expire before the next packet arrives). > **** > > **2. **Have the client could =91restart=92 the Solicit process inst= ead > of using the longer time as a cap to the retransmission delay. But this > means that the client would send restart sending at the normal backoff > intervals and that makes the clients (if there are a lot) very chatty in > total =96 which is what we wanted to prevent. This would also mean a new = XID > and new elapsed time base.**** > > **3. **Complicate the retransmission algorithm to allow some small > number (2 or 3) packets in a =93shorter=94 interval after =91long=92 retr= ansmission > interval (this is what you suggested). Probably these should occur well > within the typical ND cache expiration interval.**** > > **4. **Something else? (Document that not retaining a packet per > destination when needing ND is a bad idea.)**** > > ** ** > > 2 may be the most attractive as it is much simpler (and means this > document would define an MRD for Solicit too). But the long delay between > retransmissions leading up to the maximum may also suffer from the issue > mentioned in #1, so #3 may have the best merit.**** > > ** ** > > **- **Bernie**** > > ** ** > > *From:* dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > *On Behalf Of *VithalPrasad Gaitonde > *Sent:* Thursday, February 14, 2013 10:14 PM > *To:* Bernie Volz (volz) > *Cc:* Bud Millwood; Dmitry Anipko; Ralph Droms; dhcwg@ietf.org; Andre > Kostur; Lemon Ted > *Subject:* Re: [dhcwg] I-D Action: > draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt**** > > ** ** > > Apparently, some relay agents/switches can be configured to relay packets > based on the amount of time the client has been trying (elapsed time > option). Similar language exists for the behavior of the DHCP server.**** > > **** > > From RFC 3315 section 22.9 - **** > > Servers and Relay Agents use the data value in this option (elapsed time) > as input to policy controlling how a server responds to a client > message. For example, the elapsed time option allows a secondary > DHCP server to respond to a request when a primary server has not > answered in a reasonable time.**** > > **** > > When the client retransmits at every 1 hour interval, does the client > reset the elapsed time option to 0. If yes, with the above mentioned > behavior of relay agents and servers, the single retransmission of SOLICI= T > or INFORM will turn out inadequate.**** > > Also, given the unreliability of UDP, doing only one retransmission of th= e > message every hour (beyond the first hour) may lead to situations where t= he > server does not see the request and the client has to wait for another ho= ur > to get an IPv6 address or options.**** > > **** > > Instead of making just a single retransmission at every 1 hour interval, > the client should make at least a couple of retransmissions to increase t= he > reliability of getting an IPv6 address or options from the server.**** > > **** > > Thanks,**** > > Prasad**** > > On Fri, Feb 1, 2013 at 8:10 PM, Bernie Volz (volz) wrote= : > **** > > Fine by me too. > > - Bernie**** > > > On Feb 1, 2013, at 9:52 PM, "Dmitry Anipko" > wrote: > > >>> A client is not expected to listen for a response during the entire > period between transmission of Solicit or Information-Request messages > > > > Looks good to me. > > > > Thanks. > > > > -----Original Message----- > > From: Ralph Droms [mailto:rdroms.ietf@gmail.com] > > Sent: Friday, February 01, 2013 6:08 PM > > To: Dmitry Anipko > > Cc: Bernie Volz (volz); Bud Millwood; Sten Carlsen; dhcwg@ietf.org; > Andre Kostur; Lemon Ted > > Subject: Re: [dhcwg] I-D Action: > draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt > > > > (resending to dhcwg mailing list) > > > > On Feb 1, 2013, at 5:59 PM 2/1/13, Dmitry Anipko < > Dmitry.Anipko@microsoft.com> > > wrote: > > > >> Agree with everything you wrote. I think several minutes waiting would > be fine, and I understand there may be good reasons for such waiting > interval (as opposed to hour). > >> > >> If there is a general agreement on these 2 adjustments (allowed waitin= g > period cap and INF_MAX_RT default), how do we move forward - Ralph, can > these be included in the next revision of the draft? > >> > >> Thank you. > > > > Adding INF_MAX_RT makes sense. > > > > In my opinion, the right thing to say about waiting for a response is > something vague, to the effect of "A client is not expected to listen for= a > response during the entire period between transmission of Solicit or > Information-Request messages." > > > > - Ralph > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg**** > > ** ** > --047d7bb04ed6bc6fcc04d6a504d4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Agree that 3 has the best merit. In terms of number of retransmissions= , it would be preferable to go with as many retransmission (about 8?) as wo= uld fit in a 2 minute interval (i.e. the older SOL_MAX_RT value).
Since existing deployments work with the 2 minute retransmission cycle= , this will ensure that subsequent retransmissions (beyond the first hour) = are successful.
=A0
So the proposal is - the first retr= ansmission cycle is for 1 hour with exponentially increasing time between r= etransmissions. Every subsequent retransmission cycle which will occur afte= r a gap of 1 hour will=A0last for a 2 minute duration.=A0


=A0
On Sat, Feb 16, 2013 at 8:= 41 AM, Dmitry Anipko <Dmitry.Anipko@microsoft.com>= wrote:

My understanding is = that (2) would be against one of the motivations for the draft =96 reduce l= oad on servers, as you pointed out.

=A0

So I agree (3) would= be better, if at all something needs to be done for this issue.<= /u>

=A0

From: Bernie Volz = (volz) [mailto:volz@cis= co.com]
Sent: Friday, February 15, 2013 2:45 PM
To: VithalPrasad Gaitonde


Cc: Bud Millwood; Dmitry Anipko; Ralph Droms; dhcwg@ietf.org; Andre Kostur; Lemon Ted
Subject: RE: [dhcwg] I-D Action: draft-ietf-= dhc-dhcpv6-solmaxrt-update-00.txt

=A0

(I guess I should no= w start saying =93WG co-chair hat off=94 =85)

=

=A0

Interesting points.<= u>

=A0

The elapsed time opt= ion only supports 16-bits and is in 100ths of a second, so it will max out = at 655.35 seconds (under 11 minutes).

=A0

As these are a =91re= transmission=92 and so the XID would be the same and the elapsed time shoul= d reflect the time since the client started (obviously maxing out at a value of 0xffff as documented in RFC 3315).

=A0

Regarding the single= packet issue =85 I see:

1.Let it be. If t= he original retransmissions up this point didn=92t work, what=92s the chanc= e that it will work now? And a single packet should generally be OK. Though there may be some ND implementations that drop a packet they= can=92t send instead of holding onto at least that one packet and that mig= ht cause things to fail =91forever=92 (the server-to-client or relay-to-cli= ent ND entry would expire before the next packet arrives).

2.Have the client= could =91restart=92 the Solicit process instead of using the longer time a= s a cap to the retransmission delay. But this means that the client would send restart sending at the normal backoff intervals and that= makes the clients (if there are a lot) very chatty in total =96 which is w= hat we wanted to prevent. This would also mean a new XID and new elapsed ti= me base.

3.Complicate the = retransmission algorithm to allow some small number (2 or 3) packets in a = =93shorter=94 interval after =91long=92 retransmission interval (this is what you suggested). Probably these should occur well within the typica= l ND cache expiration interval.

4.Something else?= (Document that not retaining a packet per destination when needing ND is a= bad idea.)

=A0

2 may be the most at= tractive as it is much simpler (and means this document would define an MRD= for Solicit too). But the long delay between retransmissions leading up to the maximum may also suffer from the issue mentioned in #1, = so #3 may have the best merit.

=A0

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Bernie

=A0

From: dhcwg-bounces@i= etf.org [ma= ilto:dhcwg-bounces@ietf.org] On Behalf Of VithalPrasad Gaitonde
Sent: Thursday, February 14, 2013 10:14 PM
To: Bernie Volz (volz)
Cc: Bud Millwood; Dmitry Anipko; Ralph Droms; dhcwg@ietf.org; Andre Kostur; Lemon Ted
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-upda= te-00.txt

=A0

Apparently, some relay agents/switches can be config= ured to relay packets based on the amount of time the client has been tryin= g (elapsed time option). Similar language exists for the behavior of the DH= CP server.

=A0

From RFC 3315 section 22.9 -

Servers and Relay Agents use the data value in this = option (elapsed time)
=A0=A0 as input to policy controlling how a server responds to a client
=A0=A0 message.=A0 For example, the elapsed time option allows a secondary<= br> =A0=A0 DHCP server to respond to a request when a primary server has not =A0=A0 answered in a reasonable time.

=A0

When the client retransmits at every 1 hour interval= , does the client reset the elapsed time option to 0. If yes, with the abov= e mentioned behavior of relay agents and servers, the single retransmission= of SOLICIT or INFORM will turn out inadequate.

Also, given the unreliability of UDP, doing only one= retransmission of the message every hour (beyond the first hour) may lead = to situations where the server does not see the request and the client has = to wait for another hour to get an IPv6 address or options.

=A0

Instead of making just a single retransmission at ev= ery 1 hour interval, the client should make at least=A0a couple of=A0retran= smissions to increase the reliability of getting an IPv6 address or options= from the server.

=A0

Thanks,

Prasad

On Fri, Feb 1, 2013 at 8:10 PM, Bernie Volz (volz) &= lt;volz@cisco.com&g= t; wrote:

Fine by me too.

- Bernie


On Feb 1, 2013, at 9:52 PM, "Dmitry Anipko" <Dmitry.Anipko@microsoft.com= > wrote:

>>> A client is not expected to listen for a response during the e= ntire period between transmission of Solicit or Information-Request message= s
>
> Looks good to me.
>
> Thanks.
>
> -----Original Message-----
> From: Ralph Droms [mailto:rdroms.ietf@gmail.com]
> Sent: Friday, February 01, 2013 6:08 PM
> To: Dmitry Anipko
> Cc: Bernie Volz (volz); Bud Millwood; Sten Carlsen; dhcwg@ietf.org; Andre Kostur; Lemon Ted
> Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update= -00.txt
>
> (resending to dhcwg mailing list)
>
> On Feb 1, 2013, at 5:59 PM 2/1/13, Dmitry Anipko <Dmitry.Anipko@microsoft.com= >
> wrote:
>
>> Agree with everything you wrote. I think several minutes waiting w= ould be fine, and I understand there may be good reasons for such waiting i= nterval (as opposed to hour).
>>
>> If there is a general agreement on these 2 adjustments (allowed wa= iting period cap and INF_MAX_RT default), how do we move forward - Ralph, c= an these be included in the next revision of the draft?
>>
>> Thank you.
>
> Adding INF_MAX_RT makes sense.
>
> In my opinion, the right thing to say about waiting for a response is = something vague, to the effect of "A client is not expected to listen = for a response during the entire period between transmission of Solicit or = Information-Request messages."
>
> - Ralph
>
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

=A0


--047d7bb04ed6bc6fcc04d6a504d4-- From leaf.yeh.sdo@gmail.com Wed Feb 27 08:49:07 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D561821F84F5 for ; Wed, 27 Feb 2013 08:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.021 X-Spam-Level: X-Spam-Status: No, score=-3.021 tagged_above=-999 required=5 tests=[AWL=0.577, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cC6fZP+yVtzq for ; Wed, 27 Feb 2013 08:49:06 -0800 (PST) Received: from mail-da0-f41.google.com (mail-da0-f41.google.com [209.85.210.41]) by ietfa.amsl.com (Postfix) with ESMTP id D466121F8667 for ; Wed, 27 Feb 2013 08:49:06 -0800 (PST) Received: by mail-da0-f41.google.com with SMTP id j17so382296dan.14 for ; Wed, 27 Feb 2013 08:49:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=WBD3oQ9ymHBxKq7IP2Vrh8ok6LogngXLJgksNBVlcdc=; b=1CP8CokzVBcOAqc3Ll2EfCvRh0jf40bIoQDnjcqibcMsSwYab3OKgQ247GfmIIs0+G HxOeqVeBWhxk86FU5xwKNI+W9uJwG4KM5lVTXYTQE2pidzeqEX5HPNn112EuMtXpHfla NKUy0WTGbRMHIUTCpf/W88ui3u2v6q+KJjGkzEFBvQx3/6EwTNgL0KSvFYuDX9ADXh/Q jYbQrQy2cJv258jTVKIvPk40F+ZTUzyTGwhjVK01v6Gq5MUJlovIp7/5EphJnPSndGFG uASo0S8kxZbSLBVw/X1mevhyCH8tkQ+bkUjKkePZo+jEOMt6EhskEM9Wy63Jm9QIcXC8 vVkQ== X-Received: by 10.66.146.37 with SMTP id sz5mr8338408pab.157.1361983746162; Wed, 27 Feb 2013 08:49:06 -0800 (PST) Received: from PC ([218.18.217.235]) by mx.google.com with ESMTPS id ax3sm5172953pbd.42.2013.02.27.08.49.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 27 Feb 2013 08:49:05 -0800 (PST) From: "Leaf Yeh" To: "'Dhc Chairs'" , "'Bernie Volz \(volz\)'" , "'dhc WG'" Date: Thu, 28 Feb 2013 00:48:51 +0800 Message-ID: <512e3901.6300450a.1da0.ffffa48a@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01CE154D.657D5220" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4VCkdan65c4meqQDW2z402Hv1U+w== Content-Language: zh-cn Cc: 'Ted Lemon' Subject: [dhcwg] Request to make WGLC on draft-ietf-dhc-dhcpv6-prefix-pool-opt-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 16:49:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001F_01CE154D.657D5220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Chairs, The authors of the draft (OPTION_PREFIX_POOL) request to make WGLC on draft-ietf-dhc-dhcpv6-prefix-pool-opt-02. We think it is ready to collect more thorough reviews and comments on it. Best Regards, Leaf PS. The following slides are for the reference to the DHC folks: http://www.ietf.org/proceedings/85/slides/slides-85-dhc-6.pdf http://www.ietf.org/proceedings/84/slides/slides-84-dhc-10.pdf http://www.ietf.org/proceedings/81/slides/dhc-2.pdf http://www.ietf.org/proceedings/80/slides/dhc-3.pdf http://www.ietf.org/proceedings/79/slides/dhc-3.pdf We won't send more slides to the WG for IETF86. ------=_NextPart_000_001F_01CE154D.657D5220 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = Chairs,

 

The authors of the draft (OPTION_PREFIX_POOL) request to = make WGLC on draft-ietf-dhc-dhcpv6-prefix-pool-opt-02. We think it is = ready to collect more thorough reviews and comments on = it.

 

 

Best Regards,

Leaf

 

 

PS. The following slides are for = the reference to the DHC folks:

ht= tp://www.ietf.org/proceedings/85/slides/slides-85-dhc-6.pdf

h= ttp://www.ietf.org/proceedings/84/slides/slides-84-dhc-10.pdf

http://www.i= etf.org/proceedings/81/slides/dhc-2.pdf

http://www.i= etf.org/proceedings/80/slides/dhc-3.pdf

http://www.i= etf.org/proceedings/79/slides/dhc-3.pdf

We won’t send more slides to = the WG for IETF86.

 

------=_NextPart_000_001F_01CE154D.657D5220-- From gvithal@gmail.com Wed Feb 27 11:00:06 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8A221F847B for ; Wed, 27 Feb 2013 11:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xup8JOLM6kHM for ; Wed, 27 Feb 2013 11:00:04 -0800 (PST) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by ietfa.amsl.com (Postfix) with ESMTP id 66C5421F8988 for ; Wed, 27 Feb 2013 11:00:02 -0800 (PST) Received: by mail-vc0-f169.google.com with SMTP id n10so613313vcn.14 for ; Wed, 27 Feb 2013 11:00:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=8GibuyiSyghLSEWSsBAN0SCMFUENd14T405/n64FwP8=; b=g4N/AeI7pmgHkbXTitlgmkAEkJ65aIUSWwcNiCZ2CP6UTvRxdF/7Yfrx7OYmGSvUFq 4sIdx8mW2svQMvTRuZa6YYob6JNipf1rnDqe4FPwbBHSuev582xyHVpXICzznVL0wFYX yDWUf+TbKaP8yHp9gJg3J0P4WlTbhLtMoh8a55TiJyyzfKfLP/l/a2Byl3rgmuB33ChY U9ZTZWpWHVRct4dz77C7M6TqTbOxKkcKpYBdNaHtfRYg3hWvNoonQM73LT4cAIWcUDzc 0r+h4LOXyOGGhURQUf94+sgbiB0qU/68AWldOayYRBIS2PxLQnY1IWOvrbY9vGgicGPt 4N3Q== MIME-Version: 1.0 X-Received: by 10.220.155.8 with SMTP id q8mr1286427vcw.42.1361991601694; Wed, 27 Feb 2013 11:00:01 -0800 (PST) Received: by 10.59.6.134 with HTTP; Wed, 27 Feb 2013 11:00:01 -0800 (PST) Date: Thu, 28 Feb 2013 00:30:01 +0530 Message-ID: From: VithalPrasad Gaitonde To: "" Content-Type: multipart/alternative; boundary=f46d043bdf9e9b2ef504d6b961e0 Subject: [dhcwg] RFC 4702 - FQDN option (81) X-BeenThere: dhcwg@ietf.org 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, 27 Feb 2013 19:00:06 -0000 --f46d043bdf9e9b2ef504d6b961e0 Content-Type: text/plain; charset=ISO-8859-1 As per RFC 4702, Clients MAY send the Client FQDN option, setting appropriate Flags values, in both their DHCPDISCOVER and DHCPREQUEST messages. If a client sends the Client FQDN option in its DHCPDISCOVER message, it MUST send the option in subsequent DHCPREQUEST messages though the contents of the option MAY change. Which implies the client is not required to send FQDN option in DHCPDISCOVER message but can do so in the REQUEST. INFORM message is also not required to contain the FQDN option. This client behavior poses a problem if the server is configured to give IP addresses and/or options based on DNS domain of the client. For example,. all clients in example.com should get IP from 10.1.1.10 to 10.1.1.50 and DNS server of 10.1.1.2 The server will not be able to evaluate the message at the time of DISCOVER message and will OFFER an IP address from the general IP address range. However, the REQUEST message contains the FQDN. Since FQDN is present, the client needs to be given an IP address (and options) based on the DNS domain of the client. So, the server will need to NAK the REQUEST for the same IP that it OFFERED earlier. This will force the client to start a fresh DORA transaction to be initiated but which will never complete leading to perpetual attempts being made by the client. To avoid this problem, should we consider altering the behavior specified in RFC 4702 to mandate FQDN option to be sent in DISCOVER as well as INFORM message by the client. Thanks, Prasad --f46d043bdf9e9b2ef504d6b961e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As per RFC 4702,
=A0
Clients MAY send the Client F= QDN option, setting appropriate Flags
=A0=A0 values, in both their DHCPD= ISCOVER and DHCPREQUEST messages.=A0 If a
=A0=A0 client sends the Client= FQDN option in its DHCPDISCOVER message, it
=A0=A0 MUST send the option in subsequent DHCPREQUEST messages though the=A0=A0 contents of the option MAY change.
Which implies the= client is not required to send FQDN option in DHCPDISCOVER message but can= do so in the REQUEST. INFORM message is also not required to contain the F= QDN option.
This client behavior poses a problem if the server is configured to gi= ve IP addresses and/or options based on DNS domain of the client. For examp= le,. all clients in example.com should g= et IP from 10.1.1.10 to 10.1.1.50 and DNS server of 10.1.1.2 The server wil= l not be able to evaluate the message at the time of DISCOVER message and w= ill OFFER an IP address from the general IP address range. However, the REQ= UEST message contains the FQDN. Since FQDN is present, the client needs to = be given an IP address (and options) based on the DNS domain of the client.= So, the server will need to NAK the REQUEST for the same IP that it OFFERE= D earlier. This will force the client to=A0start a=A0fresh DORA transaction= to be initiated but which will never complete leading to perpetual attempt= s being made by the client.
=A0
To avoid this problem, should we consider altering the b= ehavior specified in RFC 4702 to mandate FQDN option to be sent in DISCOVER= as well as INFORM message by the client.
=A0
Thanks,
Prasad
--f46d043bdf9e9b2ef504d6b961e0-- From Ted.Lemon@nominum.com Wed Feb 27 11:46:04 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E6F21F8B83 for ; Wed, 27 Feb 2013 11:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceEDwCfW6NPJ for ; Wed, 27 Feb 2013 11:46:04 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 70C1321F8B0C for ; Wed, 27 Feb 2013 11:46:04 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUS5ifDrcvRCCygKRqMFSNR6BMAFohTaN@postini.com; Wed, 27 Feb 2013 11:46:04 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 283A61B8363 for ; Wed, 27 Feb 2013 11:46:04 -0800 (PST) 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 1FB04190043; Wed, 27 Feb 2013 11:46:04 -0800 (PST) (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.0318.004; Wed, 27 Feb 2013 11:45:58 -0800 From: Ted Lemon To: VithalPrasad Gaitonde Thread-Topic: [dhcwg] RFC 4702 - FQDN option (81) Thread-Index: AQHOFRysdoLfTCtosEG2McEuZNRzEZiOogKA Date: Wed, 27 Feb 2013 19:45:58 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474A3E3C@mbx-01.win.nominum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0F07E273F7762448900D0FFCC372E3F5@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] RFC 4702 - FQDN option (81) X-BeenThere: dhcwg@ietf.org 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, 27 Feb 2013 19:46:05 -0000 On Feb 27, 2013, at 2:00 PM, VithalPrasad Gaitonde wrote: > To avoid this problem, should we consider altering the behavior specified= in RFC 4702 to mandate FQDN option to be sent in DISCOVER as well as INFOR= M message by the client. Getting DHCPv4 client vendors to change their implementations by adding req= uirements language to follow-on documents as would be required here has not= been effective in the past. I don't think there's much point in it. From lear@cisco.com Wed Feb 27 11:48:57 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF67E21F8AA6 for ; Wed, 27 Feb 2013 11:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.593 X-Spam-Level: X-Spam-Status: No, score=-110.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVma7Y5fMm2i for ; Wed, 27 Feb 2013 11:48:57 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 2C93821F8A1C for ; Wed, 27 Feb 2013 11:48:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=327; q=dns/txt; s=iport; t=1361994535; x=1363204135; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=7/LndCOZWNh4j6hnaPYFbaR3TXNs9Z8heQ9eIe6O458=; b=bQfhM28RkEr3UF0pn1mLec8WFmpdBQbTUz4taKOn85lMUG2GIoC3yWzR I0bev5VKy+NlP7WFhejLbQ9tk7ajS1ubwXp9j12A4SvqXuFZXpqiufla/ pX++u6cL6ExboviG1/hhJp6ql9+jrG3ZSdOdFrL10joS3JjuATZtlEa3y 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFABViLlGQ/khR/2dsb2JhbABFhk+7WH0Wc4IfAQEBBCNVARALGAICBRYLAgIJAwIBAgFFBg0BBwEBiA+vJ5J1gSONcQeCLYETA5ZBkGqDCQ X-IronPort-AV: E=Sophos;i="4.84,750,1355097600"; d="scan'208";a="12100970" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 27 Feb 2013 19:48:54 +0000 Received: from dhcp-10-61-98-134.cisco.com (dhcp-10-61-98-134.cisco.com [10.61.98.134]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1RJmru2022121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2013 19:48:53 GMT Message-ID: <512E6325.9000603@cisco.com> Date: Wed, 27 Feb 2013 20:48:53 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Ted Lemon References: <8D23D4052ABE7A4490E77B1A012B6307474A3E3C@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474A3E3C@mbx-01.win.nominum.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [dhcwg] RFC 4702 - FQDN option (81) X-BeenThere: dhcwg@ietf.org 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, 27 Feb 2013 19:48:57 -0000 On 2/27/13 8:45 PM, Ted Lemon wrote: > > Getting DHCPv4 client vendors to change their implementations by adding requirements language to follow-on documents as would be required here has not been effective in the past. I don't think there's much point in it. > And relying on such behavior is often risky. Eliot From volz@cisco.com Wed Feb 27 21:35:07 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61CD221F84C9 for ; Wed, 27 Feb 2013 21:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.525 X-Spam-Level: X-Spam-Status: No, score=-10.525 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOQtMuMuK-uy for ; Wed, 27 Feb 2013 21:35:05 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 45C2E21F84F0 for ; Wed, 27 Feb 2013 21:35:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6033; q=dns/txt; s=iport; t=1362029705; x=1363239305; h=from:to:subject:date:message-id:mime-version; bh=ZTS2jnl7euxAEShlewT62SwPNJvT6Tr1SabHKRvUoTA=; b=JDXtDYupkeRc/f5GFK17U0hK+Merlls9VFpW//swj9gvT8saOQBthanp 8+S8X2tDmCv76jgbyZ+L6Z1CwmyKZA9OkDTxeLcQqhfsBKJw3DqPkUPWP zDBhUOJh26KOsHmppQtln+3kYOHXdgnD3pB3rVYp7C7ueSmeHl6ho7YlH s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEFAEbrLlGtJV2c/2dsb2JhbABFgkODRbwnexZzgiEBBC1eASodORQSAQQTCIgLDKAOoTEEjmMtgmphA6crgwiCJw X-IronPort-AV: E=Sophos;i="4.84,753,1355097600"; d="scan'208,217";a="182062147" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 28 Feb 2013 05:35:04 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1S5Z4lB019891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 28 Feb 2013 05:35:04 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Wed, 27 Feb 2013 23:35:03 -0600 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: Draft IETF-86 (Orlando) agenda posted Thread-Index: Ac4VdJzDvtfdP0elRfye9gApBonidg== Date: Thu, 28 Feb 2013 05:35:03 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E18484954@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.246.27] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E18484954xmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: [dhcwg] Draft IETF-86 (Orlando) agenda posted X-BeenThere: dhcwg@ietf.org 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, 28 Feb 2013 05:35:07 -0000 X-List-Received-Date: Thu, 28 Feb 2013 05:35:07 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E18484954xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A draft of the IETF-86 DHC WG meeting in Orlando has been posted: https://datatracker.ietf.org/meeting/86/agenda/dhc/ If you requested time, please confirm that it is on the agenda! If not, ple= ase let us know (dhc-chairs@tools.ietf.org). If you haven't requested time and want a slot, please send a request ASAP (= to dhc-chairs@tools.ietf.org). - Bernie --_000_489D13FBFA9B3E41812EA89F188F018E18484954xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A draft of the IETF-86 DHC WG meeting in Orlando has= been posted:

 

https://datatracker.ietf.org/meeting/86/agenda/dhc/

 

If you requested time, please confirm that it is on = the agenda! If not, please let us know (dhc-chairs@tools.ietf.org).

 

If you haven’t requested time and want a slot,= please send a request ASAP (to dhc-chairs@tools.ietf.org)= .

 

-     &= nbsp;    Bernie

--_000_489D13FBFA9B3E41812EA89F188F018E18484954xmbrcdx04ciscoc_-- From repenno@cisco.com Thu Feb 28 11:11:28 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B0221F88C1 for ; Thu, 28 Feb 2013 11:11:28 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtGc8KMC3SZe for ; Thu, 28 Feb 2013 11:11:27 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 94DB021F88BE for ; Thu, 28 Feb 2013 11:11:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=177; q=dns/txt; s=iport; t=1362078687; x=1363288287; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=UG2Sz4xzyWYtVKihzUSbW0mVLgpdKnER7bZMDVUQOq8=; b=hE1S17+bIVQGZjtfA+vFfMw46GhnOabNx7l5iRJ1Rr7tDsS+/VLSR115 Qq+YIP8y48UG16yvnns4BpnbfO6W3ecyPmkXW0O14HF8HDBrptSDyMlmK lu+x1Pzlmx/ypeknlKcBcOYI1zAtTlIIsAAmzeWUNtpWqUszyNv0AEsbS Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FADKqL1GtJV2c/2dsb2JhbABFhgi8JnwWc4IhAQQ6UQEqFEInBBuICwygQKBfjmODF2EDl1+PTIMIgic X-IronPort-AV: E=Sophos;i="4.84,756,1355097600"; d="scan'208";a="179354378" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 28 Feb 2013 19:11:27 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1SJBReS017547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 28 Feb 2013 19:11:27 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Thu, 28 Feb 2013 13:11:26 -0600 From: "Reinaldo Penno (repenno)" To: "dhcwg@ietf.org" Thread-Topic: WGLC Request for Container Option for Server Configuration Thread-Index: AQHOFednUNNIsXbzjkSp+Zmzokohaw== Date: Thu, 28 Feb 2013 19:11:26 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040901511E@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.74.57] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] WGLC Request for Container Option for Server Configuration X-BeenThere: dhcwg@ietf.org 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, 28 Feb 2013 19:11:28 -0000 Chairs, I would like to request a WGLC on "Container Option for Server Configuration" http://tools.ietf.org/html/draft-ietf-dhc-container-opt-06. Regards, Reinaldo From volz@cisco.com Thu Feb 28 19:55:07 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBAA121F85EB for ; Thu, 28 Feb 2013 19:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.532 X-Spam-Level: X-Spam-Status: No, score=-10.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlDtBwxxdX4T for ; Thu, 28 Feb 2013 19:55:06 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D109221F8585 for ; Thu, 28 Feb 2013 19:55:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=670; q=dns/txt; s=iport; t=1362110106; x=1363319706; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=6myFDbvd8DqopAy4udSofeww6IjIp4VKHqa6fEBq1SE=; b=Bjz8JjasN2vKrLQyyuIPALsvsLU/DrVMgaLcJGh4NCqh1RcZ+yd/JZEm iDC+cnvoLM2XoGdEWWY6D38Vq7rBaiURLM2BO6WyySCa3yrvlBl35x4Cn zoPh+p297iSlXzmPZZq5ng5kAOfRE9kg4kQvCQEq76GDEuyG/JLhur2a8 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFALIlMFGtJV2d/2dsb2JhbABFhgi8K4EAFnOCHwEBAQQBAQE3NBcEAgEIEQQBAQsUCQcnCxQJCAIEARIIiAsMwSmOYyYSBoJZYQOXX49MgwiCJw X-IronPort-AV: E=Sophos;i="4.84,759,1355097600"; d="scan'208";a="182473976" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 01 Mar 2013 03:55:05 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r213t5LL009332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 1 Mar 2013 03:55:05 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Thu, 28 Feb 2013 21:55:05 -0600 From: "Bernie Volz (volz)" To: "Reinaldo Penno (repenno)" , "dhcwg@ietf.org" Thread-Topic: WGLC Request for Container Option for Server Configuration Thread-Index: AQHOFednUNNIsXbzjkSp+Zmzokoha5iQNNmQ Date: Fri, 1 Mar 2013 03:55:04 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E18486E99@xmb-rcd-x04.cisco.com> References: <45A697A8FFD7CF48BCF2BE7E106F06040901511E@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040901511E@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.246.27] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC Request for Container Option for Server Configuration X-BeenThere: dhcwg@ietf.org 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, 01 Mar 2013 03:55:07 -0000 Hi: We will initiate a WGLC shortly after the Orlando IETF meeting. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of R= einaldo Penno (repenno) Sent: Thursday, February 28, 2013 2:11 PM To: dhcwg@ietf.org Subject: [dhcwg] WGLC Request for Container Option for Server Configuration Chairs, I would like to request a WGLC on "Container Option for Server Configuratio= n" http://tools.ietf.org/html/draft-ietf-dhc-container-opt-06. Regards, Reinaldo _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Thu Feb 28 21:20:53 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B4321F87CE for ; Thu, 28 Feb 2013 21:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.536 X-Spam-Level: X-Spam-Status: No, score=-10.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wTE4JDVq1y8 for ; Thu, 28 Feb 2013 21:20:52 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2C59321F87BA for ; Thu, 28 Feb 2013 21:20:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10754; q=dns/txt; s=iport; t=1362115252; x=1363324852; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FUV15XsxudOHTASWQHYWHRZuS9MiHGd3k5JaGYE9TLQ=; b=Di0m1ozfwEF4SkRjPy9qfnPc16pU21p3v95U5AsRrzXOvfGax/g5JAaY iCNw75c5w4EWM69jL6tsepOlnIbG0wCiUZ9Ls1UQp2o5d3fwNdJRJM3oD 6dceg9Rxgt2F/KWmtibgGFaordQLGfimUhkrPf42HSiWQXtreR/NZ81to k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAKs5MFGtJV2a/2dsb2JhbABEwjOBARZzgh8BAQEDAQEBATcNJQIIAwUHBAIBCA4DBAEBAQoUCQcnCxQJCAEBBAENBQgRh3QGDLJujhYEjU6BFSYLBwaCWWEDpyuDCIFpAQYZBBo X-IronPort-AV: E=Sophos;i="4.84,759,1355097600"; d="scan'208";a="182491157" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 01 Mar 2013 05:20:51 +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 r215KmAM024162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Mar 2013 05:20:48 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Thu, 28 Feb 2013 23:20:48 -0600 From: "Bernie Volz (volz)" To: Tomek Mrugalski , "mohamed.boucadair@orange.com" Thread-Topic: [dhcwg] Reminder - WGLC: draft-ietf-dhc-triggered-reconfigure-03 Thread-Index: Ac4To7U7cr4L60i/Ykinr5uevMfmMQATmaFQABQKCgAAfc7GkA== Date: Fri, 1 Mar 2013 05:20:48 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E18487090@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E1847C264@xmb-rcd-x04.cisco.com> <512BDF3E.3030902@gmail.com> <94C682931C08B048B7A8645303FDC9F36EB3C83288@PUEXCB1B.nanterre.francetelecom.fr> <512C94F0.8060106@gmail.com> In-Reply-To: <512C94F0.8060106@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.246.27] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Reminder - WGLC: draft-ietf-dhc-triggered-reconfigure-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, 01 Mar 2013 05:20:53 -0000 (WG hat off) The issue regarding section 4.4 and error-codes should be addressed and cla= rified. Personally, I don't see a need for the server to return specific status (er= ror) information for each client, as the likely reasons it would not be abl= e to send a Reconfigure is because the client didn't negotiate for reconfig= ure support or the client doesn't exist in the server. There are other reas= ons (lack of resources) ... We have to ask what benefit (other than potentially logging) would the Rela= y gain by having more specific information? I don't really believe there is= . Perhaps the three possible returns are: - Full Success (first bullet in existing section). - Partial Success (second bullet) - includes list of clients NOT processed = (for whatever reason) which might be ALL clients. - Full failure (third bullet) where clients were not even attempted - this = handles the case where: A) the packet is malformed (for example has no client-identifier option) - = UnspecFail B) the server has been configured not to allow this request - NotAllowed C) the server has no record of the link - NotConfigured - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= omek Mrugalski Sent: Tuesday, February 26, 2013 5:57 AM To: mohamed.boucadair@orange.com Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Reminder - WGLC: draft-ietf-dhc-triggered-reconfigure-= 03 On 26.02.2013 10:34, mohamed.boucadair@orange.com wrote: >> Figure 1 mentions NAS, without explaining what it means. I presume=20 >> that it is Network Access Server, but it is not a common term in DHCP=20 >> world, so it would be good to explain it. >=20 > Med: I added this sentence:=20 > "Figure 1 shows a broadband network scenario in which the Network Access = Server (NAS) embeds a DHCPv6 relay agent." > Do you think the document needs to say more? No. That addition is sufficient. >> Section 2: "Reconfigure message is then sent to the DHCPv6 relay,=20 >> which in turn will forward the message to the appropriate DHCPv6=20 >> client." This reconfigure message will be sent encapsulated in=20 >> Relay-Reply, so it will look like every other message received from a=20 >> server and to be processed by the relay, right? There's no text that=20 >> clarifies that. >=20 > Med: I added this sentence just after the one you quoted:=20 >=20 > "Note, the server encapsulates the Reconfigure message in a Relay-reply m= essage." > Better? Yes. >> Last paragraph is section 2 talks about retransmissions, but do not=20 >> explain how to conduct them if there is no server response. It should=20 >> point out that the details are explained in section 4.3. > Med: The text is now updated to call out Section 4.3.=20 Thanks. >> Section 4.2.1: "Clients MUST silently discard any received=20 >> RECONFIGURE-REQUEST messages.". I would add that logging such an=20 >> event is allowed, though. > Med: Is there any value to log such events in the client side? Sometimes yes. Some clients (e.g. dibbler) will print out a warning message= , when receiving unknown message (basically anything besides advertise or r= eply). Reception of such a message by a client may mean that your network i= s seriously broken or there is an attack in progress. This is really a grey area that nobody cares about. Many clients and server= s log various things when configured with sufficient log levels. If we want to be strict, this is a violation of RFC3315, but I have serious= doubts anyone care about that. So I'm ok if you don't want to do anything = here. >> "The server MUST be configurable to accept or reject RECONFIGURE-=20 >> REQUEST messages." This should probably be moved to "Server behavior" >> section.=20 > Med: Ok for me. Done. Thanks. > Also, you should specify what is the server default if not >> explicitly configured. It should be reject in my opinion. >=20 > Med: I added this sentence:=20 > "If no indication is explicitly configured to the server, the default beh= aviour is to reject RECONFIGURE-REQUEST messages." Ok, great. >> "The relay agent MUST be configurable to accept or reject=20 >> RECONFIGURE- REQUEST messages received from other relay agents.". >> Reconfigure-Request >> is not addressed at relay and it merely helps deliver it to server,=20 >> so instead of "accept or reject" I would use "forward or drop" here. >=20 > Med: I do think both wording would work. "accept" is more generic as forw= arding the message will be the result of other steps than just accept handl= ing the message. I will maintain the initial wording.=20 Ok. >> There should be a separate "Relay behavior" section and second to=20 >> last paragraph in 4.2.1 should be moved to it. >=20 > Med: I added a new section called "Intermediate Relay Agents Behaviour" a= nd moved that text to the new section. Thanks. > There are very good reasons >> for having separate behavior sections for server, relays and client=20 >> There should be one for client as well, even if it contains only one=20 >> sentence about dropping those messages. It makes life of implementors=20 >> much easier and increases chances of wider adoption of that proposal. >> >> The last paragraph in 4.2.1 belongs more in the Server behavior=20 >> section. >=20 > Med: Agree. Ok, thanks. >> Section 4.3 "The relay may receive (Relay-Reply) Reconfigure before..." >> is awkward. It should be "The relay may receive Reconfigure=20 >> encapsulated in Relay-Reply before..." >=20 > Med: Fixed. Thanks. Thanks. >> "The relay agent MUST include a Client Identifier Option..." =3D> "The=20 >> relay agent MUST include one or more Client Identifier Options..." > Med: Fixed.=20 Thanks a lot. This was confusing without this clarification. >> Section 4.4 "Upon receipt of a valid Reconfigure-Request message from=20 >> a >> DHCPv6 relay agent (see Section 4.2), the server determines the >> client(s) for which a Reconfigure message is to be sent.". >> >> Section 4.4, bullet 2 and 3 contradict each other. When relay=20 >> requested reconfigure for 2 clients and one succeeds and the other=20 >> fails, what should be the return status: success or failure code? >=20 > Med: bullet 2 is about partial failure (i.e., there is at least a=20 > success for one client); bullet 3 is when there is failure for all=20 > clients. In the > partial failure case, the list of failed cio are returned also in the=20 > Reconfigure-Ack. >=20 > What if the >> failure reasons are different for each client? It seems that the=20 >> status code returning is not very useful for more than one client. >> >> Section 4.4, bullet 2 says that server must keep list of client-ids=20 >> that it couldn't configure, but does not explain what to do with that=20 >> list. >> Did you mean "include in reconfigure-ack"? If that is so, please=20 >> rephrase that sentence. If you meant something else, please clarify=20 >> as well. >=20 > Med: The text is about Reconfigure-Ack. I fixed the text. Thanks. >> Section 7. You should change the text to say that servers MUST=20 >> discard configure-request unless explicitly configured to accept them=20 >> (or perhaps this should go into server behavior section). It's better=20 >> to be safe than sorry. >=20 > Med: discarding RECONFIGURE-REQUEST messages + configuration options=20 > are already covered in the server behaviour. I prefer Good point. THere's no need to repeat them here. One place is enough. >> Although DUIDs are typically 14 bytes long, the maximum allowed=20 >> length is 128, so we can hit fragementation limit with only 10=20 >> clients. There should be a short clarification that relay should send=20 >> separate reconfigure-requests if there are more clients (or some=20 >> other suggestion what to do if the MTU limit is hit). >=20 > Med: Isn't this covered in the text of Section 4.3:=20 >=20 > If including Client > Identifier Options of all impacted clients exceeds the maximum > message size (see Section 5), the relay MUST generate several > RECONFIGURE-REQUEST messages required to carry all Client Identifier > Options. Rate-limit considerations are discussed in Section 5. Oh, I missed that. Sorry. Yes, the existing text is clear then. >> Reconfigure mechanism is optional. What should the server do if=20 >> client does not support Reconfigure? There's currently no way for=20 >> server to signal that to back to relay. UnspecFail doesn't look=20 >> right. Perhaps NotConfigured would be the right code for it? >=20 > Med: If we need to specific, a new error code need to be defined for=20 > this case. If you think there is a value in specifying that behaviour,=20 > I suggest we define a new error code for it. I don't know. Does the relay can use the information why the reconfigure fa= iled? I suppose there could be some value in making different permanent fai= lures (e.g. the client do not support reconfigure) with some temporary fail= ure that may disappear when repeated reconfigure request is made. But I do = not have any strong opinion on that. Can someone else comment on this as we= ll? >> Excuse my poor understanding of how NAS works, but does it keep DUIDs=20 >> of all clients connected through it? So from the pure DHCP=20 >> perspective, this is a stateful relay, right? If that is so, it=20 >> should be pointed somewhere that the way relay keeps the information=20 >> about clients is outside of scope for this document. >=20 > Med: Section 2 says:=20 >=20 > This setup assumes the relay has a record of the client, so that it > has enough information to send the Reconfigure-Request message to the > server. Means to recover state in failure events must be supported, > but are not discussed in this document. >=20 > I propose to change it to >=20 > This setup assumes the relay has a record of the client, so that it > has enough information to send the Reconfigure-Request message to the > server. How the state is recorded in the relay is out of scope. Furthe= rmore, means to recover state in failure events must be supported, > but are not discussed in this document. Ok. Ok, great. That deals with all my comments. Let's see if anyone else has ad= ditional comments on the status code. I'm ok with leaving it as it is, reus= ing some of the codes from leasequery or defining a new one. After that I think the draft is good to move forward. Cheers, Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg