From dhcwg-admin@ietf.org Mon Mar 1 01:15:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08395; Mon, 1 Mar 2004 01:15:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axghj-0002sb-Pf; Mon, 01 Mar 2004 01:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axgh9-0002mQ-BJ for dhcwg@optimus.ietf.org; Mon, 01 Mar 2004 01:14:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08352 for ; Mon, 1 Mar 2004 01:14:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axgh6-0007EV-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 01:14:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axgg9-00079m-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 01:13:25 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1Axgfs-00075X-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 01:13:08 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 29 Feb 2004 22:11:39 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i216Cb0K011638 for ; Mon, 1 Mar 2004 01:12:38 -0500 (EST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-46.cisco.com [10.86.240.46]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGK32422; Mon, 1 Mar 2004 01:12:35 -0500 (EST) Message-Id: <4.3.2.7.2.20040301010845.02a45d10@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 01 Mar 2004 01:12:31 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Subject: [dhcwg] multicast session for dhc WG meeting Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , It looks like the dhc WG meeting will be multicast. I don't have any details about how to access the session. If someone on the list has a clue about accessing an IETf multicast session, please let us know. The dhc WG meeting is scheduled for Tue, 3/2, 0900-1130 (Seoul). If I have my conversions correct, that time is equivalent to: 3/2 0530 IST 3/2 0000 UTC 3/1 1900 EST 3/1 1600 PST I still don't have a volunteer to act as a jabber scribe, so I can't promise there will be activity on the dhc jabber session during the WG meeting. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 1 08:08:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16947; Mon, 1 Mar 2004 08:08:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axn9N-0000oe-94; Mon, 01 Mar 2004 08:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axn97-0000mL-T1 for dhcwg@optimus.ietf.org; Mon, 01 Mar 2004 08:07:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16926 for ; Mon, 1 Mar 2004 08:07:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axn96-0004qB-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 08:07:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axn8F-0004l6-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 08:06:52 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1Axn7a-0004fR-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 08:06:10 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id i21D5w57018759; Mon, 1 Mar 2004 08:06:07 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Ralph Droms'" , Subject: RE: [dhcwg] multicast session for dhc WG meeting Date: Mon, 1 Mar 2004 08:06:02 -0500 Message-ID: <000001c3ff8d$f64b0890$6601a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <4.3.2.7.2.20040301010845.02a45d10@flask.cisco.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi: There's information at http://videolab.uoregon.edu/ (from a link on the http://www.ietf.org/meetings/meetings.html page). It has links to = downloads, etc for listening to multicast sessions. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Ralph Droms Sent: Monday, March 01, 2004 1:13 AM To: dhcwg@ietf.org Subject: [dhcwg] multicast session for dhc WG meeting It looks like the dhc WG meeting will be multicast. I don't have any details about how to access the session. If someone on the list has a = clue about accessing an IETf multicast session, please let us know. The dhc WG meeting is scheduled for Tue, 3/2, 0900-1130 (Seoul). If I = have my conversions correct, that time is equivalent to: 3/2 0530 IST 3/2 0000 UTC 3/1 1900 EST 3/1 1600 PST I still don't have a volunteer to act as a jabber scribe, so I can't = promise there will be activity on the dhc jabber session during the WG meeting. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 1 08:14:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17437; Mon, 1 Mar 2004 08:14:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxnFC-0001LX-AD; Mon, 01 Mar 2004 08:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxnEw-0001Ky-TL for dhcwg@optimus.ietf.org; Mon, 01 Mar 2004 08:13:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17412 for ; Mon, 1 Mar 2004 08:13:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxnEv-0005bT-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 08:13:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxnE2-0005Wn-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 08:12:51 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AxnDi-0005R9-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 08:12:30 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i21DBv4U009164; Mon, 1 Mar 2004 05:11:58 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-18.cisco.com [10.86.242.18]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGK41739; Mon, 1 Mar 2004 08:11:55 -0500 (EST) Message-Id: <4.3.2.7.2.20040301081115.02a86d80@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 01 Mar 2004 08:11:51 -0500 To: "Bernie Volz" From: Ralph Droms Subject: RE: [dhcwg] multicast session for dhc WG meeting Cc: In-Reply-To: <000001c3ff8d$f64b0890$6601a8c0@BVolz> References: <4.3.2.7.2.20040301010845.02a45d10@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Thanks, Bernie... BTW, last call for a meeting scribe, a jabber scribe and jabber participants... - Ralph At 08:06 AM 3/1/2004 -0500, Bernie Volz wrote: >Hi: > >There's information at http://videolab.uoregon.edu/ (from a link on the >http://www.ietf.org/meetings/meetings.html page). It has links to downloads, >etc for listening to multicast sessions. > >- Bernie > >-----Original Message----- >From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ralph >Droms >Sent: Monday, March 01, 2004 1:13 AM >To: dhcwg@ietf.org >Subject: [dhcwg] multicast session for dhc WG meeting > >It looks like the dhc WG meeting will be multicast. I don't have any >details about how to access the session. If someone on the list has a clue >about accessing an IETf multicast session, please let us know. > >The dhc WG meeting is scheduled for Tue, 3/2, 0900-1130 (Seoul). If I have >my conversions correct, that time is equivalent to: > >3/2 0530 IST >3/2 0000 UTC >3/1 1900 EST >3/1 1600 PST > >I still don't have a volunteer to act as a jabber scribe, so I can't promise >there will be activity on the dhc jabber session during the WG meeting. > >- Ralph > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From mailman-admin@ietf.org Mon Mar 1 09:17:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20964 for ; Mon, 1 Mar 2004 09:17:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxoDh-0007iR-RO for DHC-ARCHIVE@lists.ietf.org; Mon, 01 Mar 2004 09:16:33 -0500 Date: Mon, 01 Mar 2004 09:16:33 -0500 Message-ID: <20040301141633.27462.29794.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: DHC-ARCHIVE@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, dhcwg-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for DHC-ARCHIVE@lists.ietf.org: List Password // URL ---- -------- dhcwg@ietf.org aCBd https://www1.ietf.org/mailman/options/dhcwg/dhc-archive%40lists.ietf.org From dhcwg-admin@ietf.org Mon Mar 1 12:34:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23718; Mon, 1 Mar 2004 12:34:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxrIn-0003Ot-Sx; Mon, 01 Mar 2004 12:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxrIl-0003OH-Ew for dhcwg@optimus.ietf.org; Mon, 01 Mar 2004 12:33:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23701 for ; Mon, 1 Mar 2004 12:33:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxrIj-0007EX-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 12:33:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxrHu-00078b-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 12:33:07 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AxrGz-0006uL-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 12:32:09 -0500 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i21HVWYC015539 for ; Mon, 1 Mar 2004 18:31:33 +0100 (CET) Received: from cadar.office (cadar.office [10.1.1.118]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 5E070C7986 for ; Mon, 1 Mar 2004 18:31:32 +0100 (CET) From: Cristian Cadar Organization: NEC Europe Ltd. To: dhcwg@ietf.org Date: Mon, 1 Mar 2004 18:32:20 +0100 User-Agent: KMail/1.5.4 References: <4.3.2.7.2.20040227113616.01f2b008@flask.cisco.com> In-Reply-To: <4.3.2.7.2.20040227113616.01f2b008@flask.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200403011832.20434.Cristian.Cadar@netlab.nec.de> X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Upcoming DHCPv6 interoperability testing event Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear All, I'm currently organizing another DHCPv6 interoperability testing event. This time it will be in Tokyo on March 22-24. As for the previous one, participation is free of charges. Please see the announcement at: http://dhcpv6.ccrle.nec.de/events.htm Thanks, Cristian _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 1 15:52:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05819; Mon, 1 Mar 2004 15:52:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxuOO-0001Dp-EH; Mon, 01 Mar 2004 15:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxuOJ-0001DT-He for dhcwg@optimus.ietf.org; Mon, 01 Mar 2004 15:51:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05790 for ; Mon, 1 Mar 2004 15:51:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxuOH-0007D6-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 15:51:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxuNI-00076g-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 15:50:52 -0500 Received: from smtp810.mail.sc5.yahoo.com ([66.163.170.80]) by ietf-mx with smtp (Exim 4.12) id 1AxuMJ-0006xr-00 for DHCWG@IETF.ORG; Mon, 01 Mar 2004 15:49:51 -0500 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.88.171 with login) by smtp810.mail.sc5.yahoo.com with SMTP; 1 Mar 2004 20:49:51 -0000 Reply-To: From: "Barr Hibbs" To: Cc: Date: Mon, 1 Mar 2004 12:55:26 -0800 Message-ID: <018a01c3ffcf$873a3d80$11f4a8c0@RanchoSanchez.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [dhcwg] revisions to DHCPv4 Server MIB suggested by MIB "Doctor" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit David Harrington has been assigned to work with Glenn and myself to finalize the proposed DHCPv4 server MIB ("draft-ietf-dhc-server-mib-09.txt"), making sure that it is conformant with current SNMP practice and implementable. David has proposed many improvements to the text, most of which fall into the general category of clarification, which I believe do not require WG approval to incorporate. There are at least two concerns about the proposed MIB that David has expressed which represent significant changes to the MIB. First, the two large portions of the MIB that were declared optional (BOOTP and DHCP optional statistics) and the size of counters used throughout the MIB. Dealing first with counters, the original work which led to the development of the MIB was done on a mainframe computer that supported both 32-bit and 64-bit integers, both signed and unsigned. We collected the server's statistics (actually, our primary reason for developing the MIB) at hourly intervals and even at a prolonged level of traffic in excess of 100 DHCP requests per second received from our client population, the 32-bit counters were sufficient to avoid roll-over during the data collection intervals. At issue now is whether a 32-bit counter is of sufficient size not to roll-over during likely data collection intervals on servers managing the address space for 100s of thousands of clients. If one assumes that 10,000 clients can generate 100 msgs/sec during a mass event, and that the client population is 500,000 for a very large server (5000 msgs/sec), then a 32-bit counter will roll-over in about 10 days. The appropriate questions are, "Can anyone provide better estimates of both maximum number of clients and the peak message arrival rate?" and "What is the longest interval between data collection points that can be reasonably expected?" The answers to both of these questions impact the choice of counter size. The second significant change for which I need WG concurrence is to entirely remove the two large optional sections of the MIB, BOOTP optional statistics and DHCP optional statistics. The last time the structure of the MIB was discussed at a WG meeting, the consensus was to make both sections optional as only a very few implementors or operators were interested in the traffic engineering data that these sections covered. There were no comments about this from the mailing list. Sorry I can't be in Seoul with you all to raise these issues in the meeting. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 1 16:09:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06552; Mon, 1 Mar 2004 16:09:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axues-0002LH-L2; Mon, 01 Mar 2004 16:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axue2-0002CG-DJ for dhcwg@optimus.ietf.org; Mon, 01 Mar 2004 16:08:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06520 for ; Mon, 1 Mar 2004 16:08:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axue0-0001HS-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 16:08:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxudN-0001B0-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 16:07:30 -0500 Received: from smtp.exodus.net ([66.35.230.236]) by ietf-mx with esmtp (Exim 4.12) id 1Axucj-00014I-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 16:06:49 -0500 Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp.exodus.net (8.12.8/8.12.8) with ESMTP id i21MiVw3000667 for ; Mon, 1 Mar 2004 14:44:31 -0800 Received: from [172.16.27.253] (unverified [210.93.162.110]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id for ; Mon, 1 Mar 2004 13:06:18 -0800 Mime-Version: 1.0 X-Sender: margaret@thingmagic.com@ms101.mail1.com Message-Id: Date: Mon, 1 Mar 2004 15:57:57 -0500 To: dhcwg@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [dhcwg] draft-ietf-dhc-dhcpv6-ctep-opt-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi All, In preparing for today's meeting, I read draft-ietf-dhc-dhcpv6-ctep-opt-00.txt. I have two nits and one question, none of which require face-to-face discussion, so I just thought I'd send them to the list. The question actually applies to most DHCP options, not just this one. First, two nits: In the diagram in section 4, the first prefix length is shown as 9 bits long. I think it should be 8 bits long. Also, the text below that diagram does not indicate how the prefix length is expressed. I believe that it is the length of the prefix in bits, but it should say so. Now the question: Most of the DHCP options I've seen have a section like this: > 5. Appearance of this option > > The Configured Tunnel End Point Option MUST NOT appear in other > than the following messages: Solicit, Advertise, Request, Renew, > Rebind, Information-Request and Reply. > > The option numbers of Configured Tunnel End Point option MAY appear > in the Option Request Option [1] in the following messages: Solicit, > Request, Renew, Rebind, Information-Request and Reconfigure. Why is this type of section necessary? Do different options appear in different messages types (the ones I've seen are the same AFAIR). What are the criteria for deciding which types of options can appear in which message types? What happens if they appear in other message types? Either this information is redundant with the base DHCP specifications or it is underspecified, and I'm not sure which. Thanks, Margaret _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 1 18:33:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12975; Mon, 1 Mar 2004 18:33:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxwuD-00008s-7B; Mon, 01 Mar 2004 18:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxwtJ-0008R6-Sf for dhcwg@optimus.ietf.org; Mon, 01 Mar 2004 18:32:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12935 for ; Mon, 1 Mar 2004 18:32:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxwtG-0000vN-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 18:32:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxwsP-0000pc-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 18:31:09 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1AxwrQ-0000dV-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 18:30:08 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HTX0084C7X6CZ@mailout3.samsung.com> for dhcwg@ietf.org; Tue, 02 Mar 2004 08:29:30 +0900 (KST) Received: from ep_ms3_bk (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HTX006IP7WZ6F@mailout3.samsung.com> for dhcwg@ietf.org; Tue, 02 Mar 2004 08:29:23 +0900 (KST) Received: from ep_spt04 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HTX00MCR7WY4A@ms3.samsung.com> for dhcwg@ietf.org; Tue, 02 Mar 2004 08:29:23 +0900 (KST) Content-return: prohibited Date: Mon, 01 Mar 2004 23:29:30 +0000 (GMT) From: PARK SOO HONG Subject: Re :[dhcwg] draft-ietf-dhc-dhcpv6-ctep-opt-00.txt X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9Nb2JpbA==?= =?windows-1252?B?ZSBQbGF0Zm9ybSBMYWI/UmVzZWFyY2hlcg==?= To: Margaret Wasserman , soohong.park@samsung.com Cc: "dhcwg@ietf.org " Reply-to: soohong.park@samsung.com Message-id: <0HTX00MCS7WY4A@ms3.samsung.com> MIME-version: 1.0 Content-type: text/html; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20040301232915091@soohong.park X-MTR: 20040301232915091@soohong.park X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Generator: NamoMIME 1.1.0.14 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE, MIME_HTML_ONLY,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Samsung Enterprise Portal mySingle

 


>In preparing for today's meeting, I read 
>draft-ietf-dhc-dhcpv6-ctep-opt-00.txt.  I have two nits and one 
>question, none of which require face-to-face discussion, so I just 
>thought I'd send them to the list.  The question actually applies to 
>most DHCP options, not just this one.

>First, two nits:

>In the diagram in section 4, the first prefix length is shown as 9 
>bits long.  I think it should be 8 bits long.

 

Yes and it was realligned in the 01 version, but it is not published

because of cutoff date...

 

>Also, the text below that diagram does not indicate how the prefix 
>length is expressed.  I believe that it is the length of the prefix 
>in bits, but it should say so.

 

Ok, I will clarify that point...

 




Regards

 

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics


_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 1 18:45:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13468; Mon, 1 Mar 2004 18:45:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axx5r-0001KK-EA; Mon, 01 Mar 2004 18:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axx5B-0001JN-2N for dhcwg@optimus.ietf.org; Mon, 01 Mar 2004 18:44:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13423 for ; Mon, 1 Mar 2004 18:44:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axx58-0002Nk-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 18:44:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axx4E-0002Gp-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 18:43:23 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1Axx3X-00029Y-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 18:42:40 -0500 Received: from [218.37.226.152] (mdzadpa.dhcp.ietf59.or.kr [218.37.226.152]) by toccata.fugue.com (Postfix) with ESMTP id B4E881D0B81 for ; Mon, 1 Mar 2004 17:39:31 -0600 (CST) Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: <1DE6B612-6BDA-11D8-BB26-000A95D9C74C@nominum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: dhcwg@ietf.org From: Ted Lemon Date: Tue, 2 Mar 2004 08:42:35 +0900 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Comments on draft-ietf-dhc-opt-extrboot-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I was just reading over this draft, and had a couple of minor comments. First, in client behavior, I don't think it's safe for the client to assume that the server supports the bootfile-name and extended remote boot option. The client SHOULD request both the extended and reguler boot options, and leave it to the server to sort it out. The client also needs to implement the hierarchy described in section 6 - if it gets both a bootfile-name and an extended remote boot option, it should prefer the latter. You could address this either by combining sections 6 and 8 or by referring to section 6 in section 8. In the security considerations section, the problems are actually worse than stated - it is possible to supply a valid boot image which will take over a client machine, instead of just doing a denial-of-service attack. One other problem with this option is that it assumes that suboptions will not be combined - that is, that they are not subject to the combination technique described in rfc3396. I'm not sure how to address this, but it's an issue - it complicates server handling of this option. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 2 15:53:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00483; Tue, 2 Mar 2004 15:53:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyGsu-0000Xt-O9; Tue, 02 Mar 2004 15:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqUG-0007NL-HG for dhcwg@optimus.ietf.org; Mon, 01 Mar 2004 11:41:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18339 for ; Mon, 1 Mar 2004 11:41:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxqUE-0006eS-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 11:41:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxqTM-0006Ic-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 11:40:52 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AxqSr-0006Do-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 11:40:21 -0500 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id AC9CC15210; Tue, 2 Mar 2004 01:40:19 +0900 (JST) Date: Tue, 02 Mar 2004 01:40:15 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: vijayak@india.hp.com Cc: dhcwg@ietf.org User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] comments on draft-vijay-dhc-dhcpv6-mcast-reconf-00 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Probably too late for the wg meeting, but I have several comments on draft-vijay-dhc-dhcpv6-mcast-reconf-00. General comments: As an initial impression, I support (the idea of) this document. However, I think some fundamental points need to be discussed. - the document (and the ipv6-icmp-refresh-otherconf draft) assumes that the "O" flag in RA is tightly related to DHCPv6Light. However, this is not clear in the ongoing rfc2462bis work. And, actually, I just proposed at the ipv6 ML that we should rather separate the O flag from DHCPv6Light (the reasons were explained there). - this draft tries to reuse the existing framework, but it seems to me that the attempt causes some inconsistencies. The previous bullet is one of them. The other one is pointed out below at comment item 3. - having considered above point and the current deployment status of DHCPv6 and DHCPv6Light, it might make much more sense to design the mechanism as an explicit extension, rather than to stick to the compatibility with the existing specification and implementation. Technical (non editorial) comments: 1. In Section 4, Even if the Relay doesn't reside in the default router of the link, it should be capable of sending RAs without advertising itself as a default router. => this might cause inconsistency on the content of RAs between that from "real" routers and that from the Relay, which will then cause warnings at routers (and probably at the Relay also) according to Section 6.2.7 of RFC2461. 2. In Section 7.1, - the peer-address doesn't match any of the IPv6 prefixes configured in any of the relay's interfaces and the Interface-id option is not sent. => should the "peer-address" actually be "link-address"? 3. In Section 7.1, The match is done based on longest prefix match. => this matching rule is not always trustworthy, since the relay may have multiple link prefixes with different prefix lengths, like P::/64 and P::/72. What if the server actually wants to specify the former (and it does not know the corresponding interface ID)? Editorial comments: 4. In Section 1, of the of the client, including the address by which the client can => s/of the of the/of the 5. In Section 4, ... administrative domain to have the security association with them for IPv6Sec. => I don't think "IPv6Sec" is not a very appropriate term. IPsec would simply be enough in this case. 6. In Section 5, If the nodes find the O flag in the RA changes form FALSE to TRUE, => s/form/from/ 7. In Section 6.1, peer-address: It should be filled with 0, as this message is not really destined to any client. => I think "filled with 0" can (or even should) simply be "the unspecified address". 8. In Section 6.2, The server continues this process until REC_MAX_RC unsuccessful attempts have been made, => this seems an incomplete sentence. s/,/./ ? 9. In Section 7.2, The relay MUST trigger the router to include the Redo Service Discovery Option in the RAs. => What's the "Redo Service Discovery Option"? Shouldn't this be the "Refresh Other Configuration Option"? 10. In Section 7.3, The Relay prepares an DHCP Reply message with transaction-id copied => s/an/a/ JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 2 15:54:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00566; Tue, 2 Mar 2004 15:54:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyGtt-0000ib-1t; Tue, 02 Mar 2004 15:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyGtb-0000fM-MK for dhcwg@optimus.ietf.org; Tue, 02 Mar 2004 15:53:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00544 for ; Tue, 2 Mar 2004 15:53:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyGta-0004Mx-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 15:53:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyGsb-0004FC-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 15:52:42 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AyGrd-00046g-00 for DHCWG@ietf.org; Tue, 02 Mar 2004 15:51:41 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id i22KpW57018640; Tue, 2 Mar 2004 15:51:40 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: , Cc: Subject: RE: [dhcwg] revisions to DHCPv4 Server MIB suggested by MIB "Doctor" Date: Tue, 2 Mar 2004 15:51:37 -0500 Message-ID: <002001c40098$2a9b5b30$6601a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <018a01c3ffcf$873a3d80$11f4a8c0@RanchoSanchez.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Barr: I don't have a copy of -09 and -10 appears to have already removed the optional statistics and switched to 64 bit counters. I think removing anything optional is fine. The smaller the initial MIB, = the more likely it will be to get deployed. Looks like you also switched most of the counters to 64 bits, so I'm not sure why section 3.3.2, Counter Rollover, is needed? With 64 bits, I = can't see rollovers being likely (even with very infrequent polling). While I believe 32 bits should have been sufficient for counters (since you're not counting bytes), I also see no harm in going to 64 bits. = ASN.1 is a compact representation, so there's really not any penalty over the = wire whether the counter is 32 or 64 bits unless the value itself exceeds 32 bits.=20 So, I'm OK with these changes. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Barr Hibbs Sent: Monday, March 01, 2004 3:55 PM To: DHCWG@ietf.org Cc: dbh@enterasys.com Subject: [dhcwg] revisions to DHCPv4 Server MIB suggested by MIB = "Doctor" David Harrington has been assigned to work with Glenn and myself to finalize the proposed DHCPv4 server MIB ("draft-ietf-dhc-server-mib-09.txt"), making sure that it is conformant with current SNMP practice and implementable. David has proposed many improvements to the text, most of which fall into the general category of clarification, which I believe do not require WG approval to incorporate. There are at least two concerns about the proposed MIB that David has expressed which represent significant changes to the MIB. First, the two large portions of the MIB that were declared optional (BOOTP and DHCP optional statistics) and the size of counters used throughout the MIB. Dealing first with counters, the original work which led to the development of the MIB was done on a mainframe computer that supported both 32-bit and 64-bit integers, both signed and unsigned. We collected the server's statistics (actually, our primary reason for developing the MIB) at hourly intervals and even at a prolonged level of traffic in excess of 100 DHCP requests per second received from our client population, the 32-bit counters were sufficient to avoid roll-over during the data collection intervals. At issue now is whether a 32-bit counter is of sufficient size not to roll-over during likely data collection intervals on servers managing the address space for 100s of thousands of clients. If one assumes that 10,000 clients can generate 100 msgs/sec during a mass event, and that the client population is 500,000 for a very large server (5000 msgs/sec), then a 32-bit counter will roll-over in about 10 days. The appropriate questions are, "Can anyone provide better estimates of both maximum number of clients and the peak message arrival rate?" and "What is the longest interval between data collection points that can be reasonably expected?" The answers to both of these questions impact the choice of counter size. The second significant change for which I need WG concurrence is to entirely remove the two large optional sections of the MIB, BOOTP optional statistics and DHCP optional statistics. The last time the structure of the MIB was discussed at a WG meeting, the consensus was to make both sections optional as only a very few implementors or operators were interested in the traffic engineering data that these sections covered. There were no comments about this from the mailing list. Sorry I can't be in Seoul with you all to raise these issues in the meeting. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 2 16:32:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02044; Tue, 2 Mar 2004 16:32:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyHUf-0004y0-CN; Tue, 02 Mar 2004 16:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyHUS-0004x4-OV for dhcwg@optimus.ietf.org; Tue, 02 Mar 2004 16:31:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02036 for ; Tue, 2 Mar 2004 16:31:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyHUQ-0001ed-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 16:31:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyHTT-0001WG-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 16:30:48 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1AyHSa-0001Nv-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 16:29:52 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by pan.gwi.net (8.12.6p3/8.12.6) with ESMTP id i22LTgGn010435; Tue, 2 Mar 2004 16:29:52 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "=?iso-8859-1?B?J0pJTk1FSSBUYXR1eWEgLyCQXy2+J0KNxic=?=" , Cc: Subject: RE: [dhcwg] comments on draft-vijay-dhc-dhcpv6-mcast-reconf-00 Date: Tue, 2 Mar 2004 16:29:46 -0500 Message-ID: <002a01c4009d$804864b0$6601a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable FYI - For those that don't want to spend the 5 to 10 minutes I did = looking for Jinmei's email, I think he was referring to: http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01798.ht= ml - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = JINMEI Tatuya / =90_=96=BE=92B=8D=C6 Sent: Monday, March 01, 2004 11:40 AM To: vijayak@india.hp.com Cc: dhcwg@ietf.org Subject: [dhcwg] comments on draft-vijay-dhc-dhcpv6-mcast-reconf-00 Probably too late for the wg meeting, but I have several comments on draft-vijay-dhc-dhcpv6-mcast-reconf-00. General comments: As an initial impression, I support (the idea of) this document. However, I think some fundamental points need to be discussed. - the document (and the ipv6-icmp-refresh-otherconf draft) assumes that the "O" flag in RA is tightly related to DHCPv6Light. However, this is not clear in the ongoing rfc2462bis work. And, actually, I just proposed at the ipv6 ML that we should rather separate the O flag from DHCPv6Light (the reasons were explained there). - this draft tries to reuse the existing framework, but it seems to me that the attempt causes some inconsistencies. The previous bullet is one of them. The other one is pointed out below at comment item 3. - having considered above point and the current deployment status of DHCPv6 and DHCPv6Light, it might make much more sense to design the mechanism as an explicit extension, rather than to stick to the compatibility with the existing specification and implementation. Technical (non editorial) comments: 1. In Section 4, Even if the Relay doesn't reside in the default router of the link, it should be capable of sending RAs without advertising itself as a default router. =3D> this might cause inconsistency on the content of RAs between that from "real" routers and that from the Relay, which will then cause warnings at routers (and probably at the Relay also) according to Section 6.2.7 of RFC2461. 2. In Section 7.1, - the peer-address doesn't match any of the IPv6 prefixes configured in any of the relay's interfaces and the Interface-id option is not sent. =3D> should the "peer-address" actually be "link-address"? 3. In Section 7.1, The match is done based on longest prefix match. =3D> this matching rule is not always trustworthy, since the relay may have multiple link prefixes with different prefix lengths, like P::/64 and P::/72. What if the server actually wants to specify the former (and it does not know the corresponding interface ID)? Editorial comments: 4. In Section 1, of the of the client, including the address by which the client can =3D> s/of the of the/of the 5. In Section 4, ... administrative domain to have the security association with them for IPv6Sec. =3D> I don't think "IPv6Sec" is not a very appropriate term. IPsec would simply be enough in this case. 6. In Section 5, If the nodes find the O flag in the RA changes form FALSE to TRUE, =3D> s/form/from/ 7. In Section 6.1, peer-address: It should be filled with 0, as this message is not really destined to any client. =3D> I think "filled with 0" can (or even should) simply be "the unspecified address". 8. In Section 6.2, The server continues this process until REC_MAX_RC unsuccessful attempts have been made, =3D> this seems an incomplete sentence. s/,/./ ? 9. In Section 7.2, The relay MUST trigger the router to include the Redo Service Discovery Option in the RAs. =3D> What's the "Redo Service Discovery Option"? Shouldn't this be the "Refresh Other Configuration Option"? 10. In Section 7.3, The Relay prepares an DHCP Reply message with transaction-id copied =3D> s/an/a/ JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 2 16:39:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00484; Tue, 2 Mar 2004 15:53:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyGsv-0000Y1-64; Tue, 02 Mar 2004 15:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyTK-0004gB-RF for dhcwg@optimus.ietf.org; Mon, 01 Mar 2004 20:13:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18347 for ; Mon, 1 Mar 2004 20:13:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyTI-0004ul-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 20:13:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxySK-0004mO-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 20:12:20 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AxyRQ-0004ea-00 for dhcwg@ietf.org; Mon, 01 Mar 2004 20:11:24 -0500 Received: from ocean.jinmei.org (unknown [2001:220:101a:224:202:2dff:fe6a:d20]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2DC5315210; Tue, 2 Mar 2004 10:11:24 +0900 (JST) Date: Tue, 02 Mar 2004 10:11:08 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Tim Chown Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Renumbering Requirements for Stateless DHCPv6 In-Reply-To: <20040210134549.GC15972@login.ecs.soton.ac.uk> References: <20040210134549.GC15972@login.ecs.soton.ac.uk> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Tue, 10 Feb 2004 13:45:49 +0000, >>>>> Tim Chown said: > There have not been any list comments on a draft that I wrote with Stig and > A.K. after Minneapolis on the issue of how nodes using DHCPv6 only for non > address configuration options should leanr ofconfiguration changes. > http://www.ietf.org/internet-drafts/draft-chown-dhc-stateless-dhcpv6-renumbering-00.txt I've read the draft, and don't see a major problem in it. One minor comment: the draft repeatedly say there should be no additional security concerns in actual proposals to address the renumbering issues: In Section 4, it says The solution should also be secure, such that additional security concerns are not added to the stateless DHCPv6 networking environment. And in Section 7, it says However, whatever mechanism is designed or chosen to address this problem should avoid the introduction of new security concerns for (stateless) DHCPv6. I have sympathy for you here, but is this actually a clear and realistic requirement? In fact, draft-venaas-dhc-lifetime-01.txt, which is expected to be a proposal to address the renumbering issue, has the following security concern: An attacker could send a fake DHCP reply with a very low lifetime value. This could make a client request new data almost immediately. The value is however not kept when the next request is made. Regarding the clarity, I'm not sure by this consideration if an additional security concern is not added. Regarding the reality, I guess it is likely to see some security concerns in actual proposals, since the proposals would be a protocol extension that affects a core part of the base specification. I don't think this comment is a technical issue though. This is probably a matter of wording. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 2 17:18:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04369; Tue, 2 Mar 2004 17:18:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyIDB-0000Zd-14; Tue, 02 Mar 2004 17:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyICc-0000V1-OH for dhcwg@optimus.ietf.org; Tue, 02 Mar 2004 17:17:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04235 for ; Tue, 2 Mar 2004 17:17:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyICa-0000NU-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 17:17:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyIB7-00009F-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 17:15:53 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1AyIAB-0007iA-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 17:14:55 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i22MDw9u016986; Tue, 2 Mar 2004 14:14:10 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Mar 2004 14:13:58 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C682@MONTEREY.netscreen.com> From: Changming Liu To: "'JINMEI Tatuya / ???? '" , "'Tim Chown '" Cc: "'dhcwg@ietf.org '" Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Tue, 2 Mar 2004 14:13:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-2022-jp" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This draft comes at the exact time we need it. We just implemeneted DHCP server and client and one of our big customers run into this reconfig issue in their planned deployment right away! I wish I would have read it early. The scenario is different from the two described in section 3. Our customer runs DHCP clients on two unpstream interfaces and DHCP server on on downstream interface which connects to a LAN with PCs, etc, The DHCP is used just to pass configuration info . Depending on the availaibility of upstream routers which have different DNS server setup among other configs, the DHCP server needs to update DNS to the LAN immediately to avoid service outage. Note that these DNS servers are in different zones. This, to my opinion, should be another major scenario: dynamic change of config info. In section 5, among three proposed mechanisms, to me, only 1) looks viable. Multicast support should not be any issue anyway. Is it true that the entire stateless auto-config and ND are based on that? The only concern may be security for forged reconfigure message. But this is a more generic issue than just for reconfigure message itself. Or am I missing something? The lifetime has several significant drawbacks. The first one is how to engineer the lifetime value? A difficult choice. if too long it will cause too long delay, which is unacceptable for service shortage. if too short, it may cause periodic storms of request/replies. This itself sounds like a attack to me. The second one is the maintenance effort for both server and client to maintain these timers as someone pointed out in the meeting. The third option looks better, but it won't work between upstream router and downstream router using DHCPv6 to pass auto-config info. The draft requires the DHCP relay which may not exist in the scenario I just described. I guess, actually, the debate, if any, will boil down to event-driven or polling? which is better and efficient? Agree? Changming Liu Netscreen Technologies Inc. -----Original Message----- From: JINMEI Tatuya / ???? To: Tim Chown Cc: dhcwg@ietf.org Sent: 3/1/2004 5:11 PM Subject: Re: [dhcwg] Renumbering Requirements for Stateless DHCPv6 >>>>> On Tue, 10 Feb 2004 13:45:49 +0000, >>>>> Tim Chown said: > There have not been any list comments on a draft that I wrote with Stig and > A.K. after Minneapolis on the issue of how nodes using DHCPv6 only for non > address configuration options should leanr ofconfiguration changes. > http://www.ietf.org/internet-drafts/draft-chown-dhc-stateless-dhcpv6-ren umbering-00.txt I've read the draft, and don't see a major problem in it. One minor comment: the draft repeatedly say there should be no additional security concerns in actual proposals to address the renumbering issues: In Section 4, it says The solution should also be secure, such that additional security concerns are not added to the stateless DHCPv6 networking environment. And in Section 7, it says However, whatever mechanism is designed or chosen to address this problem should avoid the introduction of new security concerns for (stateless) DHCPv6. I have sympathy for you here, but is this actually a clear and realistic requirement? In fact, draft-venaas-dhc-lifetime-01.txt, which is expected to be a proposal to address the renumbering issue, has the following security concern: An attacker could send a fake DHCP reply with a very low lifetime value. This could make a client request new data almost immediately. The value is however not kept when the next request is made. Regarding the clarity, I'm not sure by this consideration if an additional security concern is not added. Regarding the reality, I guess it is likely to see some security concerns in actual proposals, since the proposals would be a protocol extension that affects a core part of the base specification. I don't think this comment is a technical issue though. This is probably a matter of wording. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 2 17:28:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04985; Tue, 2 Mar 2004 17:28:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyIMr-0002Qa-4k; Tue, 02 Mar 2004 17:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyIMf-0002Q7-JB for dhcwg@optimus.ietf.org; Tue, 02 Mar 2004 17:27:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04970 for ; Tue, 2 Mar 2004 17:27:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyIMd-0002C5-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 17:27:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyILh-00022M-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 17:26:50 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1AyIKq-0001l6-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 17:25:56 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i22MPI9u017686; Tue, 2 Mar 2004 14:25:23 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Mar 2004 14:25:18 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C684@MONTEREY.netscreen.com> From: Changming Liu To: "'JINMEI Tatuya / ???? '" , "'vijayak@india.hp.com '" Cc: "'dhcwg@ietf.org '" Subject: RE: [dhcwg] comments on draft-vijay-dhc-dhcpv6-mcast-reconf-00 Date: Tue, 2 Mar 2004 14:25:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-2022-jp" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The major concern I have with this draft is the relay assumption and RA applicability. In the case there is no relay, this still sould work. Please see my previous emails for such a scenario. Can RA be used between routers? Can DHCPv6 used between two routers, say one PE and one CPE? Changming Liu -----Original Message----- From: JINMEI Tatuya / ???? To: vijayak@india.hp.com Cc: dhcwg@ietf.org Sent: 3/1/2004 8:40 AM Subject: [dhcwg] comments on draft-vijay-dhc-dhcpv6-mcast-reconf-00 Probably too late for the wg meeting, but I have several comments on draft-vijay-dhc-dhcpv6-mcast-reconf-00. General comments: As an initial impression, I support (the idea of) this document. However, I think some fundamental points need to be discussed. - the document (and the ipv6-icmp-refresh-otherconf draft) assumes that the "O" flag in RA is tightly related to DHCPv6Light. However, this is not clear in the ongoing rfc2462bis work. And, actually, I just proposed at the ipv6 ML that we should rather separate the O flag from DHCPv6Light (the reasons were explained there). - this draft tries to reuse the existing framework, but it seems to me that the attempt causes some inconsistencies. The previous bullet is one of them. The other one is pointed out below at comment item 3. - having considered above point and the current deployment status of DHCPv6 and DHCPv6Light, it might make much more sense to design the mechanism as an explicit extension, rather than to stick to the compatibility with the existing specification and implementation. Technical (non editorial) comments: 1. In Section 4, Even if the Relay doesn't reside in the default router of the link, it should be capable of sending RAs without advertising itself as a default router. => this might cause inconsistency on the content of RAs between that from "real" routers and that from the Relay, which will then cause warnings at routers (and probably at the Relay also) according to Section 6.2.7 of RFC2461. 2. In Section 7.1, - the peer-address doesn't match any of the IPv6 prefixes configured in any of the relay's interfaces and the Interface-id option is not sent. => should the "peer-address" actually be "link-address"? 3. In Section 7.1, The match is done based on longest prefix match. => this matching rule is not always trustworthy, since the relay may have multiple link prefixes with different prefix lengths, like P::/64 and P::/72. What if the server actually wants to specify the former (and it does not know the corresponding interface ID)? Editorial comments: 4. In Section 1, of the of the client, including the address by which the client can => s/of the of the/of the 5. In Section 4, ... administrative domain to have the security association with them for IPv6Sec. => I don't think "IPv6Sec" is not a very appropriate term. IPsec would simply be enough in this case. 6. In Section 5, If the nodes find the O flag in the RA changes form FALSE to TRUE, => s/form/from/ 7. In Section 6.1, peer-address: It should be filled with 0, as this message is not really destined to any client. => I think "filled with 0" can (or even should) simply be "the unspecified address". 8. In Section 6.2, The server continues this process until REC_MAX_RC unsuccessful attempts have been made, => this seems an incomplete sentence. s/,/./ ? 9. In Section 7.2, The relay MUST trigger the router to include the Redo Service Discovery Option in the RAs. => What's the "Redo Service Discovery Option"? Shouldn't this be the "Refresh Other Configuration Option"? 10. In Section 7.3, The Relay prepares an DHCP Reply message with transaction-id copied => s/an/a/ JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 2 18:03:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06212; Tue, 2 Mar 2004 18:03:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyIui-0007ej-VW; Tue, 02 Mar 2004 18:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyIuY-0007SZ-3B for dhcwg@optimus.ietf.org; Tue, 02 Mar 2004 18:02:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06149 for ; Tue, 2 Mar 2004 18:02:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyIuV-0006iU-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 18:02:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyItg-0006ag-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 18:01:56 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1AyIsh-0006L3-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 18:00:55 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i22N0I9u023969 for ; Tue, 2 Mar 2004 15:00:25 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Mar 2004 15:00:18 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C687@MONTEREY.netscreen.com> From: Changming Liu To: "'dhcwg@ietf.org'" Date: Tue, 2 Mar 2004 15:00:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [dhcwg] [dhcwg] Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Just read the entire draft. The first comment I have is that this is great idea. This complements PD where the fixing mapping is required. (like bootp vs. DHCP but in block of addresses instead of a single address?) Another comement is that because the proxy server can have several blocks assigned from the server, this makes the decision of the block size much easier. Even small block size like 8 can still dramatically reduce the routing entries. Author should mention this in the draft. Changming Liu _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 2 18:08:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06828; Tue, 2 Mar 2004 18:08:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyIzZ-0001BM-Dm; Tue, 02 Mar 2004 18:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyIzT-00019A-DB for dhcwg@optimus.ietf.org; Tue, 02 Mar 2004 18:07:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06766 for ; Tue, 2 Mar 2004 18:07:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyIzQ-0007Sv-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 18:07:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyIyZ-0007La-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 18:07:00 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AyIy0-0007DU-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 18:06:24 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id i22N6G57053142; Tue, 2 Mar 2004 18:06:25 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "=?iso-8859-1?Q?'JINMEI_Tatuya_/_=90=5F-=BE'B=8D=C6'?=" , Cc: Subject: RE: [dhcwg] comments on draft-vijay-dhc-dhcpv6-mcast-reconf-00 Date: Tue, 2 Mar 2004 18:06:15 -0500 Message-ID: <002b01c400aa$fc7b5d00$6601a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <002a01c4009d$804864b0$6601a8c0@BVolz> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Regarding Jinmei's msg01798: - I agree that DHCPv6 should be the stateful protocol (question c). - I don't agree that DHCPv6light should not be controlled by the 'O' = flag in a RA (question d). Personally, I think it a good thing for hosts to be silent on any = protocol unless explicitly configured to run it. So, avoiding periodic Information-Request messages on all IPv6 networks, especially simple networks, is IMHO a good thing. Also, from RFC 2462, we have: "In addition, when the value of the ManagedFlag is TRUE, the value of OtherConfigFlag is implicitely TRUE as well." This would seem to me to very closely tie the "M" (Managed) and = "O" (Other) configuration protocols - if they are completely separate, why connect them at all? - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Bernie Volz Sent: Tuesday, March 02, 2004 4:30 PM To: 'JINMEI Tatuya / =90_-=BE'B=8D=C6'; vijayak@india.hp.com Cc: dhcwg@ietf.org Subject: RE: [dhcwg] comments on draft-vijay-dhc-dhcpv6-mcast-reconf-00 FYI - For those that don't want to spend the 5 to 10 minutes I did = looking for Jinmei's email, I think he was referring to: http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01798.ht= ml - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = JINMEI Tatuya / =90_=96=BE=92B=8D=C6 Sent: Monday, March 01, 2004 11:40 AM To: vijayak@india.hp.com Cc: dhcwg@ietf.org Subject: [dhcwg] comments on draft-vijay-dhc-dhcpv6-mcast-reconf-00 Probably too late for the wg meeting, but I have several comments on draft-vijay-dhc-dhcpv6-mcast-reconf-00. General comments: As an initial impression, I support (the idea of) this document. However, I think some fundamental points need to be discussed. - the document (and the ipv6-icmp-refresh-otherconf draft) assumes that the "O" flag in RA is tightly related to DHCPv6Light. However, this is not clear in the ongoing rfc2462bis work. And, actually, I just proposed at the ipv6 ML that we should rather separate the O flag from DHCPv6Light (the reasons were explained there). - this draft tries to reuse the existing framework, but it seems to me that the attempt causes some inconsistencies. The previous bullet is one of them. The other one is pointed out below at comment item 3. - having considered above point and the current deployment status of DHCPv6 and DHCPv6Light, it might make much more sense to design the mechanism as an explicit extension, rather than to stick to the compatibility with the existing specification and implementation. Technical (non editorial) comments: 1. In Section 4, Even if the Relay doesn't reside in the default router of the link, it should be capable of sending RAs without advertising itself as a default router. =3D> this might cause inconsistency on the content of RAs between that from "real" routers and that from the Relay, which will then cause warnings at routers (and probably at the Relay also) according to Section 6.2.7 of RFC2461. 2. In Section 7.1, - the peer-address doesn't match any of the IPv6 prefixes configured in any of the relay's interfaces and the Interface-id option is not sent. =3D> should the "peer-address" actually be "link-address"? 3. In Section 7.1, The match is done based on longest prefix match. =3D> this matching rule is not always trustworthy, since the relay may have multiple link prefixes with different prefix lengths, like P::/64 and P::/72. What if the server actually wants to specify the former (and it does not know the corresponding interface ID)? Editorial comments: 4. In Section 1, of the of the client, including the address by which the client can =3D> s/of the of the/of the 5. In Section 4, ... administrative domain to have the security association with them for IPv6Sec. =3D> I don't think "IPv6Sec" is not a very appropriate term. IPsec would simply be enough in this case. 6. In Section 5, If the nodes find the O flag in the RA changes form FALSE to TRUE, =3D> s/form/from/ 7. In Section 6.1, peer-address: It should be filled with 0, as this message is not really destined to any client. =3D> I think "filled with 0" can (or even should) simply be "the unspecified address". 8. In Section 6.2, The server continues this process until REC_MAX_RC unsuccessful attempts have been made, =3D> this seems an incomplete sentence. s/,/./ ? 9. In Section 7.2, The relay MUST trigger the router to include the Redo Service Discovery Option in the RAs. =3D> What's the "Redo Service Discovery Option"? Shouldn't this be the "Refresh Other Configuration Option"? 10. In Section 7.3, The Relay prepares an DHCP Reply message with transaction-id copied =3D> s/an/a/ JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 2 19:04:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10947; Tue, 2 Mar 2004 19:04:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyJrl-0003XD-22; Tue, 02 Mar 2004 19:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyJqn-0003SV-8x for dhcwg@optimus.ietf.org; Tue, 02 Mar 2004 19:03:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10869 for ; Tue, 2 Mar 2004 19:02:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyJqk-0000Dl-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 19:02:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyJpw-00004F-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 19:02:09 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AyJpA-0007iW-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 19:01:20 -0500 Received: from [218.37.226.152] (mdzadpa.wireless.ietf59.or.kr [218.37.226.152]) by toccata.fugue.com (Postfix) with ESMTP id F09F31EFF4E; Tue, 2 Mar 2004 17:57:57 -0600 (CST) In-Reply-To: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C682@MONTEREY.netscreen.com> References: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C682@MONTEREY.netscreen.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'JINMEI Tatuya / ???? '" , "'dhcwg@ietf.org '" , "'Tim Chown '" From: Ted Lemon Subject: Re: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Wed, 3 Mar 2004 09:01:13 +0900 To: Changming Liu X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Why would the lifetime solution cause packet storms? We don't have similar problems with similar protocols. Choosing a lifetime is easy, and you can adjust the lifetime when you plan a change. I don't understand the objection. Reconfigure would work, but it opens a vulnerability on the client (which now has to be listening for DHCP messages all the time), and requires a lot more infrastructure support than the lifetime solution. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 2 20:35:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18617; Tue, 2 Mar 2004 20:35:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLHt-0001Yt-3K; Tue, 02 Mar 2004 20:35:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLH0-0001SI-Ep for dhcwg@optimus.ietf.org; Tue, 02 Mar 2004 20:34:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18465 for ; Tue, 2 Mar 2004 20:34:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyLGy-0007lv-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 20:34:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyLGK-0007aW-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 20:33:28 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1AyLEr-00076G-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 20:31:57 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i231VI9u003173; Tue, 2 Mar 2004 17:31:18 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Mar 2004 17:31:18 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C689@MONTEREY.netscreen.com> From: Changming Liu To: "'Ted Lemon '" , Changming Liu Cc: "''JINMEI Tatuya / ???? ' '" , "''dhcwg@ietf.org ' '" , "''Tim Chown ' '" Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Tue, 2 Mar 2004 17:31:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , For unplanned change, how can you set the lifetime? The solution should work for both planned and unplanned changes. The unplanned changes are more demanding. Please see the scenario described in my previous email. For reconfig, we already have one defined, but unicast only. So the infrastruture should be there. It only problem is it's unicast which does not scale well. The problem is well defined in this draft and no need to repeat here. Changming -----Original Message----- From: Ted Lemon To: Changming Liu Cc: 'JINMEI Tatuya / ???? '; 'dhcwg@ietf.org '; 'Tim Chown ' Sent: 3/2/2004 4:01 PM Subject: Re: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Why would the lifetime solution cause packet storms? We don't have similar problems with similar protocols. Choosing a lifetime is easy, and you can adjust the lifetime when you plan a change. I don't understand the objection. Reconfigure would work, but it opens a vulnerability on the client (which now has to be listening for DHCP messages all the time), and requires a lot more infrastructure support than the lifetime solution. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 2 21:27:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21773; Tue, 2 Mar 2004 21:27:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyM6B-0001gt-71; Tue, 02 Mar 2004 21:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyM65-0001fv-Jm for dhcwg@optimus.ietf.org; Tue, 02 Mar 2004 21:26:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21725 for ; Tue, 2 Mar 2004 21:26:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyM62-0000Cy-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 21:26:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyM56-00004M-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 21:25:57 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1AyM4A-0007dU-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 21:24:58 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i232OS9u006136 for ; Tue, 2 Mar 2004 18:24:29 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Mar 2004 18:24:28 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C68F@MONTEREY.netscreen.com> From: Changming Liu To: "'dhcwg@ietf.org'" Subject: [dhcwg] draft-chown-dhc-dual-stack-00 Date: Tue, 2 Mar 2004 18:24:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I've read the draft and I agree that there is an issue. But this issue is not a protocol related per say but local administative one because It can be simply solved buy the local configuration. Lots of folks also come from routing world. There may be several IGP running in one AS such as RIP/OSPF. The same route (the equilvent config info in DHCP case) can be learned by RIP and OSPF. How does the router solve this preblom? Nobody has suggested to change the routing protocol. The problem is solved by Administrative Distance in case of Cisco and other vendors use similar approach. It becomes purely a local matter. One way to solve this problem, similar to routing, is to assign a repference to each DHCP instance. This can be done in two ways, either on the client or on the server. If on the server, the DHCP protocols need to be enhanced to carry this info in the message so that client can make informed decision. The drawback is, how can you con-ordinate the settings of DHCP servers especially when they may be multi-homed? Another way is that DHCP client implementation should be flexible enough to allow the local admin to assign the value to each DHCP client if multiple clients exist. This waay, it becomes a completely local matter. BTW we have implemented both DHCPv4 and DHCPv6 client and server on our dual-stack devices and we offer the user the preference options. Just another way to look at this problem. Changming Liu Netscreen technologies. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 2 22:14:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25035; Tue, 2 Mar 2004 22:14:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyMpd-0000n0-Q1; Tue, 02 Mar 2004 22:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyMoq-0000YD-Fo for dhcwg@optimus.ietf.org; Tue, 02 Mar 2004 22:13:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24980 for ; Tue, 2 Mar 2004 22:13:08 -0500 (EST) From: matthew.ford@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyMon-0000MY-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 22:13:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyMnE-0007fu-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 22:11:33 -0500 Received: from smtp5.smtp.bt.com ([217.32.164.139] helo=i2kc05-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1AyMkt-00070H-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 22:09:07 -0500 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by i2kc05-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Mar 2004 03:08:37 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Mar 2004 03:08:37 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Wed, 3 Mar 2004 03:08:37 -0000 Message-ID: <0AAF93247C75E3408638B965DEE11A7005E3CC4B@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Thread-Index: AcQAv+K+1OE5RS8xTIKU9RjtdEC0PAADFxtQ To: , Cc: , , X-OriginalArrivalTime: 03 Mar 2004 03:08:37.0508 (UTC) FILETIME=[D2512C40:01C400CC] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Changming,=20 > For unplanned change, how can you set the lifetime? The=20 > solution should work for both planned and unplanned changes.=20 > The unplanned changes are more demanding. Please see the=20 > scenario described in my previous email. I don't agree at all. There is no requirement to work in the event of unplanned events - it would be nice, but I don't agree that it is required. There will always be breakage in the case of unplanned events, which is precisely why operators try to avoid them. I think we are deluded if we think that there is a solution out there that could be guaranteed to work in the case of an unplanned event. Given that, lifetimes are necessary and sufficient in my opinion. > For reconfig, we already have one defined, but unicast only.=20 > So the infrastruture should be there. Why require infrastructure when it isn't necessary? =20 > It only problem is it's unicast which does not scale well.=20 > The problem is well defined in this draft and no need to repeat here. Unicast doesn't scale and multicast is difficult to secure - that's the bind that reconfig is in. Mat _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 2 22:44:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26237; Tue, 2 Mar 2004 22:44:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNIg-0008FD-8p; Tue, 02 Mar 2004 22:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNHr-0008Cn-Ek for dhcwg@optimus.ietf.org; Tue, 02 Mar 2004 22:43:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26215 for ; Tue, 2 Mar 2004 22:43:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyNHo-0004UB-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 22:43:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyNGr-0004MU-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 22:42:09 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AyNGN-0004Dt-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 22:41:39 -0500 Received: from [211.40.60.224] (unknown [211.40.60.224]) by toccata.fugue.com (Postfix) with ESMTP id 548611D0C1B; Tue, 2 Mar 2004 21:38:11 -0600 (CST) In-Reply-To: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C689@MONTEREY.netscreen.com> References: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C689@MONTEREY.netscreen.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9A5AAD62-6CC4-11D8-B45B-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: "''JINMEI Tatuya / ???? ' '" , "''dhcwg@ietf.org ' '" , "''Tim Chown ' '" From: Ted Lemon Subject: Re: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Wed, 3 Mar 2004 12:41:06 +0900 To: Changming Liu X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mar 3, 2004, at 10:31 AM, Changming Liu wrote: > For unplanned change, how can you set the lifetime? The solution > should > work for both planned and unplanned changes. The unplanned changes are > more > demanding. Please see the scenario described in my previous email. Your scenario seems like a configuration error. Setting things up so that the client has to update DNS server information immediately on a frequent basis is simply bad network design. I don't think the goal of this renumbering effort is to accommodate that kind of configuration. The right way to fix this is to put a DNS cache downstream of the flaky link. It's true that the mass-reconfigure solution would make your problem less bad, but it wouldn't make it go away - your clients would still experience flakiness. The reason is that, first of all, a running application may not notice that the configuration has changed, even if the client on which it is running gets a Reconfigure and successfully reconfigures. Secondly, there is always going to be a time lag between when your network configuration changes and when all the clients have been reconfigured. This lag is the sum of the time it takes for your system to notice that the network configuration has changed and the time that it takes for any given client to actually complete the reconfiguration process after it has been notified. During this window, all DNS lookups will fail, even for new applications that haven't cached DNS server information. So I think that your scenario isn't actually a good justification for doing reconfigure - yes, reconfigure makes it less bad, but no, it doesn't solve the problem. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 2 22:45:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26313; Tue, 2 Mar 2004 22:45:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNJd-0000CZ-GT; Tue, 02 Mar 2004 22:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNIq-0008IS-Ig for dhcwg@optimus.ietf.org; Tue, 02 Mar 2004 22:44:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26234 for ; Tue, 2 Mar 2004 22:44:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyNIn-0004cG-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 22:44:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyNHr-0004Up-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 22:43:12 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AyNH9-0004Mh-00 for dhcwg@ietf.org; Tue, 02 Mar 2004 22:42:27 -0500 Received: from [211.40.60.224] (unknown [211.40.60.224]) by toccata.fugue.com (Postfix) with ESMTP id 146AB1B25B0; Tue, 2 Mar 2004 21:39:07 -0600 (CST) In-Reply-To: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C68F@MONTEREY.netscreen.com> References: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C68F@MONTEREY.netscreen.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'dhcwg@ietf.org'" From: Ted Lemon Subject: Re: [dhcwg] draft-chown-dhc-dual-stack-00 Date: Wed, 3 Mar 2004 12:42:25 +0900 To: Changming Liu X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mar 3, 2004, at 11:24 AM, Changming Liu wrote: > BTW we have implemented both DHCPv4 and DHCPv6 client and server on our > dual-stack devices and we offer the user the preference options. That's very helpful information. It would be wonderful if you could write a more detailed description of the problems you've run into and the ways you've solved them. One of the problems we have right now is that most people in the working group do not have any operational experience with this. Thanks! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 01:45:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06305; Wed, 3 Mar 2004 01:45:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQ7s-0001fE-4T; Wed, 03 Mar 2004 01:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQ71-0001Xz-Tb for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 01:44:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06279 for ; Wed, 3 Mar 2004 01:44:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQ6y-0001VX-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 01:44:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQ62-0001OV-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 01:43:10 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1AyQ5T-0001G6-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 01:42:35 -0500 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i236fqBv010646; Wed, 3 Mar 2004 07:41:52 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i236foSD023396; Wed, 3 Mar 2004 07:41:50 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 3 Mar 2004 07:41:49 +0100 From: Stig Venaas To: Ted Lemon Cc: Changming Liu , "''JINMEI Tatuya / ???? ' '" , "''dhcwg@ietf.org ' '" , "''Tim Chown ' '" Subject: Re: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Message-ID: <20040303064149.GA23360@sverresborg.uninett.no> References: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C689@MONTEREY.netscreen.com> <9A5AAD62-6CC4-11D8-B45B-000A95D9C74C@fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9A5AAD62-6CC4-11D8-B45B-000A95D9C74C@fugue.com> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Wed, Mar 03, 2004 at 12:41:06PM +0900, Ted Lemon wrote: > On Mar 3, 2004, at 10:31 AM, Changming Liu wrote: > > For unplanned change, how can you set the lifetime? The solution > >should > >work for both planned and unplanned changes. The unplanned changes are > >more > >demanding. Please see the scenario described in my previous email. > > Your scenario seems like a configuration error. Setting things up so > that the client has to update DNS server information immediately on a > frequent basis is simply bad network design. I don't think the goal > of this renumbering effort is to accommodate that kind of > configuration. The right way to fix this is to put a DNS cache > downstream of the flaky link. [...] My thinking is that with a network or environment that is known to be unstable and with not too many clients, you can set the lifetime to a small value. It might be okay to set it to small values like 10 minutes. It's rather short, but with few hosts it wouldn't really be a problem. I guess you could come up with cases where you need things to change immediately. I agree that lifetime doesn't help you then. In addition it would help if hosts make a new request when RAs give you a new prefix or perhaps if host is connected to new link. To fully solve the unplanned change case you need reconfigure. The question is whether it's worth the cost. I'm not sure you can do that safely without state on server. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 01:54:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06659; Wed, 3 Mar 2004 01:54:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQGW-0003v4-Uv; Wed, 03 Mar 2004 01:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQFg-0003bW-F0 for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 01:53:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06584 for ; Wed, 3 Mar 2004 01:53:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQFd-0002eU-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 01:53:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQEj-0002W9-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 01:52:09 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1AyQDs-0002Gk-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 01:51:16 -0500 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i236oeBv012306; Wed, 3 Mar 2004 07:50:40 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i236ofq7023410; Wed, 3 Mar 2004 07:50:41 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 3 Mar 2004 07:50:41 +0100 From: Stig Venaas To: Changming Liu Cc: "'JINMEI Tatuya / ???? '" , "'Tim Chown '" , "'dhcwg@ietf.org '" Subject: Re: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Message-ID: <20040303065041.GB23360@sverresborg.uninett.no> References: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C682@MONTEREY.netscreen.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C682@MONTEREY.netscreen.com> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Tue, Mar 02, 2004 at 02:13:56PM -0800, Changming Liu wrote: [...] > The lifetime has several significant drawbacks. The first one is how to > engineer the lifetime value? A difficult choice. if too long it will cause > too long delay, which is unacceptable for service shortage. if too short, it Yes, so for unplanned changes it's difficult. Lifetime helps, but is not a complete solution. See my other mail. > may cause periodic storms of request/replies. This itself sounds like a [...] If you set the lifetime to one hour (or I gues you may want a smaller value in your case). Hosts that receive the option will refresh their configuration one hour later. If hosts are say turned on at different time, the queries will also be made at different times. So the queries will be distributed throughout the hour. If all hosts are powered up simultaneously, like after a power failure, they will query at about the same time. The randomization will help here. As time goes, they will be dispersed more and more. You will get periods with many queries, but not simultaneously. The effect above is the same as for lease times, there's nothing new about this I think. In the worst case, it will behave like reconfigure... Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 02:06:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14742; Wed, 3 Mar 2004 02:06:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQSE-00088f-9b; Wed, 03 Mar 2004 02:06:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQS0-000839-1M for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 02:05:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13801 for ; Wed, 3 Mar 2004 02:05:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQRw-000536-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 02:05:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQQq-0004pB-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 02:04:41 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1AyQQ0-0004d6-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 02:03:48 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 0F9A835496B; Tue, 2 Mar 2004 23:03:49 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03120-05; Tue, 2 Mar 2004 23:03:48 -0800 (PST) Received: from redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id 4ECEF354969; Tue, 2 Mar 2004 23:03:43 -0800 (PST) Received: from malt (localhost [127.0.0.1]) by redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) with ESMTP id XAA00308; Tue, 2 Mar 2004 23:03:43 -0800 (PST) Message-Id: <200403030703.XAA00308@redback.com> To: Stig Venaas Cc: Changming Liu , "'JINMEI Tatuya / ???? '" , "'Tim Chown '" , "'dhcwg@ietf.org '" Subject: Re: [dhcwg] Renumbering Requirements for Stateless DHCPv6 In-reply-to: Mail from Stig Venaas dated Wed, 03 Mar 2004 07:50:41 +0100 <20040303065041.GB23360@sverresborg.uninett.no> Date: Tue, 02 Mar 2004 23:03:42 -0800 From: Naiming Shen X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Stig, ] On Tue, Mar 02, 2004 at 02:13:56PM -0800, Changming Liu wrote: ] [...] ] > The lifetime has several significant drawbacks. The first one is how to ] > engineer the lifetime value? A difficult choice. if too long it will cause ] > too long delay, which is unacceptable for service shortage. if too short, it ] ] Yes, so for unplanned changes it's difficult. Lifetime helps, but is ] not a complete solution. See my other mail. ] ] > may cause periodic storms of request/replies. This itself sounds like a ] [...] ] ] If you set the lifetime to one hour (or I gues you may want a smaller ] value in your case). Hosts that receive the option will refresh their ] configuration one hour later. If hosts are say turned on at different ] time, the queries will also be made at different times. So the queries ] will be distributed throughout the hour. If all hosts are powered up ] simultaneously, like after a power failure, they will query at about ] the same time. The randomization will help here. As time goes, they ] will be dispersed more and more. You will get periods with many ] queries, but not simultaneously. ] ] The effect above is the same as for lease times, there's nothing new ] about this I think. I think the scaling issue is missing in your text. The router we have in the network right now handles 60K customers per box, and ISPs demand that there need to be 1 or 2 second detection delay if any host is gone. This customer number per box can dramatically increase in the future, just to give some examples here. Randomness does not help here. Regards, ] ] In the worst case, it will behave like reconfigure... ] ] Stig ] ] _______________________________________________ ] dhcwg mailing list ] dhcwg@ietf.org ] https://www1.ietf.org/mailman/listinfo/dhcwg - Naiming _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 02:19:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24474; Wed, 3 Mar 2004 02:19:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQek-00051z-JE; Wed, 03 Mar 2004 02:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQdv-0004ib-PX for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 02:18:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22983 for ; Wed, 3 Mar 2004 02:18:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQds-0007Lo-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 02:18:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQcz-0007En-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 02:17:13 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1AyQcK-0006zK-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 02:16:32 -0500 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i237FlBv017408; Wed, 3 Mar 2004 08:15:47 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i237FmGj023507; Wed, 3 Mar 2004 08:15:48 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 3 Mar 2004 08:15:47 +0100 From: Stig Venaas To: Naiming Shen Cc: Changming Liu , "'JINMEI Tatuya / ???? '" , "'Tim Chown '" , "'dhcwg@ietf.org '" Subject: Re: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Message-ID: <20040303071547.GA23494@sverresborg.uninett.no> References: <20040303065041.GB23360@sverresborg.uninett.no> <200403030703.XAA00308@redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403030703.XAA00308@redback.com> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Tue, Mar 02, 2004 at 11:03:42PM -0800, Naiming Shen wrote: > I think the scaling issue is missing in your text. The router we have > in the network right now handles 60K customers per box, and ISPs demand that > there need to be 1 or 2 second detection delay if any host is gone. This > customer number per box can dramatically increase in the future, just > to give some examples here. Randomness does not help here. OK, so all of these areusing the same DHCP server? Would reconfigure help? If all hosts get a reconfigure message you have the same problem. I think reconfigure has the same issue unless you could send reconfig to different hosts (or different subnets) at different times. I must confess I'm not sure I understand your scenario. But I'm not saying that lifetime works in all cases. It's a simple solution I believe helps in many cases, but there are cases where other solutions are better. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 02:36:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07151; Wed, 3 Mar 2004 02:36:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQvC-0001HV-Na; Wed, 03 Mar 2004 02:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQu2-0000oT-GJ for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 02:35:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06917 for ; Wed, 3 Mar 2004 02:34:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQte-0002Tv-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 02:34:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQsm-0002KF-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 02:33:33 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1AyQs5-00029k-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 02:32:49 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 22CEB80EAA2; Tue, 2 Mar 2004 23:32:50 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06794-05; Tue, 2 Mar 2004 23:32:49 -0800 (PST) Received: from redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id 96C7380EAA0; Tue, 2 Mar 2004 23:32:49 -0800 (PST) Received: from malt (localhost [127.0.0.1]) by redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) with ESMTP id XAA00477; Tue, 2 Mar 2004 23:32:49 -0800 (PST) Message-Id: <200403030732.XAA00477@redback.com> To: Stig Venaas Cc: Naiming Shen , Changming Liu , "'JINMEI Tatuya / ???? '" , "'Tim Chown '" , "'dhcwg@ietf.org '" Subject: Re: [dhcwg] Renumbering Requirements for Stateless DHCPv6 In-reply-to: Mail from Stig Venaas dated Wed, 03 Mar 2004 08:15:47 +0100 <20040303071547.GA23494@sverresborg.uninett.no> Date: Tue, 02 Mar 2004 23:32:49 -0800 From: Naiming Shen X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , ] On Tue, Mar 02, 2004 at 11:03:42PM -0800, Naiming Shen wrote: ] > I think the scaling issue is missing in your text. The router we have ] > in the network right now handles 60K customers per box, and ISPs demand that ] > there need to be 1 or 2 second detection delay if any host is gone. This ] > customer number per box can dramatically increase in the future, just ] > to give some examples here. Randomness does not help here. ] ] OK, so all of these areusing the same DHCP server? Would reconfigure ] help? If all hosts get a reconfigure message you have the same problem. ] I think reconfigure has the same issue unless you could send reconfig ] to different hosts (or different subnets) at different times. No, reconfig may have the same problem. I would like to see to have the server give out a 'lease-time' of 1 hour, but report back to me every 1 minute. this way we cut down the traffic to half(only busy in one direction). ] ] I must confess I'm not sure I understand your scenario. But I'm not ] saying that lifetime works in all cases. It's a simple solution I ] believe helps in many cases, but there are cases where other solutions ] are better. ] ] Stig - Naiming _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 04:24:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13241; Wed, 3 Mar 2004 04:24:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AySc6-00012L-Pn; Wed, 03 Mar 2004 04:24:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRcM-0003xO-F3 for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 03:20:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10133 for ; Wed, 3 Mar 2004 03:20:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRc0-0003Qi-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 03:20:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRb5-0003JG-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 03:19:20 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1AyRai-0003B8-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 03:18:56 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i238IQ9u022532; Wed, 3 Mar 2004 00:18:26 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 00:18:26 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C695@MONTEREY.netscreen.com> From: Changming Liu To: "'Ted Lemon '" , Changming Liu Cc: "''dhcwg@ietf.org' '" Subject: RE: [dhcwg] draft-chown-dhc-dual-stack-00 Date: Wed, 3 Mar 2004 00:18:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >That's very helpful information. It would be wonderful if you could >write a more detailed description of the problems you've run into and >the ways you've solved them. One of the problems we have right now is >that most people in the working group do not have any operational >experience with this. Changming: It is a very simple solution: when enabling a DHCP client on an interface, allow the end user to define a preference value from 0 to 255 and default to 128. This also works well with multiple instances of PPPoE clients on the same device (which we also support). In Japan, it seems very commom to have a CPE dual homed running two instance of PPPoE, one is primary and another is backup. The primary one will be given high preference. Note that in case of PPPoE, the PPP will also get DNS info, same as DHCP. So this solution works even in a mixed environment such as PPPoE and DHCP running at the same time, which may not be real, just want to show its flexibility. Thanks! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 04:25:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13269; Wed, 3 Mar 2004 04:25:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyScZ-00019m-L2; Wed, 03 Mar 2004 04:24:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRqx-0004s6-Ic for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 03:35:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11030 for ; Wed, 3 Mar 2004 03:35:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRqb-00060Q-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 03:35:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRpg-0005rq-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 03:34:25 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1AyRpH-0005iv-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 03:33:59 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i238Wu9u023152; Wed, 3 Mar 2004 00:32:56 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 00:32:56 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C696@MONTEREY.netscreen.com> From: Changming Liu To: "'Ted Lemon '" , Changming Liu Cc: "'''JINMEI Tatuya / ???? ' ' '" , "'''dhcwg@ietf.org ' ' '" , "'''Tim Chown ' ' '" Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Wed, 3 Mar 2004 00:32:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Ted, >Your scenario seems like a configuration error. Setting things up so >that the client has to update DNS server information immediately on a >frequent basis is simply bad network design. I don't think the goal >of this renumbering effort is to accommodate that kind of >configuration. The right way to fix this is to put a DNS cache >downstream of the flaky link. If I was not clear in describing the scenario, pleae forgive me. Our customer is one of the biggest Telecoes in the world. Without their permission, I can not disclose too much details. Needless to say, it should not be that bad design after so many engineers working on it. Let me try it again in different way. Let's say a multi-homed CPE with two upstream links, one connected to one of its ISPs, one is primary and one is backup. DHCP are enabled on both links for configuration info such as DNS. These two ISPs offer different DNS servers. The requirement is that as long as primary ISP is up, use it right away including DNS. This is due to cost struture. Is this reasonable requirement? This CPE runs DHCP server on the downstream link to pass the DNS info to the local LAN. Once the primary ISP is up, its DNS info neends to push to downstream. Of course, you an hope the primary links never goes down unplanned(if it is true, why dualhome at the first palce?). The lifetime solution does not solve this problem. If you need more info, we can get together to discuss this. Changming Netscreen Technoloies Inc _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 04:24:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13240; Wed, 3 Mar 2004 04:24:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AySbn-0000uk-PD; Wed, 03 Mar 2004 04:24:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRUf-00036e-8z for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 03:13:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09828 for ; Wed, 3 Mar 2004 03:12:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRUJ-0002Hh-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 03:12:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRTP-00029M-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 03:11:23 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1AyRT3-00020K-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 03:11:01 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i238AG9u022174; Wed, 3 Mar 2004 00:10:16 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 00:10:16 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C694@MONTEREY.netscreen.com> From: Changming Liu To: "'matthew.ford@bt.com '" , Changming Liu , "'mellon@fugue.com '" Cc: "'jinmei@isl.rdc.toshiba.co.jp '" , "'dhcwg@ietf.org '" , "'tjc@ecs.soton.ac.uk '" Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Wed, 3 Mar 2004 00:10:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Mat, >I don't agree at all. There is no requirement to work in the event of unplanned events - it would be nice, but I don't agree that it is required. There will always be breakage in the case of unplanned events, which is precisely why operators try to avoid them. I think we are deluded if we think that there is a solution out there that could be guaranteed to work in the case of an unplanned event. Given that, lifetimes are necessary and sufficient in my opinion. Changming: If you have read the draft, in both sectin 2 (problem statement) and section 4 (renumbering requirement) state it very clearly and I agree 100% with. Here is the quote fom the draft in case you don't have access: The unplanned renumbering event, which may be more common in smaller, unmanaged networks, is more difficult to cater for. Ideally, any solution for the problem should consider planned and unplanned events > For reconfig, we already have one defined, but unicast only. > So the infrastruture should be there. Why require infrastructure when it isn't necessary? Changming: That's not my point. My point is whatever infrastruture needed to support the unicast reconfigure message will be reused for multiast. The unicast RECONFIGURE message is defined in RFC 3315 section 15.11. > It only problem is it's unicast which does not scale well. > The problem is well defined in this draft and no need to repeat here. Unicast doesn't scale and multicast is difficult to secure - that's the bind that reconfig is in. Changming: true statement and in general I agree. "Two advantages of IPv6 are that support for multicast is required and nodes can create link-local addresses during initialization. " from RFC 3315 section 3. If multicast is not secure, why don't we abandon it all together? We use multicast address in many places such as RA, why not here? Mat _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 04:26:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13458; Wed, 3 Mar 2004 04:26:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyScu-0001HR-72; Wed, 03 Mar 2004 04:25:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRzr-0005dg-UQ for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 03:45:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11329 for ; Wed, 3 Mar 2004 03:44:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRzV-0007RD-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 03:44:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRyU-0007FU-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 03:43:30 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1AyRxk-00071v-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 03:42:44 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i238g79u023603; Wed, 3 Mar 2004 00:42:08 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 00:42:07 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C697@MONTEREY.netscreen.com> From: Changming Liu To: "'Stig Venaas '" , "'Ted Lemon '" Cc: Changming Liu , "'''JINMEI Tatuya / ???? ' ' '" , "'''dhcwg@ietf.org ' ' '" , "'''Tim Chown ' ' '" Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Wed, 3 Mar 2004 00:41:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Stig, >My thinking is that with a network or environment that is known to be >unstable and with not too many clients, you can set the lifetime to a >small value. It might be okay to set it to small values like 10 minutes. >It's rather short, but with few hosts it wouldn't really be a problem. 10 minutes is long time. ANyone of you want your laptop to be out of service for 10 minutes? >I guess you could come up with cases where you need things to change >immediately. I agree that lifetime doesn't help you then. In addition >it would help if hosts make a new request when RAs give you a new >prefix or perhaps if host is connected to new link. We are the same page >To fully solve the unplanned change case you need reconfigure. The >question is whether it's worth the cost. I'm not sure you can do that >safely without state on server. Worth it or not depends on situation. There is no perfect world. It is full of trade-off, especially in engineering. The security is a concern. But think about the case that a client just reboots and which DHCP server does it trust? For ND,now we have SEND. for DHCPv6, do we have Secure SEDHCPv6? Why does security just matter to this message? Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 04:38:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14369; Wed, 3 Mar 2004 04:38:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AySpK-0004TF-VD; Wed, 03 Mar 2004 04:38:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AySo7-0004Dv-Od for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 04:37:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14306 for ; Wed, 3 Mar 2004 04:36:19 -0500 (EST) From: matthew.ford@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AySna-0000zq-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 04:36:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AySmi-0000r4-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 04:35:24 -0500 Received: from smtp5.smtp.bt.com ([217.32.164.139] helo=i2kc05-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1AySm0-0000f8-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 04:34:40 -0500 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by i2kc05-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Mar 2004 09:34:11 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Mar 2004 09:34:10 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Wed, 3 Mar 2004 09:34:07 -0000 Message-ID: <0AAF93247C75E3408638B965DEE11A7005E3CD24@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Thread-Index: AcQA9viUfL7weIHcQnuajkiFvwig6wACrH/A To: , Cc: , , X-OriginalArrivalTime: 03 Mar 2004 09:34:10.0540 (UTC) FILETIME=[AEADBAC0:01C40102] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Changming,=20 > >I don't agree at all. There is no requirement to work in the event of > unplanned events - it would be nice, but I don't agree that it is > required. There will always be breakage in the case of=20 > unplanned events, > which is precisely why operators try to avoid them. I think we are > deluded if we think that there is a solution out there that could be > guaranteed to work in the case of an unplanned event. Given that, > lifetimes are necessary and sufficient in my opinion. >=20 > Changming: If you have read the draft, in both sectin 2=20 > (problem statement) > and section 4 (renumbering requirement) state it very clearly=20 > and I agree > 100% with. Here is the quote fom the draft in case you don't=20 > have access: >=20 > =20 > The unplanned renumbering event, which may be more common in smaller, > unmanaged networks, is more difficult to cater for. Ideally, any > solution for the problem should consider planned and unplanned > events This doesn't make it a requirement, it just says, 'It would be nice if we could cater for unplanned events.' I agree it would be nice, but I don't think it is possible in any really useful way, without imposing considerable burdens and costs on network operators, and therefore believe that lifetime's are sufficient here. > > For reconfig, we already have one defined, but unicast only.=20 > > So the infrastruture should be there. >=20 > Why require infrastructure when it isn't necessary? >=20 > Changming: That's not my point. My point is whatever=20 > infrastruture needed to > support the unicast reconfigure message will be reused for=20 > multiast. The > unicast RECONFIGURE message is defined in RFC 3315 section 15.11. Is it implemented? Is it deployed? =20 > > It only problem is it's unicast which does not scale well.=20 > > The problem is well defined in this draft and no need to=20 > repeat here. >=20 > Unicast doesn't scale and multicast is difficult to secure -=20 > that's the > bind that reconfig is in. >=20 > Changming: true statement and in general I agree. "Two=20 > advantages of IPv6 > are that support for multicast is required and nodes can=20 > create link-local > addresses during initialization. " from RFC 3315 section 3.=20 > If multicast is > not secure, why don't we abandon it all together? We use=20 > multicast address > in many places such as RA, why not here? I've seen enough IPv6 networks hosed by rogue RAs to know that the way forward is not to add another unsecured multicast technology into the mix, but to work on solutions for securing those we've already got, e.g. SEND (although I think they may have backed off from the RA-auth problem). Mat _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 06:56:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20513; Wed, 3 Mar 2004 06:56:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyUyo-0000PU-30; Wed, 03 Mar 2004 06:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyUxX-0000Ko-Nn for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 06:55:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20396 for ; Wed, 3 Mar 2004 06:54:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyUx9-0000xM-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 06:54:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyUwE-0000p6-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 06:53:23 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1AyUvK-0000Z6-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 06:52:26 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i23Bpm9u002370; Wed, 3 Mar 2004 03:51:48 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 03:51:47 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C698@MONTEREY.netscreen.com> From: Changming Liu To: "'matthew.ford@bt.com '" , Changming Liu , "'mellon@fugue.com '" Cc: "'jinmei@isl.rdc.toshiba.co.jp '" , "'dhcwg@ietf.org '" , "'tjc@ecs.soton.ac.uk '" Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Wed, 3 Mar 2004 03:51:44 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Mat, >This doesn't make it a requirement, it just says, 'It would be nice if >we could cater for unplanned events.' I agree it would be nice, but I >don't think it is possible in any really useful way, without imposing >considerable burdens and costs on network operators, and therefore >believe that lifetime's are sufficient here. If this one can be interpreted as "nice to have" one. In section 2, it says highly desirable. If this "highly desirable" still does not do the trick, why do we removed it completely fom the draft? Why bother? >Is it implemented? Is it deployed? Can not speak for other implementations. Our implementation is in alpha testing now because ou customer demands it and we don't have other solutions at this point! I wish this draft and the solution draft come out earlier. >I've seen enough IPv6 networks hosed by rogue RAs to know that the way >forward is not to add another unsecured multicast technology into the >mix, but to work on solutions for securing those we've already got, e.g. >SEND (although I think they may have backed off from the RA-auth >problem). How about othe applications using link-local multicast such as RIPng, OSPFv3, etc. We really have a bigger poblem to solve. Unless someone comes to say link-local multicast should not be used at all and lets obsolete it (just like the site-local), I guess it sould not be limited to one particular message. Changming _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 07:30:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21909; Wed, 3 Mar 2004 07:30:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVVk-0005N2-AF; Wed, 03 Mar 2004 07:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVUV-0005KI-Tb for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 07:29:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21751 for ; Wed, 3 Mar 2004 07:28:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyVUB-0006FM-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 07:28:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyVTN-00066S-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 07:27:37 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1AyVSi-0005tl-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 07:26:56 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i23CQJ9u003913; Wed, 3 Mar 2004 04:26:19 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 04:26:19 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C69A@MONTEREY.netscreen.com> From: Changming Liu To: "'Naiming Shen '" , "'Stig Venaas '" Cc: Changming Liu , "''JINMEI Tatuya / ???? ' '" , "''Tim Chown ' '" , "''dhcwg@ietf.org ' '" Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Wed, 3 Mar 2004 04:26:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Naiming and Stig, You two just brought up an issue about scability with these two approaches in cases of power outage and unplanned config changes, which is very good. The solution to this, if we really decide to go with e-configure solution, is to implement a push model instead of request-reply model. Just a thought. Changming _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 08:51:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26916; Wed, 3 Mar 2004 08:51:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyWm6-0000Hj-W2; Wed, 03 Mar 2004 08:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyWlf-0000Dn-DW for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 08:50:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26839 for ; Wed, 3 Mar 2004 08:50:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyWld-0005nh-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 08:50:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyWkh-0005av-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 08:49:36 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1AyWjt-0005Of-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 08:48:45 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by pan.gwi.net (8.12.6p3/8.12.6) with ESMTP id i23DmSGn098435; Wed, 3 Mar 2004 08:48:37 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Changming Liu'" , "'Ted Lemon '" Cc: "'''JINMEI Tatuya / ???? ' ' '" , , "'''Tim Chown ' ' '" Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Wed, 3 Mar 2004 08:48:36 -0500 Message-ID: <000001c40126$3d358840$6601a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C696@MONTEREY.netscreen.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable For this situation, why don't you advertise BOTH DNS servers (primary = and secondary) and simply have the CPE do the proper routing? If the primary link is up, the CPE sends the packets over the primary link. If the = primary is down, the CPE sends the packets over the secondary link. Using the routing infrastructure and CPE knowledge of which link is up or down = seems to me to be the best solution. Note that you need to do this anyway with any active sessions that are running - as I'm sure your big customer doesn't want all sessions to be broken. It seems to me, unless I don't understand something, there really is no issue here. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Changming Liu Sent: Wednesday, March 03, 2004 3:33 AM To: 'Ted Lemon '; Changming Liu Cc: '''JINMEI Tatuya / ???? ' ' '; '''dhcwg@ietf.org ' ' '; '''Tim Chown = ' ' ' Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Hi Ted,=20 >Your scenario seems like a configuration error. Setting things up so=20 >that the client has to update DNS server information immediately on a=20 >frequent basis is simply bad network design. I don't think the goal=20 >of this renumbering effort is to accommodate that kind of=20 >configuration. The right way to fix this is to put a DNS cache=20 >downstream of the flaky link. If I was not clear in describing the scenario, pleae forgive me. Our customer is one of the biggest Telecoes in the world. Without their permission, I can not disclose too much details. Needless to say, it = should not be that bad design after so many engineers working on it.=20 Let me try it again in different way. Let's say a multi-homed CPE with = two upstream links, one connected to one of its ISPs, one is primary and one = is backup. DHCP are enabled on both links for configuration info such as = DNS. These two ISPs offer different DNS servers. The requirement is that as = long as primary ISP is up, use it right away including DNS. This is due to = cost struture. Is this reasonable requirement?=20 This CPE runs DHCP server on the downstream link to pass the DNS info to = the local LAN. Once the primary ISP is up, its DNS info neends to push to downstream. Of course, you an hope the primary links never goes down unplanned(if it is true, why dualhome at the first palce?). The lifetime solution does not solve this problem. If you need more info, we can get together to discuss this. Changming Netscreen Technoloies Inc _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 09:09:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28170; Wed, 3 Mar 2004 09:09:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyX3X-0001e8-3g; Wed, 03 Mar 2004 09:09:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyX3L-0001cX-ME for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 09:08:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28064 for ; Wed, 3 Mar 2004 09:08:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyX3K-0001fg-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 09:08:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyX2J-0001SZ-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 09:07:47 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1AyX1S-000170-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 09:06:54 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 03 Mar 2004 06:05:25 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i23E6IxU004609; Wed, 3 Mar 2004 09:06:19 -0500 (EST) Received: from mjs-xp.cisco.com ([161.44.65.244]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGM19535; Wed, 3 Mar 2004 09:06:18 -0500 (EST) Message-Id: <4.3.2.7.2.20040303090022.01bb7b20@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 03 Mar 2004 09:05:53 -0500 To: "Bernie Volz" From: Mark Stapp Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Cc: "'Changming Liu'" , "'Ted Lemon '" , "'''JINMEI Tatuya / ???? ' ' '" , , "'''Tim Chown ' ' '" In-Reply-To: <000001c40126$3d358840$6601a8c0@BVolz> References: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C696@MONTEREY.netscreen.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , or the CPE could supply its own address (if it has an address on the downstream link) as the dns server address, and act as a forwarder for its clients. the CPE knows which upstream links and upstream dns resolvers to use, so it should make the decision, not the clients. the downstream clients should be insulated from upstream network issues as much as possible, imo. I agree with Bernie: this doesn't sound like a problem that should be solved by reconfiguring the clients repeatedly. -- Mark At 08:48 AM 3/3/2004 -0500, Bernie Volz wrote: >For this situation, why don't you advertise BOTH DNS servers (primary and >secondary) and simply have the CPE do the proper routing? If the primary >link is up, the CPE sends the packets over the primary link. If the primary >is down, the CPE sends the packets over the secondary link. Using the >routing infrastructure and CPE knowledge of which link is up or down seems >to me to be the best solution. > >Note that you need to do this anyway with any active sessions that are >running - as I'm sure your big customer doesn't want all sessions to be >broken. > >It seems to me, unless I don't understand something, there really is no >issue here. > >- Bernie > >-----Original Message----- >From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of >Changming Liu >Sent: Wednesday, March 03, 2004 3:33 AM >To: 'Ted Lemon '; Changming Liu >Cc: '''JINMEI Tatuya / ???? ' ' '; '''dhcwg@ietf.org ' ' '; '''Tim Chown ' ' >' >Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 > >Hi Ted, > > >Your scenario seems like a configuration error. Setting things up so > >that the client has to update DNS server information immediately on a > >frequent basis is simply bad network design. I don't think the goal > >of this renumbering effort is to accommodate that kind of > >configuration. The right way to fix this is to put a DNS cache > >downstream of the flaky link. > >If I was not clear in describing the scenario, pleae forgive me. Our >customer is one of the biggest Telecoes in the world. Without their >permission, I can not disclose too much details. Needless to say, it should >not be that bad design after so many engineers working on it. > >Let me try it again in different way. Let's say a multi-homed CPE with two >upstream links, one connected to one of its ISPs, one is primary and one is >backup. DHCP are enabled on both links for configuration info such as DNS. >These two ISPs offer different DNS servers. The requirement is that as long >as primary ISP is up, use it right away including DNS. This is due to cost >struture. Is this reasonable requirement? > >This CPE runs DHCP server on the downstream link to pass the DNS info to the >local LAN. Once the primary ISP is up, its DNS info neends to push to >downstream. Of course, you an hope the primary links never goes down >unplanned(if it is true, why dualhome at the first palce?). The lifetime >solution does not solve this problem. > >If you need more info, we can get together to discuss this. > >Changming >Netscreen Technoloies Inc > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 09:22:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29382; Wed, 3 Mar 2004 09:22:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyXG5-0003Vq-Sh; Wed, 03 Mar 2004 09:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyXFy-0003TY-38 for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 09:21:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29360 for ; Wed, 3 Mar 2004 09:21:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyXFv-0004VM-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 09:21:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyXF6-0004Jz-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 09:21:01 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1AyXER-00045J-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 09:20:19 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i23EJd9u009421; Wed, 3 Mar 2004 06:19:39 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 06:19:39 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C69F@MONTEREY.netscreen.com> From: Changming Liu To: "'Bernie Volz '" , Changming Liu , "''Ted Lemon ' '" Cc: "''''JINMEI Tatuya / ???? ' ' ' '" , "'dhcwg@ietf.org '" , "''''Tim Chown ' ' ' '" Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Wed, 3 Mar 2004 06:19:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , That could be a solutiuon. But will that break the layered model? Currently our routing is purely based on IP addresses. DNS is just one of the configurations. There could be more. Changming -----Original Message----- From: Bernie Volz To: 'Changming Liu'; 'Ted Lemon ' Cc: '''JINMEI Tatuya / ???? ' ' '; dhcwg@ietf.org; '''Tim Chown ' ' ' Sent: 3/3/2004 5:48 AM Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 For this situation, why don't you advertise BOTH DNS servers (primary and secondary) and simply have the CPE do the proper routing? If the primary link is up, the CPE sends the packets over the primary link. If the primary is down, the CPE sends the packets over the secondary link. Using the routing infrastructure and CPE knowledge of which link is up or down seems to me to be the best solution. Note that you need to do this anyway with any active sessions that are running - as I'm sure your big customer doesn't want all sessions to be broken. It seems to me, unless I don't understand something, there really is no issue here. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Changming Liu Sent: Wednesday, March 03, 2004 3:33 AM To: 'Ted Lemon '; Changming Liu Cc: '''JINMEI Tatuya / ???? ' ' '; '''dhcwg@ietf.org ' ' '; '''Tim Chown ' ' ' Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Hi Ted, >Your scenario seems like a configuration error. Setting things up so >that the client has to update DNS server information immediately on a >frequent basis is simply bad network design. I don't think the goal >of this renumbering effort is to accommodate that kind of >configuration. The right way to fix this is to put a DNS cache >downstream of the flaky link. If I was not clear in describing the scenario, pleae forgive me. Our customer is one of the biggest Telecoes in the world. Without their permission, I can not disclose too much details. Needless to say, it should not be that bad design after so many engineers working on it. Let me try it again in different way. Let's say a multi-homed CPE with two upstream links, one connected to one of its ISPs, one is primary and one is backup. DHCP are enabled on both links for configuration info such as DNS. These two ISPs offer different DNS servers. The requirement is that as long as primary ISP is up, use it right away including DNS. This is due to cost struture. Is this reasonable requirement? This CPE runs DHCP server on the downstream link to pass the DNS info to the local LAN. Once the primary ISP is up, its DNS info neends to push to downstream. Of course, you an hope the primary links never goes down unplanned(if it is true, why dualhome at the first palce?). The lifetime solution does not solve this problem. If you need more info, we can get together to discuss this. Changming Netscreen Technoloies Inc _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 09:34:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00081; Wed, 3 Mar 2004 09:34:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyXRh-0004DM-DG; Wed, 03 Mar 2004 09:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyXRC-0004C7-Ll for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 09:33:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00016 for ; Wed, 3 Mar 2004 09:33:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyXRB-0006b7-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 09:33:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyXQI-0006QT-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 09:32:35 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1AyXPQ-00067R-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 09:31:40 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i23EUs9u009972; Wed, 3 Mar 2004 06:30:54 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 06:30:54 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C6A0@MONTEREY.netscreen.com> From: Changming Liu To: "'Mark Stapp '" , "'Bernie Volz '" Cc: Changming Liu , "''Ted Lemon ' '" , "''''JINMEI Tatuya / ???? ' ' ' '" , "'dhcwg@ietf.org '" , "''''Tim Chown ' ' ' '" Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Wed, 3 Mar 2004 06:30:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Mark, Thanks for the suggestion. We already have this DNS proxy solution implemented. That will work for DNS in this situation. How about other configurations? How about other scenarios that configration can change in the fly? Without a good infrustruture in place, we need to conquer this problem one by one. Why don't we have once-for-all solution? Another point is that not all the people buy into the proxy idea. Remember that in old days, the firwalls are almost all proxy based. Look at now, they almost are stateful. What a change! Changming -----Original Message----- From: Mark Stapp To: Bernie Volz Cc: 'Changming Liu'; 'Ted Lemon '; '''JINMEI Tatuya / ???? ' ' '; dhcwg@ietf.org; '''Tim Chown ' ' ' Sent: 3/3/2004 6:05 AM Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 or the CPE could supply its own address (if it has an address on the downstream link) as the dns server address, and act as a forwarder for its clients. the CPE knows which upstream links and upstream dns resolvers to use, so it should make the decision, not the clients. the downstream clients should be insulated from upstream network issues as much as possible, imo. I agree with Bernie: this doesn't sound like a problem that should be solved by reconfiguring the clients repeatedly. -- Mark At 08:48 AM 3/3/2004 -0500, Bernie Volz wrote: >For this situation, why don't you advertise BOTH DNS servers (primary and >secondary) and simply have the CPE do the proper routing? If the primary >link is up, the CPE sends the packets over the primary link. If the primary >is down, the CPE sends the packets over the secondary link. Using the >routing infrastructure and CPE knowledge of which link is up or down seems >to me to be the best solution. > >Note that you need to do this anyway with any active sessions that are >running - as I'm sure your big customer doesn't want all sessions to be >broken. > >It seems to me, unless I don't understand something, there really is no >issue here. > >- Bernie > >-----Original Message----- >From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of >Changming Liu >Sent: Wednesday, March 03, 2004 3:33 AM >To: 'Ted Lemon '; Changming Liu >Cc: '''JINMEI Tatuya / ???? ' ' '; '''dhcwg@ietf.org ' ' '; '''Tim Chown ' ' >' >Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 > >Hi Ted, > > >Your scenario seems like a configuration error. Setting things up so > >that the client has to update DNS server information immediately on a > >frequent basis is simply bad network design. I don't think the goal > >of this renumbering effort is to accommodate that kind of > >configuration. The right way to fix this is to put a DNS cache > >downstream of the flaky link. > >If I was not clear in describing the scenario, pleae forgive me. Our >customer is one of the biggest Telecoes in the world. Without their >permission, I can not disclose too much details. Needless to say, it should >not be that bad design after so many engineers working on it. > >Let me try it again in different way. Let's say a multi-homed CPE with two >upstream links, one connected to one of its ISPs, one is primary and one is >backup. DHCP are enabled on both links for configuration info such as DNS. >These two ISPs offer different DNS servers. The requirement is that as long >as primary ISP is up, use it right away including DNS. This is due to cost >struture. Is this reasonable requirement? > >This CPE runs DHCP server on the downstream link to pass the DNS info to the >local LAN. Once the primary ISP is up, its DNS info neends to push to >downstream. Of course, you an hope the primary links never goes down >unplanned(if it is true, why dualhome at the first palce?). The lifetime >solution does not solve this problem. > >If you need more info, we can get together to discuss this. > >Changming >Netscreen Technoloies Inc > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 09:39:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00374; Wed, 3 Mar 2004 09:39:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyXWX-00051a-JZ; Wed, 03 Mar 2004 09:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyXWN-00050P-Mm for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 09:38:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00342 for ; Wed, 3 Mar 2004 09:38:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyXWL-0007bc-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 09:38:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyXV5-0007KO-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 09:37:31 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AyXTB-0006zR-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 09:35:33 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id i23EZG57055157; Wed, 3 Mar 2004 09:35:25 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Changming Liu'" , "''Ted Lemon ' '" Cc: "''''JINMEI Tatuya / ???? ' ' ' '" , , "''''Tim Chown ' ' ' '" Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Wed, 3 Mar 2004 09:35:24 -0500 Message-ID: <000a01c4012c$c6bbc600$6601a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C69F@MONTEREY.netscreen.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Huh? How does this break anything? This is exactly what routing is all about. And it is exactly what layering is all about. The application = layer (such as DNS) shouldn't care exactly what route packets take to reach = their destination - that's the responsibility of IP, not DNS. As I said earlier, any active connections (or sessions) will need to be re-routed over the link that's up and preferred, and you would not want = to break these connections (sessions). Note also that: - This will be instantaneous (or as close as you can get) since the CPE = can switch links as soon as the primary link returns (or the primary link is marked down). - Will redirect *ALL* traffic, which is exactly what you want. - Is transparent to all applications and works for all applications (anything above the IP layer). - Allows fancier use of the two links as well - such as for load = balancing. This is not a DHCP issue at all, but just a standard routing issue. - Bernie -----Original Message----- From: Changming Liu [mailto:cliu@netscreen.com]=20 Sent: Wednesday, March 03, 2004 9:20 AM To: 'Bernie Volz '; Changming Liu; ''Ted Lemon ' ' Cc: ''''JINMEI Tatuya / ???? ' ' ' '; 'dhcwg@ietf.org '; ''''Tim Chown ' = ' ' ' Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 That could be a solutiuon. But will that break the layered model? = Currently our routing is purely based on IP addresses. DNS is just one of the configurations. There could be more. Changming -----Original Message----- From: Bernie Volz To: 'Changming Liu'; 'Ted Lemon ' Cc: '''JINMEI Tatuya / ???? ' ' '; dhcwg@ietf.org; '''Tim Chown ' ' ' Sent: 3/3/2004 5:48 AM Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 For this situation, why don't you advertise BOTH DNS servers (primary and secondary) and simply have the CPE do the proper routing? If the primary link is up, the CPE sends the packets over the primary link. If the primary is down, the CPE sends the packets over the secondary link. Using the routing infrastructure and CPE knowledge of which link is up or down seems to me to be the best solution. Note that you need to do this anyway with any active sessions that are running - as I'm sure your big customer doesn't want all sessions to be broken. It seems to me, unless I don't understand something, there really is no issue here. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Changming Liu Sent: Wednesday, March 03, 2004 3:33 AM To: 'Ted Lemon '; Changming Liu Cc: '''JINMEI Tatuya / ???? ' ' '; '''dhcwg@ietf.org ' ' '; '''Tim Chown ' ' ' Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Hi Ted,=20 >Your scenario seems like a configuration error. Setting things up so=20 >that the client has to update DNS server information immediately on a=20 >frequent basis is simply bad network design. I don't think the goal=20 >of this renumbering effort is to accommodate that kind of=20 >configuration. The right way to fix this is to put a DNS cache=20 >downstream of the flaky link. If I was not clear in describing the scenario, pleae forgive me. Our customer is one of the biggest Telecoes in the world. Without their permission, I can not disclose too much details. Needless to say, it should not be that bad design after so many engineers working on it.=20 Let me try it again in different way. Let's say a multi-homed CPE with two upstream links, one connected to one of its ISPs, one is primary and one is backup. DHCP are enabled on both links for configuration info such as DNS. These two ISPs offer different DNS servers. The requirement is that as long as primary ISP is up, use it right away including DNS. This is due to cost struture. Is this reasonable requirement?=20 This CPE runs DHCP server on the downstream link to pass the DNS info to the local LAN. Once the primary ISP is up, its DNS info neends to push to downstream. Of course, you an hope the primary links never goes down unplanned(if it is true, why dualhome at the first palce?). The lifetime solution does not solve this problem. If you need more info, we can get together to discuss this. Changming Netscreen Technoloies Inc _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 10:42:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05793; Wed, 3 Mar 2004 10:42:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyYVV-0006NE-Cg; Wed, 03 Mar 2004 10:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyYV1-0006MN-Ca for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 10:41:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05669 for ; Wed, 3 Mar 2004 10:41:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyYUz-0004K7-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 10:41:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyYTh-0003yE-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 10:40:10 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1AyYSL-0003ey-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 10:38:45 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by pan.gwi.net (8.12.6p3/8.12.6) with ESMTP id i23FcbGn017438; Wed, 3 Mar 2004 10:38:45 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "=?iso-8859-1?B?J0pJTk1FSSBUYXR1eWEgLyCQXy2+J0KNxic=?=" Cc: "'Changming Liu'" , Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Wed, 3 Mar 2004 10:38:44 -0500 Message-ID: <000d01c40135$9fa8a2a0$6601a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable >>> The requirement is that as long >>> as primary ISP is up, use it right away including DNS. This is due = to cost >>> struture. >to mean that we do not want to use the secondary DNS (which would be >located in the secondary ISP) if the primary ISP is up, due to the >cost reason (and perhaps reachability/latency issue also?). I don't know of anyone that charges for use of the DNS to resolve = addresses, do you? Latency could be an issue; but that all depends on the routing infrastructure (the secondary link might be slower than the primary, but = if the primary link is up, you'll use the primary link). Place the primary = DNS first in the list and it should be preferred; yes there may be some = latency before the DNS resolvers switch back to using the primary, but you'll = always have some small issue like that. It could also be that the secondary DNS provider won't accept queries from the primary providers addresses, and = in that case you'll have the normal failover between the two DNS servers (resolver will try primary and give up after a timeout and try = secondary). Note that the hosts (clients) would likely be using the provider's = address as the source address (I'd presume the CPE would advertise both prefixes = and the client would configure addresses on both). Also, if the DNS fails because of addressing issues, what does that say about any open sessions (or connections)? In order for this to be successful, the two providers will have to have some agreement between = them to cross route packets and the DNS (and any other essential services) = would just have to be part of that. Remember, the providers are after the best experience for the customer - or if they're not, they'll loose = customers. >I've not reached a conclusion (of myself) on whether or not this is >really a serious issue that can be a show-stopper for the lifetime >proposal. However, at least I think Changming has some valid points. Look, you can always find an argument against any solution or at least = to reduce the effectiveness of that solution. But remember that keeping it simple is the best. Needlessly reconfiguring clients is no way to go. It also has latency issues since transactions could be in progress or = clients might miss the first (or first few) reconfiguration signals. Putting all this in the routing logic of the CPE means that all the = smarts about what to do is located in ONE place and all traffic is treated = equal. This, to me, is such a basic routing issue that moving it up to any = other layer is, frankly, stupid. - Bernie -----Original Message----- From: JINMEI Tatuya / =90_=96=BE=92B=8D=C6 = [mailto:jinmei@isl.rdc.toshiba.co.jp]=20 Sent: Wednesday, March 03, 2004 10:14 AM To: Bernie Volz Cc: 'Changming Liu'; dhcwg@ietf.org Subject: Re: [dhcwg] Renumbering Requirements for Stateless DHCPv6 >>>>> On Wed, 3 Mar 2004 08:48:36 -0500,=20 >>>>> "Bernie Volz" said: > For this situation, why don't you advertise BOTH DNS servers (primary = and > secondary) and simply have the CPE do the proper routing? If the = primary > link is up, the CPE sends the packets over the primary link. If the primary > is down, the CPE sends the packets over the secondary link. Using the > routing infrastructure and CPE knowledge of which link is up or down = seems > to me to be the best solution. I read the scenario >> The requirement is that as long >> as primary ISP is up, use it right away including DNS. This is due to cost >> struture. to mean that we do not want to use the secondary DNS (which would be located in the secondary ISP) if the primary ISP is up, due to the cost reason (and perhaps reachability/latency issue also?). I've not reached a conclusion (of myself) on whether or not this is really a serious issue that can be a show-stopper for the lifetime proposal. However, at least I think Changming has some valid points. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 11:29:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05795; Wed, 3 Mar 2004 10:42:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyYVW-0006NM-01; Wed, 03 Mar 2004 10:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyXET-0003B5-EG for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 09:20:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29235 for ; Wed, 3 Mar 2004 09:20:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyXEQ-000489-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 09:20:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyXDL-0003vT-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 09:19:11 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AyXCX-0003ii-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 09:18:21 -0500 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id E10FA15210; Wed, 3 Mar 2004 23:18:12 +0900 (JST) Date: Wed, 03 Mar 2004 23:18:25 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bernie Volz" Cc: , Subject: Re: [dhcwg] comments on draft-vijay-dhc-dhcpv6-mcast-reconf-00 In-Reply-To: <002a01c4009d$804864b0$6601a8c0@BVolz> References: <002a01c4009d$804864b0$6601a8c0@BVolz> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Tue, 2 Mar 2004 16:29:46 -0500, >>>>> "Bernie Volz" said: > FYI - For those that don't want to spend the 5 to 10 minutes I did looking > for Jinmei's email, I think he was referring to: > http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01798.html That's correct, thanks. My previous post should have been more informative on this. BTW: I've only seen one response to this proposal at the ipv6 ML. If you DHCP guys have comments on it, please speak up (I know Bernie has made one here). If you don't mind, please send your comments to the ipv6 ML (whether cc'ing to this list or not). But comments only sent to this list are also welcome. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 11:29:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05794; Wed, 3 Mar 2004 10:42:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyYVW-0006NU-GM; Wed, 03 Mar 2004 10:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyY60-0003Mm-Cl for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 10:15:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03345 for ; Wed, 3 Mar 2004 10:15:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyY5y-0006rc-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 10:15:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyY4v-0006cA-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 10:14:34 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AyY41-0006Or-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 10:13:38 -0500 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id B05F215210; Thu, 4 Mar 2004 00:13:35 +0900 (JST) Date: Thu, 04 Mar 2004 00:13:48 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bernie Volz" Cc: "'Changming Liu'" , Subject: Re: [dhcwg] Renumbering Requirements for Stateless DHCPv6 In-Reply-To: <000001c40126$3d358840$6601a8c0@BVolz> <1B6D4CAFB8CA554EB1A0925685A07DFC0342C696@MONTEREY.netscreen.com> References: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C696@MONTEREY.netscreen.com> <000001c40126$3d358840$6601a8c0@BVolz> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Wed, 3 Mar 2004 08:48:36 -0500, >>>>> "Bernie Volz" said: > For this situation, why don't you advertise BOTH DNS servers (primary and > secondary) and simply have the CPE do the proper routing? If the primary > link is up, the CPE sends the packets over the primary link. If the primary > is down, the CPE sends the packets over the secondary link. Using the > routing infrastructure and CPE knowledge of which link is up or down seems > to me to be the best solution. I read the scenario >> The requirement is that as long >> as primary ISP is up, use it right away including DNS. This is due to cost >> struture. to mean that we do not want to use the secondary DNS (which would be located in the secondary ISP) if the primary ISP is up, due to the cost reason (and perhaps reachability/latency issue also?). I've not reached a conclusion (of myself) on whether or not this is really a serious issue that can be a show-stopper for the lifetime proposal. However, at least I think Changming has some valid points. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 11:39:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08735; Wed, 3 Mar 2004 11:39:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyZOe-0002ZF-FF; Wed, 03 Mar 2004 11:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyZNj-0002TO-3o for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 11:38:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08708 for ; Wed, 3 Mar 2004 11:38:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyZNi-0007ce-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 11:38:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyZMr-0007Qr-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 11:37:10 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1AyZM6-0007A6-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 11:36:22 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i23GZO9u017075; Wed, 3 Mar 2004 08:35:28 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 08:35:24 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C6A2@MONTEREY.netscreen.com> From: Changming Liu To: "'Bernie Volz '" , Changming Liu , "'''Ted Lemon ' ' '" Cc: "'''''JINMEI Tatuya / ???? ' ' ' ' '" , "'dhcwg@ietf.org '" , "'''''Tim Chown ' ' ' ' '" Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Wed, 3 Mar 2004 08:35:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Bernie, I may miss your point. The primary and backup DNS servers' addresses are different. When switching-over from backup to primary happens, the backup's DNS server's address can not be used any more. How does it become a routing issue? Changming -----Original Message----- From: Bernie Volz To: 'Changming Liu'; ''Ted Lemon ' ' Cc: ''''JINMEI Tatuya / ???? ' ' ' '; dhcwg@ietf.org; ''''Tim Chown ' ' ' ' Sent: 3/3/2004 6:35 AM Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Huh? How does this break anything? This is exactly what routing is all about. And it is exactly what layering is all about. The application layer (such as DNS) shouldn't care exactly what route packets take to reach their destination - that's the responsibility of IP, not DNS. As I said earlier, any active connections (or sessions) will need to be re-routed over the link that's up and preferred, and you would not want to break these connections (sessions). Note also that: - This will be instantaneous (or as close as you can get) since the CPE can switch links as soon as the primary link returns (or the primary link is marked down). - Will redirect *ALL* traffic, which is exactly what you want. - Is transparent to all applications and works for all applications (anything above the IP layer). - Allows fancier use of the two links as well - such as for load balancing. This is not a DHCP issue at all, but just a standard routing issue. - Bernie -----Original Message----- From: Changming Liu [mailto:cliu@netscreen.com] Sent: Wednesday, March 03, 2004 9:20 AM To: 'Bernie Volz '; Changming Liu; ''Ted Lemon ' ' Cc: ''''JINMEI Tatuya / ???? ' ' ' '; 'dhcwg@ietf.org '; ''''Tim Chown ' ' ' ' Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 That could be a solutiuon. But will that break the layered model? Currently our routing is purely based on IP addresses. DNS is just one of the configurations. There could be more. Changming -----Original Message----- From: Bernie Volz To: 'Changming Liu'; 'Ted Lemon ' Cc: '''JINMEI Tatuya / ???? ' ' '; dhcwg@ietf.org; '''Tim Chown ' ' ' Sent: 3/3/2004 5:48 AM Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 For this situation, why don't you advertise BOTH DNS servers (primary and secondary) and simply have the CPE do the proper routing? If the primary link is up, the CPE sends the packets over the primary link. If the primary is down, the CPE sends the packets over the secondary link. Using the routing infrastructure and CPE knowledge of which link is up or down seems to me to be the best solution. Note that you need to do this anyway with any active sessions that are running - as I'm sure your big customer doesn't want all sessions to be broken. It seems to me, unless I don't understand something, there really is no issue here. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Changming Liu Sent: Wednesday, March 03, 2004 3:33 AM To: 'Ted Lemon '; Changming Liu Cc: '''JINMEI Tatuya / ???? ' ' '; '''dhcwg@ietf.org ' ' '; '''Tim Chown ' ' ' Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Hi Ted, >Your scenario seems like a configuration error. Setting things up so >that the client has to update DNS server information immediately on a >frequent basis is simply bad network design. I don't think the goal >of this renumbering effort is to accommodate that kind of >configuration. The right way to fix this is to put a DNS cache >downstream of the flaky link. If I was not clear in describing the scenario, pleae forgive me. Our customer is one of the biggest Telecoes in the world. Without their permission, I can not disclose too much details. Needless to say, it should not be that bad design after so many engineers working on it. Let me try it again in different way. Let's say a multi-homed CPE with two upstream links, one connected to one of its ISPs, one is primary and one is backup. DHCP are enabled on both links for configuration info such as DNS. These two ISPs offer different DNS servers. The requirement is that as long as primary ISP is up, use it right away including DNS. This is due to cost struture. Is this reasonable requirement? This CPE runs DHCP server on the downstream link to pass the DNS info to the local LAN. Once the primary ISP is up, its DNS info neends to push to downstream. Of course, you an hope the primary links never goes down unplanned(if it is true, why dualhome at the first palce?). The lifetime solution does not solve this problem. If you need more info, we can get together to discuss this. Changming Netscreen Technoloies Inc _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 11:50:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09380; Wed, 3 Mar 2004 11:50:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyZZK-0003Om-T3; Wed, 03 Mar 2004 11:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyZYs-0003M3-N4 for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 11:49:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09225 for ; Wed, 3 Mar 2004 11:49:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyZYr-0002Eb-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 11:49:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyZXw-0001zp-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 11:48:37 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1AyZWz-0001a4-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 11:47:37 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i23Gko9u017798; Wed, 3 Mar 2004 08:46:57 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 08:46:49 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C6A3@MONTEREY.netscreen.com> From: Changming Liu To: "'Bernie Volz '" , =?iso-8859-1?Q?=27=27JINMEI_Ta?= =?iso-8859-1?Q?tuya_/_=90=5F-=3FB=8D=C6=27_=27?= Cc: Changming Liu , "'dhcwg@ietf.org '" Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Wed, 3 Mar 2004 08:46:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I think we are going into a rat hole here. My original point is that = the lifetime approach works well for planned change, but it does not work = for unplanned changes. If we decide not to deal with unplanned situation, = that's fine although it is better to have one solution for both.=20 But in my situation, we need to deal with unplanned changes now. I = don't know who else has such an experience or requirement. If they do, please speak up. If our customer's situation is unique, we just need to deal = with it ourselves. Good luck to the lifetime proposal, which solves problems in its own = space, in my opinion. Changming=20 =20 -----Original Message----- From: Bernie Volz To: 'JINMEI Tatuya / =90_-?B=8D=C6' Cc: 'Changming Liu'; dhcwg@ietf.org Sent: 3/3/2004 7:38 AM Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 >>> The requirement is that as long >>> as primary ISP is up, use it right away including DNS. This is due to cost >>> struture. >to mean that we do not want to use the secondary DNS (which would be >located in the secondary ISP) if the primary ISP is up, due to the >cost reason (and perhaps reachability/latency issue also?). I don't know of anyone that charges for use of the DNS to resolve addresses, do you? Latency could be an issue; but that all depends on the routing infrastructure (the secondary link might be slower than the primary, = but if the primary link is up, you'll use the primary link). Place the primary DNS first in the list and it should be preferred; yes there may be some latency before the DNS resolvers switch back to using the primary, but you'll always have some small issue like that. It could also be that the secondary = DNS provider won't accept queries from the primary providers addresses, and in that case you'll have the normal failover between the two DNS servers (resolver will try primary and give up after a timeout and try secondary). Note that the hosts (clients) would likely be using the provider's address as the source address (I'd presume the CPE would advertise both = prefixes and the client would configure addresses on both). Also, if the DNS fails because of addressing issues, what does that say about any open sessions (or connections)? In order for this to be successful, the two providers will have to have some agreement between them to cross route packets and the DNS (and any other essential services) would just have to be part of that. Remember, the providers are after the = best experience for the customer - or if they're not, they'll loose customers. >I've not reached a conclusion (of myself) on whether or not this is >really a serious issue that can be a show-stopper for the lifetime >proposal. However, at least I think Changming has some valid points. Look, you can always find an argument against any solution or at least to reduce the effectiveness of that solution. But remember that keeping it simple is the best. Needlessly reconfiguring clients is no way to go. = It also has latency issues since transactions could be in progress or clients might miss the first (or first few) reconfiguration signals. Putting all this in the routing logic of the CPE means that all the smarts about what to do is located in ONE place and all traffic is treated equal. This, to me, is such a basic routing issue that moving it up to any other layer is, frankly, stupid. - Bernie -----Original Message----- From: JINMEI Tatuya / =90_-=BE'B=8D=C6 = [mailto:jinmei@isl.rdc.toshiba.co.jp]=20 Sent: Wednesday, March 03, 2004 10:14 AM To: Bernie Volz Cc: 'Changming Liu'; dhcwg@ietf.org Subject: Re: [dhcwg] Renumbering Requirements for Stateless DHCPv6 >>>>> On Wed, 3 Mar 2004 08:48:36 -0500,=20 >>>>> "Bernie Volz" said: > For this situation, why don't you advertise BOTH DNS servers (primary and > secondary) and simply have the CPE do the proper routing? If the primary > link is up, the CPE sends the packets over the primary link. If the primary > is down, the CPE sends the packets over the secondary link. Using the > routing infrastructure and CPE knowledge of which link is up or down seems > to me to be the best solution. I read the scenario >> The requirement is that as long >> as primary ISP is up, use it right away including DNS. This is due = to cost >> struture. to mean that we do not want to use the secondary DNS (which would be located in the secondary ISP) if the primary ISP is up, due to the cost reason (and perhaps reachability/latency issue also?). I've not reached a conclusion (of myself) on whether or not this is really a serious issue that can be a show-stopper for the lifetime proposal. However, at least I think Changming has some valid points. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 17:31:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00782; Wed, 3 Mar 2004 17:31:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyetJ-0000oI-Kd; Wed, 03 Mar 2004 17:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayesb-0000lN-OW for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 17:30:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00733 for ; Wed, 3 Mar 2004 17:30:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyesZ-0004YE-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 17:30:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayerg-0004NU-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 17:29:20 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1Ayeqy-0004AV-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 17:28:36 -0500 Received: from [10.0.1.3] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id D7BD022DD83; Wed, 3 Mar 2004 16:24:58 -0600 (CST) In-Reply-To: <200403030703.XAA00308@redback.com> References: <200403030703.XAA00308@redback.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <15B5B744-6D62-11D8-B32B-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: "'dhcwg@ietf.org '" From: Ted Lemon Subject: Re: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Thu, 4 Mar 2004 07:28:24 +0900 To: Naiming Shen X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mar 3, 2004, at 4:03 PM, Naiming Shen wrote: > I think the scaling issue is missing in your text. The router we have > in the network right now handles 60K customers per box, and ISPs > demand that > there need to be 1 or 2 second detection delay if any host is gone. > This > customer number per box can dramatically increase in the future, just > to give some examples here. Randomness does not help here. What does this have to do with DHCP? DHCP doesn't provide the capability you're talking about, whether you use reconfigure or lifetimes. If you are doing something like this, correct me if I am wrong, but I would assume you are relying on some kind of layer 1 or layer 2 mechanism. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 17:36:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01153; Wed, 3 Mar 2004 17:36:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayey9-0001GE-LH; Wed, 03 Mar 2004 17:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyexI-0001BJ-5L for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 17:35:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01050 for ; Wed, 3 Mar 2004 17:35:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyexF-0005Vd-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 17:35:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyewD-0005JA-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 17:34:01 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AyevM-00058f-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 17:33:08 -0500 Received: from [10.0.1.3] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 1080822DDBF; Wed, 3 Mar 2004 16:29:41 -0600 (CST) In-Reply-To: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C694@MONTEREY.netscreen.com> References: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C694@MONTEREY.netscreen.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'dhcwg@ietf.org '" From: Ted Lemon Subject: Re: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Thu, 4 Mar 2004 07:33:06 +0900 To: Changming Liu X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mar 3, 2004, at 5:10 PM, Changming Liu wrote: > We use multicast address > in many places such as RA, why not here? Here multicast reconfigure opens you up to an easy amplification attack - a single packet from the attacker can produce dozens, hundreds or thousands of packets on the server in short succession, depending on your network configuration. So it's very much worth avoiding. Multicast reconfigure also creates a serious risk in the sense that an attacker can disrupt all of the clients on your network very quickly and easily, whereas if you don't support multicast reconfigure the attacker can't get the information it needs to succeed with an attack of this type. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 17:38:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01313; Wed, 3 Mar 2004 17:38:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayf06-0001cl-0s; Wed, 03 Mar 2004 17:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyezP-0001TO-EJ for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 17:37:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01209 for ; Wed, 3 Mar 2004 17:37:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyezM-0005xe-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 17:37:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyeyU-0005kB-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 17:36:22 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1Ayexc-0005XM-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 17:35:28 -0500 Received: from [10.0.1.3] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id A6CFB22DDD3; Wed, 3 Mar 2004 16:32:00 -0600 (CST) In-Reply-To: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C695@MONTEREY.netscreen.com> References: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C695@MONTEREY.netscreen.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <11439BDF-6D63-11D8-B32B-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: "''dhcwg@ietf.org' '" From: Ted Lemon Subject: Re: [dhcwg] draft-chown-dhc-dual-stack-00 Date: Thu, 4 Mar 2004 07:35:26 +0900 To: Changming Liu X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mar 3, 2004, at 5:18 PM, Changming Liu wrote: > It is a very simple solution: when enabling a DHCP client on an > interface, allow the end user to define a preference value from 0 to > 255 and > default to 128. So this is done on the client? Is preference assigned to different classes of DHCP server (e.g., v4 vs. v6) or different server identification information, or what? I can envision a table on the client that contains a list of server ids and preferences, although this seems not so helpful in the sense that the client now has to be configured before it can use the network. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 17:53:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02794; Wed, 3 Mar 2004 17:53:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyfEa-0002qq-PS; Wed, 03 Mar 2004 17:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyfEX-0002qG-5b for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 17:52:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02784 for ; Wed, 3 Mar 2004 17:52:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyfEU-0001el-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 17:52:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyfDf-0001Vc-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 17:52:04 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AyfDG-0001LL-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 17:51:38 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 03 Mar 2004 15:03:34 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i23Mp6Y6016534 for ; Wed, 3 Mar 2004 14:51:06 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-89.cisco.com [10.86.240.89]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGM73929; Wed, 3 Mar 2004 17:51:04 -0500 (EST) Message-Id: <4.3.2.7.2.20040303174249.02a82800@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 03 Mar 2004 17:50:59 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Summary of dhc WG meeting @ IETF 59 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Here's my summary of the meeting; note that this summary focuses on results, not discussion. I will write up and post more detailed minutes separately. Please review and comment by 3/5. - Ralph ----- DHCP Option for Proxy Server Configuration Technical discussion; ready for WG last call? Author justified proxy server option because it provides port number as well as proxy server address. WG consensus for WGLC. Ted Lemon to publish editorial comments during WGLC. The Extended Remote Boot Option for DHCPv4 Technical discussion; ready for WG last call? Author to revise draft to eliminate requirement for sub-options. No WGLC at this time. Vendor-Identifying Vendor Options for DHCPv4 Technical discussion; ready for WG last call? No comments from WG. WG consensus for WGLC. Node-Specific Client Identifiers for DHCPv4 Technical discussion; ready for WG last call? No comments from WG. WG consensus for WGLC. Rapid Commit Option for DHCPv4 Technical discussion; ready for WG last call? No comments from WG. WG consensus for WGLC. Ted Lemon to publish editorial comments during WGLC. DHCPv6 Support for Remote Boot Technical discussion; ready for WG last call? This option may be impacted by dual-stack problem resolution. Some comments from WG. Author to revise for editorial issues and for consistency (where possible) with similar DHCPv4 option. No WGLC at this time. Configured Tunnel End Point Option for DHCPv6 Technical discussion; ready for WG last call? WG consensus that this option is intended for configuring routers, which is out-of-scope. ID to be dropped as WG work item. Reclassifying DHCPv4 Options Technical discussion; ready for WG last call? No comment from WG. Consensus for WGLC. DHCPv4 Support for Conf. IPv6-in-IPv4 Tunnels Accept as WG work item? Should be reviewed by v6ops WG. WG chair to contact v6ops WG chairs to determine how to proceed. Also need to confirm it fits in dhc WG charter. Not accepted as WG work item at this time. Micro-block IP Addr. Alloc. With DHCP Proxy Server Accept as WG work item? Fits in dhc WG charter under "address assignment". Requires discussion to reconcile with DHCPv6 prefix delegation and earlier ODAP work. Not accepted as WG work item at this time. Vendor-Specific Suboption for the DHCP RAIO Accept as WG work item? Lemon concerned that this option will lead to unstandardized RAIO sub-options. WG consensus to accept as WG work item at this time. Renumbering Requirements for Stateless DHCPv6 Accept as WG work item? Addresses issue of updating configuration information obtained through Information-Request. There was some technical discussion by the WG. Charter needs to be updated for this work. WG consensus to accept as WG work item (pending charter update). Lifetime Option for DHCPv6 Accept as WG work item? Charter needs to be updated for this work. WG consensus to accept as WG work item (pending charter update). Multicast Reconf. Protocol for Stateless DHCPv6 Accept as WG work item? Wassserman to take some concerns to dhcwg mailing list. Charter needs to be updated for this work. WG is very interested in this work, but ID is not accepted as WG work item IPv4 and IPv6 Dual-Stack Issues for DHCPv6 Accept as WG work item? Requires WG charter update to take on this work. kre remarked that title is all wrong; draft really discusses problem of accepting configuration from multiple interfaces. WG consensus to accept as WG work item (pending charter update). DHCPv6 IPv4 Information Options Accept as WG work item? (skipped) Update of dhc WG charter Part 1 - OK Part 2 - OK Part 3 - work in progress (security); Droms to ask design team about progress Part 4 - work in progress; design team (Hibbs, chair) reviewing RFC 2131 List of drafts to be dropped; inactive IDs to be explicitly dropped from WG work items New charter items: * Stateless DHCpv6 renumbering () * Dual stack issues * DHCP proxy architecture - Narten to discuss with WG chair before adding to charter WG chair to write up text for each of the three items. WG will discuss on dhcwg mailing list Update on IPR issue with two drafts This agenda item was overtaken events; WG to review three new RFCs: RFC 3667, RFC 3668, RFC 3669: and discuss IPR issues on dhcwg mailing list. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 17:55:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02917; Wed, 3 Mar 2004 17:55:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyfGZ-00030o-JN; Wed, 03 Mar 2004 17:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyfFa-0002wu-5z for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 17:54:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02849 for ; Wed, 3 Mar 2004 17:53:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyfFX-0001pV-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 17:53:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyfEd-0001fx-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 17:53:04 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AyfE8-0001W8-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 17:52:32 -0500 Received: from [10.0.1.3] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id A796E22DC15; Wed, 3 Mar 2004 16:49:04 -0600 (CST) In-Reply-To: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C696@MONTEREY.netscreen.com> References: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C696@MONTEREY.netscreen.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7351462E-6D65-11D8-B32B-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: "'''dhcwg@ietf.org ' ' '" From: Ted Lemon Subject: Re: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Wed, 3 Mar 2004 16:52:30 -0600 To: Changming Liu X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mar 3, 2004, at 2:32 AM, Changming Liu wrote: > The requirement is that as long > as primary ISP is up, use it right away including DNS. This is due to > cost > struture. Is this reasonable requirement? Sure. The right way to do this is to set up a DNS caching server that normally contacts the primary ISP's DNS server to resolve queries, but will contact the secondary if the primary doesn't answer. This allows for automatic failover, with no significant time delay. If it's set up right, the user shouldn't even notice when the switch happens. The point is that the wrong way to do it is to do it with DHCP. The DNS protocol is already designed to correctly handle the situation you're describing, so there's no reason to place the burden on the DHCP protocol to solve this problem. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 17:59:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03073; Wed, 3 Mar 2004 17:59:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyfKP-0003mS-3d; Wed, 03 Mar 2004 17:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyfKG-0003ly-S2 for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 17:58:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03068 for ; Wed, 3 Mar 2004 17:58:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyfKE-0002ck-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 17:58:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyfJK-0002Tu-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 17:57:54 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1AyfIe-0002Bb-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 17:57:12 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i23MuZ9u012635; Wed, 3 Mar 2004 14:56:39 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 14:56:35 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C6A6@MONTEREY.netscreen.com> From: Changming Liu To: "'Ted Lemon '" , Changming Liu Cc: "'''dhcwg@ietf.org' ' '" Subject: RE: [dhcwg] draft-chown-dhc-dual-stack-00 Date: Wed, 3 Mar 2004 14:56:34 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is done on the client. No table is required execpt one additional attribute is difined in client data structure. Once the client learns any configuration info, its preference is checked to see if it is better or equal than currentlly installed. If so, install it and the system start to use it. Otherwise, ignore it (actually installed in the client table). There are some minor details which can be easy to be figured out. For devices with multiple DHCP client enabled, I guess usually some kind of config may be needed anyway. Otherwise the latest one will always be used based on the above rule as they will have the same preference by default. But you do have a point. As I said earlier, this can be done on the server side as well but some co-ordination is required among these server, which may not be possible in some environment. CHangming. -----Original Message----- From: Ted Lemon To: Changming Liu Cc: ''dhcwg@ietf.org' ' Sent: 3/3/2004 2:35 PM Subject: Re: [dhcwg] draft-chown-dhc-dual-stack-00 On Mar 3, 2004, at 5:18 PM, Changming Liu wrote: > It is a very simple solution: when enabling a DHCP client on an > interface, allow the end user to define a preference value from 0 to > 255 and > default to 128. So this is done on the client? Is preference assigned to different classes of DHCP server (e.g., v4 vs. v6) or different server identification information, or what? I can envision a table on the client that contains a list of server ids and preferences, although this seems not so helpful in the sense that the client now has to be configured before it can use the network. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From fglinfonet@mail.com Wed Mar 3 18:20:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05394 for ; Wed, 3 Mar 2004 18:20:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayffb-0006aA-00 for dhc-archive@ietf.org; Wed, 03 Mar 2004 18:20:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyfeF-0006Al-00 for dhc-archive@ietf.org; Wed, 03 Mar 2004 18:19:33 -0500 Received: from c-24-1-63-3.client.comcast.net ([24.1.63.3] helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1AyfcQ-0005jF-00; Wed, 03 Mar 2004 18:17:40 -0500 From: "Fórum Social / Bombay . wcf" To: dccp-request@ietf.org Subject: Preocupante articulação - Informe exclusivo ref.: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Wed, 03 Mar 2004 18:17:40 -0500 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=11.2 required=5.0 tests=AWL,HTML_50_60,HTML_FONT_BIG, HTML_MESSAGE,MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT, REMOVE_REMOVAL_2WORD,SUBJ_HAS_SPACES,SUBJ_HAS_UNIQ_ID, SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 0.2 SUBJ_HAS_UNIQ_ID Subject contains a unique ID * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.0 AWL AWL: Auto-whitelist adjustment

Ref. Addr. Book: (eqm) EnEspañol - English:FreeAutomaticTranslator - Retirar-Remover

Caros amigos,

Temos o prazer de oferecer-lhes com exclusividade e gratuitamente o e-Book "4º Fórum Social Mundial: preocupante articulação revolucionária" (Bombay, 2004), elaborado pela agência hispana Destaque Internacional. Na continuação, transcrevemos o índice de tal Informe. Simplesmente faça clic em FSM-Bombay:e-BookGratuitoBr . Cordialmente, Ferreira-Passos, Atualidade Brasileira, Rio de Janeiro (RJ). Postdata importante: Para receber, também gratuitamente, o Informe sobre as próximas eleições presidenciais em El Salvador, veja links no final.

4o. Fórum Social Mundial:

preocupante articulação revolucionária

(Bombay, Janeiro 16-21, 2004)

A verdade sobre um evento alter-mundialista desdenhado por uns e admirado por outros, a respeito do qual muito se falou, porém pouco se conheceu

1. Neo-imperialismo de uma potência mundial "emergente"

Os milhares de ativistas presentes em Bombay reconhecem que a meta é transformar suas redes na "segunda potência mundial", capaz de modificar radicalmente o panorama da Índia, da Ásia e do mundo

2. O porquê da Índia

Instrumentação revolucionária de "excluídos" e galvanização das esquerdas, duas metas do FSM para o país de segunda maior população do mundo

3. "Dalits", "adivasis" e teologia da libertação

Correntes "liberacionistas" da Índia e da Ásia tentam anular o efeito sócio-político paralizante da religião brahmânica, para impulsionar a revolução socia.

4. Mumbai Resistance 2004 e MST

Evento paralelo ao 4º FSM contribui à "politização" e radicalização deste, com a colaboração do brasileiro Movimento dos Trabalhadores Rurais Sem Terra (MST)

5. Eixo contestatário Índia-Brasil

O FSM como "novo protagonista" e "ponte" para alcançar uma esquerdização da atual correlação de forças internacional

6. "Catalisação" alter-mundialista, "sinergia" e nova "racionalidade"

O evento de Bombay, enquanto enorme e preocupante articulação revolucionária, deve ser analisado segundo o sábio ensinamento de Santo Tomás: "ver, julgar e atuar"

Redação: Destaque Internacional, de Madri, com a colaboração de seus enviados especiais a Bombay, Suresh Noronha, T. F. Joseph e Sunil Abrahan. Tradução: Graça Salgueiro, Brasil.

LINKS:

FSM-Bombay:MinhaOpinião

FSM-Bombay:e-BookGratuitoBr

DestaqueInternacional:Subscrever

InformeElSalvador(ResumoEmPortuguês)

InformeElSalvador(TextoCompletoEmEspanhol)

NextMessages:OnlyInEnglish

ProximosEnvios:SoloEnEspañol

DestaqueInternacional:Retirar-Remover (nota importante: por um lamentável acidente digital foram apagados, sem serem processados, os pedidos de remoção chegados no mes de janeiro de 2004; àqueles que o tiverem feito, apresentamos nossas mais sinceras desculpas, e solicitamos re-enviarem o pedido de Remoção).

  

 

 

From dhcwg-admin@ietf.org Wed Mar 3 19:31:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09859; Wed, 3 Mar 2004 19:31:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyglT-0001B2-NI; Wed, 03 Mar 2004 19:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyglN-0001AC-Jd for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 19:30:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09848 for ; Wed, 3 Mar 2004 19:30:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyglL-0003z3-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 19:30:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AygkV-0003pr-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 19:30:04 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1Aygjb-0003Vs-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 19:29:07 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HU000E0CZZOQQ@mailout3.samsung.com> for dhcwg@ietf.org; Thu, 04 Mar 2004 09:28:36 +0900 (KST) Received: from ep_ms3_bk (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HU000GR4ZZDG9@mailout3.samsung.com> for dhcwg@ietf.org; Thu, 04 Mar 2004 09:28:25 +0900 (KST) Received: from ep_spt02 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HU000JGZZZDJ6@ms3.samsung.com> for dhcwg@ietf.org; Thu, 04 Mar 2004 09:28:25 +0900 (KST) Content-return: prohibited Date: Thu, 04 Mar 2004 00:28:35 +0000 (GMT) From: PARK SOO HONG Subject: Re :[dhcwg] Summary of dhc WG meeting @ IETF 59 X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9Nb2JpbA==?= =?windows-1252?B?ZSBQbGF0Zm9ybSBMYWI/UmVzZWFyY2hlcg==?= To: Ralph Droms Cc: "dhcwg@ietf.org " Reply-to: soohong.park@samsung.com Message-id: <0HU000JH0ZZDJ6@ms3.samsung.com> MIME-version: 1.0 Content-type: text/html; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20040304002811889@soohong.park X-MTR: 20040304002811889@soohong.park X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Generator: NamoMIME 1.1.0.14 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.8 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE, MIME_HTML_ONLY,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Samsung Enterprise Portal mySingle


Ralph

 


>Configured Tunnel End Point Option for DHCPv6
>   <draft-ietf-dhc-dhcpv6-ctep-opt-01>
>   Technical discussion; ready for WG last call?

>   WG consensus that this option is intended for configuring routers,
>   which is out-of-scope.  ID to be dropped as WG work item.


No. this option is not intended for configuring routers. Vijay and I will clarify

this point why we need this option for IPv6 connectivity through configured tunnel.

This option is for host configuration as well.

So don't drop this item for a while....


Regards

 

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics


_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 19:46:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10567; Wed, 3 Mar 2004 19:46:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aygzx-0002zd-TS; Wed, 03 Mar 2004 19:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aygzp-0002yr-Ik for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 19:45:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10518 for ; Wed, 3 Mar 2004 19:45:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aygzn-0006UR-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 19:45:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aygyp-0006Ju-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 19:44:51 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1Aygxx-00061x-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 19:43:57 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i240hJ9u019973; Wed, 3 Mar 2004 16:43:19 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 16:43:19 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C6A8@MONTEREY.netscreen.com> From: Changming Liu To: "'Ralph Droms '" , "'dhcwg@ietf.org '" Date: Wed, 3 Mar 2004 16:43:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [dhcwg] Default route issue Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Sorry, folks it's me again. We also have another issue with default route(r) in the following scenario. In a palnned network deployment, our device is acted as a CPE router which communicates with upstream PE router through DHCPv6 for configuration info. There are potential huge volume of CPE devices, so manual configuration of each CPE is deemed un-acceptable operationally. For the same reason, no dynamic routing protocol is planned to be deployed. Because RA can not be used to learn the default routers by other routers themselves, one of kludge solutions we come with is to learn default routers via DHCPv6. The PE acted as DHCPv6 server is accepted as the default router on the CPE. Do you have any suggestions? Any other better way? Thanks in advance. Changming _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 19:51:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10733; Wed, 3 Mar 2004 19:51:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayh4n-0003JX-6d; Wed, 03 Mar 2004 19:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayh4i-0003Iw-Mv for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 19:50:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10718 for ; Wed, 3 Mar 2004 19:50:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayh4g-0007HL-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 19:50:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayh3l-00077e-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 19:49:58 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1Ayh37-0006pl-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 19:49:17 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i240ml9u020334; Wed, 3 Mar 2004 16:48:47 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 16:48:47 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C6A9@MONTEREY.netscreen.com> From: Changming Liu To: "'Ted Lemon '" , Changming Liu Cc: "''''dhcwg@ietf.org ' ' ' '" Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Wed, 3 Mar 2004 16:48:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Are you talking about CPE being a proxy? Marked already suggested that and I've replied his email. If not proxy, the primary and backup selections need to be passed to the client PCs once any of these ones is changed. That's why we need the reconfigure message at the first place. Changming -----Original Message----- From: Ted Lemon To: Changming Liu Cc: '''dhcwg@ietf.org ' ' ' Sent: 3/3/2004 2:52 PM Subject: Re: [dhcwg] Renumbering Requirements for Stateless DHCPv6 On Mar 3, 2004, at 2:32 AM, Changming Liu wrote: > The requirement is that as long > as primary ISP is up, use it right away including DNS. This is due to > cost > struture. Is this reasonable requirement? Sure. The right way to do this is to set up a DNS caching server that normally contacts the primary ISP's DNS server to resolve queries, but will contact the secondary if the primary doesn't answer. This allows for automatic failover, with no significant time delay. If it's set up right, the user shouldn't even notice when the switch happens. The point is that the wrong way to do it is to do it with DHCP. The DNS protocol is already designed to correctly handle the situation you're describing, so there's no reason to place the burden on the DHCP protocol to solve this problem. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 20:11:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11681; Wed, 3 Mar 2004 20:11:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyhOA-0005IJ-Pu; Wed, 03 Mar 2004 20:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyhND-0005Df-0L for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 20:10:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11630 for ; Wed, 3 Mar 2004 20:10:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyhNA-0002ml-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 20:10:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyhMI-0002di-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 20:09:06 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1AyhLw-0002Tx-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 20:08:44 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HU100G041TQM5@mailout3.samsung.com> for dhcwg@ietf.org; Thu, 04 Mar 2004 10:08:14 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HU100F2A1TP76@mailout3.samsung.com> for dhcwg@ietf.org; Thu, 04 Mar 2004 10:08:13 +0900 (KST) Received: from Alperyegin ([107.10.71.1]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HU100I841TLXK@mmp2.samsung.com> for dhcwg@ietf.org; Thu, 04 Mar 2004 10:08:13 +0900 (KST) Date: Wed, 03 Mar 2004 17:08:10 -0800 From: Alper Yegin Subject: RE: [dhcwg] Summary of dhc WG meeting @ IETF 59 In-reply-to: <4.3.2.7.2.20040303174249.02a82800@flask.cisco.com> To: "'Ralph Droms'" , dhcwg@ietf.org Message-id: <000001c40185$2b695ce0$e22f10ac@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > Configured Tunnel End Point Option for DHCPv6 > > Technical discussion; ready for WG last call? > > WG consensus that this option is intended for configuring routers, > which is out-of-scope. ID to be dropped as WG work item. I wasn't at the meeting, so I might be missing something. But reading this summary, I think this criteria is not sufficient to not adapt a draft. Otherwise prefix delegation mechanism would not have been an RFC (3633). Alper _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 21:17:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16576; Wed, 3 Mar 2004 21:17:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiQ1-0004qK-0n; Wed, 03 Mar 2004 21:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiPR-0004go-3k for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 21:16:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16374 for ; Wed, 3 Mar 2004 21:16:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyiPO-0000Cp-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 21:16:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyiOM-0007lc-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 21:15:19 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1AyiNV-0007V4-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 21:14:25 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HU100J044V6QV@mailout3.samsung.com> for dhcwg@ietf.org; Thu, 04 Mar 2004 11:13:54 +0900 (KST) Received: from ep_ms3_bk (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HU100LZA4V6W3@mailout3.samsung.com> for dhcwg@ietf.org; Thu, 04 Mar 2004 11:13:54 +0900 (KST) Received: from ep_spt02 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HU1002J54V65M@ms3.samsung.com> for dhcwg@ietf.org; Thu, 04 Mar 2004 11:13:54 +0900 (KST) Content-return: prohibited Date: Thu, 04 Mar 2004 02:14:05 +0000 (GMT) From: PARK SOO HONG Subject: Re :[dhcwg] Summary of dhc WG meeting @ IETF 59 X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9Nb2JpbA==?= =?windows-1252?B?ZSBQbGF0Zm9ybSBMYWI/UmVzZWFyY2hlcg==?= To: Ralph Droms Cc: "dhcwg@ietf.org " Reply-to: soohong.park@samsung.com Message-id: <0HU1002J64V65M@ms3.samsung.com> MIME-version: 1.0 Content-type: text/html; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20040304021341713@soohong.park X-MTR: 20040304021341713@soohong.park X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Generator: NamoMIME 1.1.0.14 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE, MIME_HTML_ONLY,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Samsung Enterprise Portal mySingle
> DHCPv4 Support for Conf. IPv6-in-IPv4 Tunnels
>    <draft-daniel-dhc-ipv6in4-tunnels-00>
>    Accept as WG work item?
>
>    Should be reviewed by v6ops WG.  WG chair to contact v6ops WG chairs
>    to determine how to proceed.  Also need to confirm it fits in dhc WG
>    charter.  Not accepted as WG work item at this time.

 

Ralph, please make sure that this mechanism is for configuring DHCP client

explicitly. I think we can gather some comments from v6ops WG but I am sure

that kind of utility should be attached to the charter of dhc WG just like a dual

stack issue. It's not scenario at all...





Regards

 

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics


_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 22:40:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22111; Wed, 3 Mar 2004 22:40:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyjiN-0007FE-Ge; Wed, 03 Mar 2004 22:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyjhR-0007Dy-RO for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 22:39:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22041 for ; Wed, 3 Mar 2004 22:39:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyjhO-0001Ts-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 22:39:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyjgV-0001Ja-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 22:38:08 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1Ayjfi-000196-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 22:37:18 -0500 Received: from [10.0.1.3] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 31CC41B2E47; Wed, 3 Mar 2004 21:33:45 -0600 (CST) In-Reply-To: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C6A9@MONTEREY.netscreen.com> References: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C6A9@MONTEREY.netscreen.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <388F54EE-6D8D-11D8-B32B-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: "''''dhcwg@ietf.org ' ' ' '" From: Ted Lemon Subject: Re: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Wed, 3 Mar 2004 21:37:11 -0600 To: Changming Liu X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Are you talking about CPE being a proxy? Marked already suggested that > and > I've replied his email. > > If not proxy, the primary and backup selections need to be passed to > the > client PCs once any of these ones is changed. That's why we need the > reconfigure message at the first place. No, I am talking about a DNS caching name server, not a proxy. There are no proxies in DNS. I'd suggest reading RFC1033 and RFC1034 to get some background on how this is done. You seem to be attempting to re-engineer the Internet on the back of DHCP. You are not talking about unplanned renumbering - you are talking about a planned system for on-the-fly reconfiguration based on asynchronous events. Whether or not this is a good idea, it is out of scope for the DHC working group, and is not part of the stated goal of the effort we are currently undertaking. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 3 22:40:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22113; Wed, 3 Mar 2004 22:40:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyjiP-0007FN-CR; Wed, 03 Mar 2004 22:40:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayjhd-0007EG-8t for dhcwg@optimus.ietf.org; Wed, 03 Mar 2004 22:39:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22071 for ; Wed, 3 Mar 2004 22:39:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyjhZ-0001VY-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 22:39:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayjge-0001LC-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 22:38:17 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1Ayjfx-0001AH-00 for dhcwg@ietf.org; Wed, 03 Mar 2004 22:37:34 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by pan.gwi.net (8.12.6p3/8.12.6) with ESMTP id i243bEGn026005; Wed, 3 Mar 2004 22:37:23 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Changming Liu'" , "'''Ted Lemon ' ' '" Cc: "'''''JINMEI Tatuya / ???? ' ' ' ' '" , , "'''''Tim Chown ' ' ' ' '" Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Wed, 3 Mar 2004 22:37:23 -0500 Message-ID: <000e01c4019a$04e4a060$6601a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C6A2@MONTEREY.netscreen.com> Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Where is the primary DNS server and why can't it be used anymore? What I assume you have is: <----primary link----> Customer network <----> CPE Service Provider <----secondary link--> If the DNS server is in the customer network or the CPE, there's no = issue since the links don't matter. If the DNS server is in the service provider(s) network (which is where = I assume they are), even if the links go to separate providers, why can't packets sent over either link reach either DNS server for resolving? Whether packets go over the primary or secondary link shouldn't really affect whether they reach their destination. That's why it is a routing issue. If there are two separate service providers, the providers will need to agree to transit traffic to each other. But they need to do this anyway, otherwise you'll have to renumber the customer network each time the = links flop and you end up breaking any active connections - which the customer isn't going to like and basically means that secondary link is pretty = much worthless. If you have some other configuration, please describe it in greater = detail so I can understand why the primary DNS server wouldn't be reachable via = the secondary link. - Bernie =20 -----Original Message----- From: Changming Liu [mailto:cliu@netscreen.com]=20 Sent: Wednesday, March 03, 2004 11:35 AM To: 'Bernie Volz '; Changming Liu; '''Ted Lemon ' ' ' Cc: '''''JINMEI Tatuya / ???? ' ' ' ' '; 'dhcwg@ietf.org '; '''''Tim = Chown ' ' ' ' ' Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Bernie, I may miss your point. The primary and backup DNS servers' addresses are different. When switching-over from backup to primary happens, the = backup's DNS server's address can not be used any more. How does it become a = routing issue? Changming -----Original Message----- From: Bernie Volz To: 'Changming Liu'; ''Ted Lemon ' ' Cc: ''''JINMEI Tatuya / ???? ' ' ' '; dhcwg@ietf.org; ''''Tim Chown ' ' = ' ' Sent: 3/3/2004 6:35 AM Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Huh? How does this break anything? This is exactly what routing is all about. And it is exactly what layering is all about. The application layer (such as DNS) shouldn't care exactly what route packets take to reach their destination - that's the responsibility of IP, not DNS. As I said earlier, any active connections (or sessions) will need to be re-routed over the link that's up and preferred, and you would not want to break these connections (sessions). Note also that: - This will be instantaneous (or as close as you can get) since the CPE can switch links as soon as the primary link returns (or the primary link is marked down). - Will redirect *ALL* traffic, which is exactly what you want. - Is transparent to all applications and works for all applications (anything above the IP layer). - Allows fancier use of the two links as well - such as for load balancing. This is not a DHCP issue at all, but just a standard routing issue. - Bernie -----Original Message----- From: Changming Liu [mailto:cliu@netscreen.com]=20 Sent: Wednesday, March 03, 2004 9:20 AM To: 'Bernie Volz '; Changming Liu; ''Ted Lemon ' ' Cc: ''''JINMEI Tatuya / ???? ' ' ' '; 'dhcwg@ietf.org '; ''''Tim Chown ' ' ' ' Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 That could be a solutiuon. But will that break the layered model? Currently our routing is purely based on IP addresses. DNS is just one of the configurations. There could be more. Changming -----Original Message----- From: Bernie Volz To: 'Changming Liu'; 'Ted Lemon ' Cc: '''JINMEI Tatuya / ???? ' ' '; dhcwg@ietf.org; '''Tim Chown ' ' ' Sent: 3/3/2004 5:48 AM Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 For this situation, why don't you advertise BOTH DNS servers (primary and secondary) and simply have the CPE do the proper routing? If the primary link is up, the CPE sends the packets over the primary link. If the primary is down, the CPE sends the packets over the secondary link. Using the routing infrastructure and CPE knowledge of which link is up or down seems to me to be the best solution. Note that you need to do this anyway with any active sessions that are running - as I'm sure your big customer doesn't want all sessions to be broken. It seems to me, unless I don't understand something, there really is no issue here. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Changming Liu Sent: Wednesday, March 03, 2004 3:33 AM To: 'Ted Lemon '; Changming Liu Cc: '''JINMEI Tatuya / ???? ' ' '; '''dhcwg@ietf.org ' ' '; '''Tim Chown ' ' ' Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Hi Ted,=20 >Your scenario seems like a configuration error. Setting things up so=20 >that the client has to update DNS server information immediately on a=20 >frequent basis is simply bad network design. I don't think the goal=20 >of this renumbering effort is to accommodate that kind of=20 >configuration. The right way to fix this is to put a DNS cache=20 >downstream of the flaky link. If I was not clear in describing the scenario, pleae forgive me. Our customer is one of the biggest Telecoes in the world. Without their permission, I can not disclose too much details. Needless to say, it should not be that bad design after so many engineers working on it.=20 Let me try it again in different way. Let's say a multi-homed CPE with two upstream links, one connected to one of its ISPs, one is primary and one is backup. DHCP are enabled on both links for configuration info such as DNS. These two ISPs offer different DNS servers. The requirement is that as long as primary ISP is up, use it right away including DNS. This is due to cost struture. Is this reasonable requirement?=20 This CPE runs DHCP server on the downstream link to pass the DNS info to the local LAN. Once the primary ISP is up, its DNS info neends to push to downstream. Of course, you an hope the primary links never goes down unplanned(if it is true, why dualhome at the first palce?). The lifetime solution does not solve this problem. If you need more info, we can get together to discuss this. Changming Netscreen Technoloies Inc _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Mar 4 00:44:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01202; Thu, 4 Mar 2004 00:44:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyleN-00068w-3a; Thu, 04 Mar 2004 00:44:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayldq-0005qV-Vn for dhcwg@optimus.ietf.org; Thu, 04 Mar 2004 00:43:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01035 for ; Thu, 4 Mar 2004 00:43:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayldo-0002j3-00 for dhcwg@ietf.org; Thu, 04 Mar 2004 00:43:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aylcn-0002Ru-00 for dhcwg@ietf.org; Thu, 04 Mar 2004 00:42:25 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1AylbV-000252-00 for dhcwg@ietf.org; Thu, 04 Mar 2004 00:41:06 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i245eZ9u007406; Wed, 3 Mar 2004 21:40:35 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 21:40:35 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C6AF@MONTEREY.netscreen.com> From: Changming Liu To: "'Ted Lemon '" , Changming Liu Cc: "'''''dhcwg@ietf.org ' ' ' ' '" Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Wed, 3 Mar 2004 21:40:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >No, I am talking about a DNS caching name server, not a proxy. There >are no proxies in DNS. I'd suggest reading RFC1033 and RFC1034 to get >some background on how this is done. I guess I can assume I know how DNS works having implemented DNS client, and proxy and NATPT for DNS. What you have asked effectively is to ask routers to look up DNS cache for through traffic without being a proxy. I don't know how many moderm routers do that. DNS is just one of the configurations passed by the DHCP. How about NTP server? How about many many opotions? THat's what I said in another email, we are going into rat hole. We need to take one step back to look at the bigger picture. >You seem to be attempting to re-engineer the Internet on the back of DHCP. No, I am not. We will consider whatever good sugguestions some of you have made. As long as it works, who cares. >You are not talking about unplanned renumbering - you are >talking about a planned system for on-the-fly reconfiguration based on >asynchronous events. Whatever the definition is, there is a problem. The lifetime based solution does not work for this planned system for the on-the-fly change. BTW, how many system deployed are not "planned system"? >Whether or not this is a good idea, it is out of >scope for the DHC working group, and is not part of the stated goal of >the effort we are currently undertaking. I am quite new to this group. Don't know who else has a say on this besides you? I originally thought it is entire working group's decision, not a particular person. But I could be completely wrong. If that's the case, please forgive me. I'll stop posting. Changming _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Mar 4 00:53:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01953; Thu, 4 Mar 2004 00:53:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayln3-0007dA-IE; Thu, 04 Mar 2004 00:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AylmD-0007Yy-Sp for dhcwg@optimus.ietf.org; Thu, 04 Mar 2004 00:52:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01924 for ; Thu, 4 Mar 2004 00:52:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AylmB-0004j5-00 for dhcwg@ietf.org; Thu, 04 Mar 2004 00:52:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyllG-0004Zv-00 for dhcwg@ietf.org; Thu, 04 Mar 2004 00:51:11 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1AylkT-0004Gj-00 for dhcwg@ietf.org; Thu, 04 Mar 2004 00:50:21 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i245nh9u007799; Wed, 3 Mar 2004 21:49:43 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 21:49:43 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C6B0@MONTEREY.netscreen.com> From: Changming Liu To: "'Bernie Volz '" , Changming Liu , "''''Ted Lemon ' ' ' '" Cc: "''''''JINMEI Tatuya / ???? ' ' ' ' ' '" , "'dhcwg@ietf.org '" , "''''''Tim Chown ' ' ' ' ' '" Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Wed, 3 Mar 2004 21:49:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Unfortunately, the links go to different ISPs and DNS servers in each ISP don't have all the entrties of the each other. I'm saying ISP in a very broad sense. It can be a IPsec VPN tunnel to the corporate central office. Another concern our customer has is the security, because they don't want the DNS info on the backup (which may be through IPsec VPN tunnel) to be sent to the public (the primary). (Otherwise the hacker may now know a host called xyz in the corporate network abc.com if the hacker just happens to be sniffing around). Changming -----Original Message----- From: Bernie Volz To: 'Changming Liu'; '''Ted Lemon ' ' ' Cc: '''''JINMEI Tatuya / ???? ' ' ' ' '; dhcwg@ietf.org; '''''Tim Chown ' ' ' ' ' Sent: 3/3/2004 7:37 PM Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Where is the primary DNS server and why can't it be used anymore? What I assume you have is: <----primary link----> Customer network <----> CPE Service Provider <----secondary link--> If the DNS server is in the customer network or the CPE, there's no issue since the links don't matter. If the DNS server is in the service provider(s) network (which is where I assume they are), even if the links go to separate providers, why can't packets sent over either link reach either DNS server for resolving? Whether packets go over the primary or secondary link shouldn't really affect whether they reach their destination. That's why it is a routing issue. If there are two separate service providers, the providers will need to agree to transit traffic to each other. But they need to do this anyway, otherwise you'll have to renumber the customer network each time the links flop and you end up breaking any active connections - which the customer isn't going to like and basically means that secondary link is pretty much worthless. If you have some other configuration, please describe it in greater detail so I can understand why the primary DNS server wouldn't be reachable via the secondary link. - Bernie -----Original Message----- From: Changming Liu [mailto:cliu@netscreen.com] Sent: Wednesday, March 03, 2004 11:35 AM To: 'Bernie Volz '; Changming Liu; '''Ted Lemon ' ' ' Cc: '''''JINMEI Tatuya / ???? ' ' ' ' '; 'dhcwg@ietf.org '; '''''Tim Chown ' ' ' ' ' Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Bernie, I may miss your point. The primary and backup DNS servers' addresses are different. When switching-over from backup to primary happens, the backup's DNS server's address can not be used any more. How does it become a routing issue? Changming -----Original Message----- From: Bernie Volz To: 'Changming Liu'; ''Ted Lemon ' ' Cc: ''''JINMEI Tatuya / ???? ' ' ' '; dhcwg@ietf.org; ''''Tim Chown ' ' ' ' Sent: 3/3/2004 6:35 AM Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Huh? How does this break anything? This is exactly what routing is all about. And it is exactly what layering is all about. The application layer (such as DNS) shouldn't care exactly what route packets take to reach their destination - that's the responsibility of IP, not DNS. As I said earlier, any active connections (or sessions) will need to be re-routed over the link that's up and preferred, and you would not want to break these connections (sessions). Note also that: - This will be instantaneous (or as close as you can get) since the CPE can switch links as soon as the primary link returns (or the primary link is marked down). - Will redirect *ALL* traffic, which is exactly what you want. - Is transparent to all applications and works for all applications (anything above the IP layer). - Allows fancier use of the two links as well - such as for load balancing. This is not a DHCP issue at all, but just a standard routing issue. - Bernie -----Original Message----- From: Changming Liu [mailto:cliu@netscreen.com] Sent: Wednesday, March 03, 2004 9:20 AM To: 'Bernie Volz '; Changming Liu; ''Ted Lemon ' ' Cc: ''''JINMEI Tatuya / ???? ' ' ' '; 'dhcwg@ietf.org '; ''''Tim Chown ' ' ' ' Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 That could be a solutiuon. But will that break the layered model? Currently our routing is purely based on IP addresses. DNS is just one of the configurations. There could be more. Changming -----Original Message----- From: Bernie Volz To: 'Changming Liu'; 'Ted Lemon ' Cc: '''JINMEI Tatuya / ???? ' ' '; dhcwg@ietf.org; '''Tim Chown ' ' ' Sent: 3/3/2004 5:48 AM Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 For this situation, why don't you advertise BOTH DNS servers (primary and secondary) and simply have the CPE do the proper routing? If the primary link is up, the CPE sends the packets over the primary link. If the primary is down, the CPE sends the packets over the secondary link. Using the routing infrastructure and CPE knowledge of which link is up or down seems to me to be the best solution. Note that you need to do this anyway with any active sessions that are running - as I'm sure your big customer doesn't want all sessions to be broken. It seems to me, unless I don't understand something, there really is no issue here. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Changming Liu Sent: Wednesday, March 03, 2004 3:33 AM To: 'Ted Lemon '; Changming Liu Cc: '''JINMEI Tatuya / ???? ' ' '; '''dhcwg@ietf.org ' ' '; '''Tim Chown ' ' ' Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Hi Ted, >Your scenario seems like a configuration error. Setting things up so >that the client has to update DNS server information immediately on a >frequent basis is simply bad network design. I don't think the goal >of this renumbering effort is to accommodate that kind of >configuration. The right way to fix this is to put a DNS cache >downstream of the flaky link. If I was not clear in describing the scenario, pleae forgive me. Our customer is one of the biggest Telecoes in the world. Without their permission, I can not disclose too much details. Needless to say, it should not be that bad design after so many engineers working on it. Let me try it again in different way. Let's say a multi-homed CPE with two upstream links, one connected to one of its ISPs, one is primary and one is backup. DHCP are enabled on both links for configuration info such as DNS. These two ISPs offer different DNS servers. The requirement is that as long as primary ISP is up, use it right away including DNS. This is due to cost struture. Is this reasonable requirement? This CPE runs DHCP server on the downstream link to pass the DNS info to the local LAN. Once the primary ISP is up, its DNS info neends to push to downstream. Of course, you an hope the primary links never goes down unplanned(if it is true, why dualhome at the first palce?). The lifetime solution does not solve this problem. If you need more info, we can get together to discuss this. Changming Netscreen Technoloies Inc _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Mar 4 08:11:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17814; Thu, 4 Mar 2004 08:11:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayscv-0003Ij-Kc; Thu, 04 Mar 2004 08:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyscP-0003Dn-Ta for dhcwg@optimus.ietf.org; Thu, 04 Mar 2004 08:10:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17703 for ; Thu, 4 Mar 2004 08:10:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyscO-0000SE-00 for dhcwg@ietf.org; Thu, 04 Mar 2004 08:10:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AysbQ-0000FO-00 for dhcwg@ietf.org; Thu, 04 Mar 2004 08:09:29 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AysaW-00001s-00 for dhcwg@ietf.org; Thu, 04 Mar 2004 08:08:32 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id i24D8F57036720; Thu, 4 Mar 2004 08:08:25 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Changming Liu'" Cc: "''''''JINMEI Tatuya / ???? ' ' ' ' ' '" , , "''''''Tim Chown ' ' ' ' ' '" , "''''Ted Lemon ' ' ' '" Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Date: Thu, 4 Mar 2004 08:08:24 -0500 Message-ID: <000401c401e9$ca42a6f0$6601a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C6B0@MONTEREY.netscreen.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I really fail to see the utility of this and it really is not = main-stream. I fail to see how the secondary link is a backup for the primary link and = why anyone would ever want to do this - you can't arbitrarily start sending traffic down a link that is a completely different purpose and enters a completely different domain. All of the active connections/sessions are going to break and that has very little value. Also, how is a user or applications on clients going to know that this "shift" in the links has taken place and want to take appropriate = action? If users are sitting at a client browsing the web (intranet or Internet), = how will they all of a sudden know that they should stop doing so because a switch in the links has taken place and they should stop browsing the = xyz host that's in the corporate network because they're now back on the = public link? - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Changming Liu Sent: Thursday, March 04, 2004 12:50 AM To: 'Bernie Volz '; Changming Liu; ''''Ted Lemon ' ' ' ' Cc: ''''''JINMEI Tatuya / ???? ' ' ' ' ' '; 'dhcwg@ietf.org '; ''''''Tim Chown ' ' ' ' ' ' Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6 Unfortunately, the links go to different ISPs and DNS servers in each = ISP don't have all the entrties of the each other. I'm saying ISP in a very broad sense. It can be a IPsec VPN tunnel to the corporate central = office. Another concern our customer has is the security, because they don't = want the DNS info on the backup (which may be through IPsec VPN tunnel) to be sent to the public (the primary). (Otherwise the hacker may now know a = host called xyz in the corporate network abc.com if the hacker just happens = to be sniffing around). Changming=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Mar 4 22:52:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02620; Thu, 4 Mar 2004 22:52:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az6NU-0003w9-Qr; Thu, 04 Mar 2004 22:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az6Mh-0003vX-9d for dhcwg@optimus.ietf.org; Thu, 04 Mar 2004 22:51:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02586 for ; Thu, 4 Mar 2004 22:51:06 -0500 (EST) From: margaret@thingmagic.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az6Md-0001vI-00 for dhcwg@ietf.org; Thu, 04 Mar 2004 22:51:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az6Lh-0001lH-00 for dhcwg@ietf.org; Thu, 04 Mar 2004 22:50:10 -0500 Received: from [210.97.99.67] (helo=lovebank) by ietf-mx with smtp (Exim 4.12) id 1Az6LG-0001bE-00 for dhcwg@ietf.org; Thu, 04 Mar 2004 22:49:42 -0500 Date: Fri, 05 Mar 2004 12:49:42 +0900 To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------vipqlbpkecefggavrxcs" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Subject: [dhcwg] Weeeeee! ;))) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , ----------vipqlbpkecefggavrxcs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_BAGLE.GEN-1 in file TextDocument.zip The file is deleted. --------------------------------------------------------- ----------vipqlbpkecefggavrxcs Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The access is open !!! 74763 -- archive password ----------vipqlbpkecefggavrxcs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) TextDocument.zip is removed from here because it contains a virus. --------------------------------------------------------- ----------vipqlbpkecefggavrxcs-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 8 10:47:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08979; Mon, 8 Mar 2004 10:47:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0MxI-0000A0-EY; Mon, 08 Mar 2004 10:46:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Mwu-00005S-Ja for dhcwg@optimus.ietf.org; Mon, 08 Mar 2004 10:45:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08885 for ; Mon, 8 Mar 2004 10:45:44 -0500 (EST) From: matthew.ford@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Mws-00005X-00 for dhcwg@ietf.org; Mon, 08 Mar 2004 10:45:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Mw2-0007jx-00 for dhcwg@ietf.org; Mon, 08 Mar 2004 10:44:54 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150] helo=i2kc02-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1B0Mvb-0007XO-00 for dhcwg@ietf.org; Mon, 08 Mar 2004 10:44:28 -0500 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by i2kc02-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 8 Mar 2004 15:43:52 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 8 Mar 2004 15:43:52 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Mar 2004 15:43:51 -0000 Message-ID: <0AAF93247C75E3408638B965DEE11A7006022C75@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: Unplanned renumbering scenarios Thread-Index: AcQFJCibEuEabdZGTturijeoF/NHqw== To: X-OriginalArrivalTime: 08 Mar 2004 15:43:52.0077 (UTC) FILETIME=[27F86BD0:01C40524] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [dhcwg] Unplanned renumbering scenarios Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable With regard to draft-chown-dhc-stateless-dhcpv6-renumbering-00, I'm having problems getting to grips with the concept of an 'unplanned' renumbering scenario. As far as I can see the only time this makes sense is if there is a set of config information that cannot be propagated until it is required - why would this ever be the case? Changming described a scenario that seemed to fit this, but as has been pointed out on the list, there are alternative, much better solutions to address this. Other possible scenarios for unplanned renumbering events might be where the config information is outwith the control of the DHCPv6 admin. How likely is that? Are there many network operators that change DNS server addresses on their subscribers without telling them in advance? If it's a case of having multiple paths for redundancy or whatever, then advertise the combined info. Essentially I'm not sure that the concept of an 'unplanned' event is relevant in this context. Mat. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 8 12:45:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15812; Mon, 8 Mar 2004 12:45:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0OoJ-0001aT-7n; Mon, 08 Mar 2004 12:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Ono-0001YC-Bh for dhcwg@optimus.ietf.org; Mon, 08 Mar 2004 12:44:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15779 for ; Mon, 8 Mar 2004 12:44:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Onm-0007Bx-00 for dhcwg@ietf.org; Mon, 08 Mar 2004 12:44:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Olr-0006b7-00 for dhcwg@ietf.org; Mon, 08 Mar 2004 12:42:32 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1B0OjP-0005se-00 for dhcwg@ietf.org; Mon, 08 Mar 2004 12:39:59 -0500 Received: from [66.93.187.232] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id E065B1B2134; Mon, 8 Mar 2004 11:35:41 -0600 (CST) In-Reply-To: <0AAF93247C75E3408638B965DEE11A7006022C75@i2km41-ukdy.domain1.systemhost.net> References: <0AAF93247C75E3408638B965DEE11A7006022C75@i2km41-ukdy.domain1.systemhost.net> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <337C4A80-7122-11D8-8AB6-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: From: Ted Lemon Subject: Re: [dhcwg] Unplanned renumbering scenarios Date: Mon, 8 Mar 2004 11:01:11 -0600 To: matthew.ford@bt.com X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The usual context for an unplanned event is that the power supply in your DNS server melts and you need to quickly switch to another DNS server. I.e., it's an unusual situation. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 8 15:22:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26938; Mon, 8 Mar 2004 15:22:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RGC-0007fx-4k; Mon, 08 Mar 2004 15:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RGA-0007fW-Hk for dhcwg@optimus.ietf.org; Mon, 08 Mar 2004 15:21:58 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26758; Mon, 8 Mar 2004 15:21:55 -0500 (EST) Message-Id: <200403082021.PAA26758@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 08 Mar 2004 15:21:55 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-isnsoption-11.txt,.pdf Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The IPv4 DHCP Options for the Internet Storage Name Service Author(s) : C. Monia, J. Tseng, K. Gibbons Filename : draft-ietf-dhc-isnsoption-11.txt,.pdf Pages : 14 Date : 2004-3-2 This document describes the DHCP option to allow Internet Storage Name Service (iSNS) clients to automatically discover the location of the iSNS server through the use of DHCP for IPv4. iSNS provides discovery and management capabilities for Internet SCSI (iSCSI) and Internet Fibre Channel Protocol (iFCP) storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity as a storage area network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-11.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-isnsoption-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-isnsoption-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-8110822.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-isnsoption-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-isnsoption-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-8110822.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 9 10:37:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01720; Tue, 9 Mar 2004 10:37:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jH9-0003iJ-IY; Tue, 09 Mar 2004 10:36:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0ggm-0000sL-02 for dhcwg@optimus.ietf.org; Tue, 09 Mar 2004 07:50:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24774 for ; Tue, 9 Mar 2004 07:50:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0ggl-0003lv-00 for dhcwg@ietf.org; Tue, 09 Mar 2004 07:50:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0gfp-0003d7-00 for dhcwg@ietf.org; Tue, 09 Mar 2004 07:49:30 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B0gf3-0003M0-00 for dhcwg@ietf.org; Tue, 09 Mar 2004 07:48:41 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i29Cm8iQ025199 for ; Tue, 9 Mar 2004 04:48:09 -0800 (PST) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-10.cisco.com [10.82.240.10]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGQ11181; Tue, 9 Mar 2004 07:48:07 -0500 (EST) Message-Id: <4.3.2.7.2.20040309074654.01f61e50@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 09 Mar 2004 07:48:05 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Archive of video from dhc WG in Seoul Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , An archive of the video from the dhc WG meeting in Seoul is available at: ftp://limestone.uoregon.edu/pub/videolab/video/ietf59/ietf59-ch1-tue-am_040302_0845_3.mpg - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 9 11:26:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06809; Tue, 9 Mar 2004 11:26:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0k3O-0006AC-0k; Tue, 09 Mar 2004 11:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0k2z-00069m-TM for dhcwg@optimus.ietf.org; Tue, 09 Mar 2004 11:25:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06760 for ; Tue, 9 Mar 2004 11:25:35 -0500 (EST) From: erik.nordmark@sun.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0k2y-0005FV-00 for dhcwg@ietf.org; Tue, 09 Mar 2004 11:25:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0k20-00056N-00 for dhcwg@ietf.org; Tue, 09 Mar 2004 11:24:36 -0500 Received: from razor.kraksystem.pl ([217.97.202.40]) by ietf-mx with esmtp (Exim 4.12) id 1B0k12-0004rs-00 for dhcwg@ietf.org; Tue, 09 Mar 2004 11:23:36 -0500 Received: from h3-60.krak ([192.168.3.60] helo=HAHA) by razor.kraksystem.pl with smtp (Exim 3.36 #1) id 1B0k10-0004tZ-00 for dhcwg@ietf.org; Tue, 09 Mar 2004 17:23:34 +0100 Date: Tue, 09 Mar 2004 17:23:32 +0100 To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------rmssrwjtbrqdgkrytvqp" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Subject: [dhcwg] Hey, ya! =)) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , ----------rmssrwjtbrqdgkrytvqp Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_BAGLE.GEN-1 in file AttachedFile.zip The file is deleted. --------------------------------------------------------- ----------rmssrwjtbrqdgkrytvqp Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't bite, weah! password -- 40728 ----------rmssrwjtbrqdgkrytvqp Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) AttachedFile.zip is removed from here because it contains a virus. --------------------------------------------------------- ----------rmssrwjtbrqdgkrytvqp-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 9 12:13:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09216; Tue, 9 Mar 2004 12:13:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0kmr-00028K-8Z; Tue, 09 Mar 2004 12:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0kmb-00027w-0B for dhcwg@optimus.ietf.org; Tue, 09 Mar 2004 12:12:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09207 for ; Tue, 9 Mar 2004 12:12:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0kmZ-0007N7-00 for dhcwg@ietf.org; Tue, 09 Mar 2004 12:12:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0klc-0007CC-00 for dhcwg@ietf.org; Tue, 09 Mar 2004 12:11:45 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1B0kkz-00073P-00 for dhcwg@ietf.org; Tue, 09 Mar 2004 12:11:05 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by pan.gwi.net (8.12.6p3/8.12.6) with ESMTP id i29HAsGn099518; Tue, 9 Mar 2004 12:11:05 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: , Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-3315id-for-v4-02.txt Date: Tue, 9 Mar 2004 12:10:57 -0500 Message-ID: <000001c405f9$806e3bc0$6601a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <200402171531.KAA04599@ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Ted: While I was pushing for the addition of the IA in DHCPv4, I'm not yet certain the technique for doing so is the best way to go. I think it has = the possibility of introducing confusion and perhaps even interoperatability issues. The confusion is as to what exactly is the client identifier. Is it the "full" IA+DUID or just DUID? I assume that the DUID is the part that is supposed to represent the client - not the IA+DUID. If that is the case, what happens when there are multiple servers in a network, some that understand the separation between IA+DUID and those that don't (they = just understand the "client identifier option" and use all the bytes to = identify the client). I'm especially concerned about DDNS updates (using the = DHCID RR draft). There are two ways to resolve this: 1. Place the IA into a separate option instead of as part of the Client Identifier. 2. Place appropriate warnings/cautions/directions as to what a server is supposed to use as the "client identifier". Though, while this resolves = the situation for those servers that are modified to support this work, it doesn't resolve the issue for those servers that don't. Using a separate option has the following advantages: - If a server does not support the IA option, the client can know that = since the server will NOT echo it back in any replies. (Of course, servers = MUST be told to do this.) I'm not sure what the client should do if the server doesn't support the IA option, but it might, for example, switch back to = an interface specific identifier if it needs multiple addresses? - The client identifier is the same regardless of whether a server = supports the new DUID based client identifier. Presently, if there are two = servers in a network, one that has full understanding of this draft (draft-ietf-dhc-3315id-for-v4-02) and one that doesn't, they'll use different client identifiers (at least as I understand it) when doing = DDNS updates (assuming they implement the DHCID RR). - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, February 17, 2004 10:32 AM To: IETF-Announce: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-3315id-for-v4-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 : Node-Specific Client Identifiers for DHCPv4 Author(s) : T. Lemon Filename : draft-ietf-dhc-3315id-for-v4-02.txt Pages : 8 Date : 2004-2-17 =09 This document specifies the format that is to be used for encoding DHCPv4 (RFC2131/RFC2132) client identifiers, so that those identifiers will be interchangeable with identifiers used in the DHCPv6 protocol (RFC3315). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-3315id-for-v4-02.txt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the = message. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-3315id-for-v4-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-3315id-for-v4-02.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 9 12:21:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09627; Tue, 9 Mar 2004 12:21:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0kuc-0002jc-DK; Tue, 09 Mar 2004 12:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0kuI-0002iM-Ln for dhcwg@optimus.ietf.org; Tue, 09 Mar 2004 12:20:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09577 for ; Tue, 9 Mar 2004 12:20:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0kuH-0001B8-00 for dhcwg@ietf.org; Tue, 09 Mar 2004 12:20:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0ktG-0000zK-00 for dhcwg@ietf.org; Tue, 09 Mar 2004 12:19:39 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1B0ksF-0000g7-00 for dhcwg@ietf.org; Tue, 09 Mar 2004 12:18:35 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by pan.gwi.net (8.12.6p3/8.12.6) with ESMTP id i29HIMGn000822; Tue, 9 Mar 2004 12:18:31 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: , , Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-3315id-for-v4-02.txt Date: Tue, 9 Mar 2004 12:18:25 -0500 Message-ID: <000101c405fa$8bf81230$6601a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Oh, I forgot to add that perhaps draft-ietf-dnsext-dhcid-rr-07.txt needs = to be updated. The following table will need to be revised: 0x0000 =3D htype, chaddr from a DHCPv4 client's DHCPREQUEST (RFC 2131) 0x0001 =3D The data portion from a DHCPv4 client's Client Identifier option (RFC 2132) 0x0002 =3D The data portion (i.e., the DUID) from a DHCPv6 client's Client Identifier option (draft-ietf-dhc-dhcpv6-*.txt) To, perhaps: 0x0000 =3D htype, chaddr from a DHCPv4 client's DHCPREQUEST (RFC 2131) 0x0001 =3D The data portion from a DHCPv4 client's Client Identifier option (RFC 2132) if not the DUID format (see draft-ietf-dhc-3315id-for-v4-*.txt) 0x0002 =3D The DUID from a DHCPv6 client's Client Identifier option (RFC 3315 or draft-ietf-dhc-3315id-for-v4-02.txt) This still creates an issue for servers that don't fully understand draft-ietf-dhc-3315id-for-v4-02.txt as they'll use 0x0001 instead of = 0x0002. I wonder whether a way out of this might be to use the DHCPv4 encoding = for both DHCPv4 and DHCPv6 DUIDs: 0x0001 <255> - Bernie -----Original Message----- From: Bernie Volz [mailto:volz@metrocast.net]=20 Sent: Tuesday, March 09, 2004 12:11 PM To: 'dhcwg@ietf.org'; 'Ted.Lemon@nominum.com' Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-3315id-for-v4-02.txt Ted: While I was pushing for the addition of the IA in DHCPv4, I'm not yet certain the technique for doing so is the best way to go. I think it has = the possibility of introducing confusion and perhaps even interoperatability issues. The confusion is as to what exactly is the client identifier. Is it the "full" IA+DUID or just DUID? I assume that the DUID is the part that is supposed to represent the client - not the IA+DUID. If that is the case, what happens when there are multiple servers in a network, some that understand the separation between IA+DUID and those that don't (they = just understand the "client identifier option" and use all the bytes to = identify the client). I'm especially concerned about DDNS updates (using the = DHCID RR draft). There are two ways to resolve this: 1. Place the IA into a separate option instead of as part of the Client Identifier. 2. Place appropriate warnings/cautions/directions as to what a server is supposed to use as the "client identifier". Though, while this resolves = the situation for those servers that are modified to support this work, it doesn't resolve the issue for those servers that don't. Using a separate option has the following advantages: - If a server does not support the IA option, the client can know that = since the server will NOT echo it back in any replies. (Of course, servers = MUST be told to do this.) I'm not sure what the client should do if the server doesn't support the IA option, but it might, for example, switch back to = an interface specific identifier if it needs multiple addresses? - The client identifier is the same regardless of whether a server = supports the new DUID based client identifier. Presently, if there are two = servers in a network, one that has full understanding of this draft (draft-ietf-dhc-3315id-for-v4-02) and one that doesn't, they'll use different client identifiers (at least as I understand it) when doing = DDNS updates (assuming they implement the DHCID RR). - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, February 17, 2004 10:32 AM To: IETF-Announce: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-3315id-for-v4-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 : Node-Specific Client Identifiers for DHCPv4 Author(s) : T. Lemon Filename : draft-ietf-dhc-3315id-for-v4-02.txt Pages : 8 Date : 2004-2-17 =09 This document specifies the format that is to be used for encoding DHCPv4 (RFC2131/RFC2132) client identifiers, so that those identifiers will be interchangeable with identifiers used in the DHCPv6 protocol (RFC3315). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-3315id-for-v4-02.txt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the = message. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-3315id-for-v4-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-3315id-for-v4-02.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 9 13:32:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13971; Tue, 9 Mar 2004 13:32:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0m1J-0007kC-Bu; Tue, 09 Mar 2004 13:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0m0O-0007ii-HA for dhcwg@optimus.ietf.org; Tue, 09 Mar 2004 13:31:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13911 for ; Tue, 9 Mar 2004 13:31:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0m0M-00008Q-00 for dhcwg@ietf.org; Tue, 09 Mar 2004 13:31:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0lzN-0007kX-00 for dhcwg@ietf.org; Tue, 09 Mar 2004 13:30:02 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1B0lys-0007ZZ-00 for dhcwg@ietf.org; Tue, 09 Mar 2004 13:29:30 -0500 Received: from [66.93.187.232] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id EA1E21B21B2; Tue, 9 Mar 2004 12:25:02 -0600 (CST) In-Reply-To: <000001c405f9$806e3bc0$6601a8c0@BVolz> References: <000001c405f9$806e3bc0$6601a8c0@BVolz> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: From: Ted Lemon Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-3315id-for-v4-02.txt Date: Tue, 9 Mar 2004 12:29:20 -0600 To: "Bernie Volz" X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mar 9, 2004, at 11:10 AM, Bernie Volz wrote: > 2. Place appropriate warnings/cautions/directions as to what a server > is > supposed to use as the "client identifier". Though, while this > resolves the > situation for those servers that are modified to support this work, it > doesn't resolve the issue for those servers that don't. Just as a reminder, there is no standard saying what servers currently are supposed to do with client identifier- there are just a bunch of soon-to-expire drafts. However, your point isn't about standards, but about what's deployed. My point in bringing this up is not to say "it's not a problem", but rather to try to suggest that the right solution _is_ in fact to say "you have to run servers that conform to the standard if you want it to work," not to make the protocol more complex to account for non-conforming implementations. The intention when I was asked to write this draft was that it would be a normative reference for the DNS update drafts, so no DHCP server that conforms to the DNS update drafts will fail to implement this standard. I'm not sure where the warning you're proposing should go - in this draft or in one of the DNS update drafts. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 9 14:51:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17932; Tue, 9 Mar 2004 14:51:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0nFl-00057O-NK; Tue, 09 Mar 2004 14:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0kgi-0001bq-AP for dhcwg@optimus.ietf.org; Tue, 09 Mar 2004 12:06:40 -0500 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08988 for ; Tue, 9 Mar 2004 12:06:37 -0500 (EST) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1B0kgD-0001aY-Up; Tue, 09 Mar 2004 12:06:09 -0500 X-test-idtracker: no To: IETF-Announce :; From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Tue, 09 Mar 2004 12:06:09 -0500 Subject: [dhcwg] Last Call: 'RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option' to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Dynamic Host Configuration WG to consider the following document: - 'RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-03-23. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentopt-radius-04.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 9 15:21:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20973; Tue, 9 Mar 2004 15:21:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0nin-0000ee-Cq; Tue, 09 Mar 2004 15:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0nif-0000cv-Mm for dhcwg@optimus.ietf.org; Tue, 09 Mar 2004 15:20:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20848 for ; Tue, 9 Mar 2004 15:20:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0nie-0004HV-00 for dhcwg@ietf.org; Tue, 09 Mar 2004 15:20:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0nhl-00047H-00 for dhcwg@ietf.org; Tue, 09 Mar 2004 15:19:58 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1B0ngp-0003wh-00 for dhcwg@ietf.org; Tue, 09 Mar 2004 15:18:59 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by pan.gwi.net (8.12.6p3/8.12.6) with ESMTP id i29KIoGn030038; Tue, 9 Mar 2004 15:18:59 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Ted Lemon'" Cc: Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-3315id-for-v4-02.txt Date: Tue, 9 Mar 2004 15:18:55 -0500 Message-ID: <001b01c40613$c2726a40$6601a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Perhaps something needs to be said in both drafts? I have no major issue with saying that you need to run servers that conform to the standard for this work, but I do believe the draft should say something about the implications of implementing the draft so that vendors producing clients and servers remember to warn their customers when deploying updated software. And, there's always the issue of coordinating client and server updates - if a new client runs on an old server, the client identifier that needs to be configured for a reservation will differ significantly from that used by an updated server. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ted Lemon Sent: Tuesday, March 09, 2004 1:29 PM To: Bernie Volz Cc: dhcwg@ietf.org Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-3315id-for-v4-02.txt On Mar 9, 2004, at 11:10 AM, Bernie Volz wrote: > 2. Place appropriate warnings/cautions/directions as to what a server > is > supposed to use as the "client identifier". Though, while this > resolves the > situation for those servers that are modified to support this work, it > doesn't resolve the issue for those servers that don't. Just as a reminder, there is no standard saying what servers currently are supposed to do with client identifier- there are just a bunch of soon-to-expire drafts. However, your point isn't about standards, but about what's deployed. My point in bringing this up is not to say "it's not a problem", but rather to try to suggest that the right solution _is_ in fact to say "you have to run servers that conform to the standard if you want it to work," not to make the protocol more complex to account for non-conforming implementations. The intention when I was asked to write this draft was that it would be a normative reference for the DNS update drafts, so no DHCP server that conforms to the DNS update drafts will fail to implement this standard. I'm not sure where the warning you're proposing should go - in this draft or in one of the DNS update drafts. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 9 15:55:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22941; Tue, 9 Mar 2004 15:55:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0oFi-0002th-Ov; Tue, 09 Mar 2004 15:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0oF9-0002sk-PC for dhcwg@optimus.ietf.org; Tue, 09 Mar 2004 15:54:27 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22758; Tue, 9 Mar 2004 15:54:25 -0500 (EST) Message-Id: <200403092054.PAA22758@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 09 Mar 2004 15:54:24 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dual-stack-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : IPv4 and IPv6 Dual-Stack Issues for DHCPv6 Author(s) : T. Chown Filename : draft-ietf-dhc-dual-stack-00.txt Pages : 10 Date : 2004-3-9 A node may have support for communications using IPv4 and/or IPv6 protocols. Such a node may wish to obtain IPv4 and/or IPv6 configuration settings via the Dynamic Host Configuration Protocol (DHCP). The original version of DHCP [1] designed for IPv4 has now been complemented by a new DHCPv6 [4] for IPv6. This document describes issues identified with dual IP version DHCP interactions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dual-stack-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dual-stack-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dual-stack-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-9161456.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dual-stack-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dual-stack-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-9161456.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 9 16:40:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22940; Tue, 9 Mar 2004 15:55:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0oFj-0002tp-8j; Tue, 09 Mar 2004 15:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0oFF-0002sp-Ly for dhcwg@optimus.ietf.org; Tue, 09 Mar 2004 15:54:33 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22774; Tue, 9 Mar 2004 15:54:31 -0500 (EST) Message-Id: <200403092054.PAA22774@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 09 Mar 2004 15:54:30 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-lifetime-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Lifetime Option for DHCPv6 Author(s) : S. Venaas, T. Chown Filename : draft-ietf-dhc-lifetime-00.txt Pages : 5 Date : 2004-3-9 This document describes an option for specifying a lifetime for other DHCPv6 configuration options. It's mainly intended for the stateless DHCPv6, but also useful when there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCP server to update its configuration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-lifetime-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-lifetime-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-lifetime-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-9161509.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-lifetime-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-lifetime-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-9161509.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 9 16:40:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22939; Tue, 9 Mar 2004 15:55:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0oFj-0002tx-OJ; Tue, 09 Mar 2004 15:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0oFL-0002sx-Vd for dhcwg@optimus.ietf.org; Tue, 09 Mar 2004 15:54:39 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22790; Tue, 9 Mar 2004 15:54:37 -0500 (EST) Message-Id: <200403092054.PAA22790@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 09 Mar 2004 15:54:37 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-stateless-dhcpv6-renumbering-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Renumbering Requirements for Stateless DHCPv6 Author(s) : T. Chown Filename : draft-ietf-dhc-stateless-dhcpv6-renumbering-00.txt Pages : 8 Date : 2004-3-9 IPv6 hosts using Stateless Address Autoconfiguration are able to automatically configure their IPv6 address and default router settings. However, further settings are not available. If such hosts wish to automatically configure their DNS, NTP or other specific settings the stateless variant of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) could be used. This combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks. However, hosts using such a combination currently have no means by which to be informed of changes in stateless DHCPv6 option settings, e.g. the addition of a new NTP server address, changes in DNS search paths, or full site renumbering. This document is presented as a problem statement from which a solution should be proposed in a subsequent document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-stateless-dhcpv6-renumbering-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-stateless-dhcpv6-renumbering-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-stateless-dhcpv6-renumbering-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-9161518.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-stateless-dhcpv6-renumbering-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-stateless-dhcpv6-renumbering-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-9161518.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 9 22:01:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14139; Tue, 9 Mar 2004 22:01:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0txu-00065O-NX; Tue, 09 Mar 2004 22:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0tx3-00064B-SN for dhcwg@optimus.ietf.org; Tue, 09 Mar 2004 22:00:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14111 for ; Tue, 9 Mar 2004 22:00:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0tx0-0005sK-00 for dhcwg@ietf.org; Tue, 09 Mar 2004 22:00:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0tw3-0005ij-00 for dhcwg@ietf.org; Tue, 09 Mar 2004 21:59:08 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1B0tvA-0005YC-00 for dhcwg@ietf.org; Tue, 09 Mar 2004 21:58:12 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i2A2w7q5016168 for ; Wed, 10 Mar 2004 11:58:07 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i2A2w6u2002107 for ; Wed, 10 Mar 2004 11:58:06 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i2A2w5V5011564 for ; Wed, 10 Mar 2004 11:58:06 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i2A2w5vQ011559 for ; Wed, 10 Mar 2004 11:58:05 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i2A2w5Rt012382 for ; Wed, 10 Mar 2004 11:58:05 +0900 (JST) Received: from ime.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id LAA25380 for ; Wed, 10 Mar 2004 11:58:05 +0900 (JST) Received: from lab.ntt.co.jp by ime.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id LAA15152 for ; Wed, 10 Mar 2004 11:58:04 +0900 (JST) Message-ID: <404E8521.9030909@lab.ntt.co.jp> Date: Wed, 10 Mar 2004 12:01:53 +0900 From: Mayumi Yanagiya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: dhcwg@ietf.org Subject: Re: [dhcwg] Last Call: 'RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option' to Proposed Standard References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I have a question that is related to this draft. In this daft, it is assumed that authenticator and dhcp relay are located in same network element such as access point. When we use dhcp relay in access controlled network, is it indispensable requirement? Or, it is an assumption when we use this sub-option? Mayumi, The IESG wrote: > The IESG has received a request from the Dynamic Host Configuration WG to > consider the following document: > > - 'RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2004-03-23. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentopt-radius-04.txt > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > -- *++++++++++++++++++++++++++++++++++++++++++ NTT Network Service Systems Laboratories Mayumi Yanagiya tel: +81 422 59 6783 fax: +81 422 37 7688 E-mail: yanagiya.mayumi@lab.ntt.co.jp +++++++++++++++++++++++++++++++++++++++++++* _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Mar 12 10:52:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29194; Fri, 12 Mar 2004 10:52:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ox8-0006Y2-M2; Fri, 12 Mar 2004 10:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1owj-0006XP-TW for dhcwg@optimus.ietf.org; Fri, 12 Mar 2004 10:51:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29127 for ; Fri, 12 Mar 2004 10:51:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1owh-00002x-00 for dhcwg@ietf.org; Fri, 12 Mar 2004 10:51:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1ovp-0007jt-00 for dhcwg@ietf.org; Fri, 12 Mar 2004 10:50:41 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B1ovH-0007ba-00 for dhcwg@ietf.org; Fri, 12 Mar 2004 10:50:07 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 12 Mar 2004 07:52:20 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2CFnXaD027381; Fri, 12 Mar 2004 07:49:34 -0800 (PST) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-338.cisco.com [10.82.225.82]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGS81882; Fri, 12 Mar 2004 10:49:32 -0500 (EST) Message-Id: <4.3.2.7.2.20040312074820.01f47388@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 12 Mar 2004 07:50:41 -0500 To: Mayumi Yanagiya From: Ralph Droms Subject: Re: [dhcwg] Last Call: 'RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option' to Proposed Standard Cc: dhcwg@ietf.org In-Reply-To: <404E8521.9030909@lab.ntt.co.jp> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Yes, it is required that the authenticator and the relay agent are located in the same network element for the protocol specified in this draft. - Ralph Droms At 12:01 PM 3/10/2004 +0900, Mayumi Yanagiya wrote: >Hi, > >I have a question that is related to this draft. > >In this daft, it is assumed that authenticator and >dhcp relay are located in same network element such >as access point. > >When we use dhcp relay in access controlled network, >is it indispensable requirement? >Or, it is an assumption when we use this sub-option? > >Mayumi, > >The IESG wrote: > > > The IESG has received a request from the Dynamic Host Configuration WG to > > consider the following document: > > > > - 'RADIUS Attributes Sub-option for the DHCP Relay Agent Information > Option' > > as a Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send any comments to the > > iesg@ietf.org or ietf@ietf.org mailing lists by 2004-03-23. > > > > The file can be obtained via > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentopt-radius-04.txt > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > >-- > >*++++++++++++++++++++++++++++++++++++++++++ >NTT Network Service Systems Laboratories >Mayumi Yanagiya >tel: +81 422 59 6783 fax: +81 422 37 7688 >E-mail: yanagiya.mayumi@lab.ntt.co.jp >+++++++++++++++++++++++++++++++++++++++++++* > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 15 04:25:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16660; Mon, 15 Mar 2004 04:25:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2oKt-0000uC-PZ; Mon, 15 Mar 2004 04:24:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2nyk-0007f7-Mt for dhcwg@optimus.ietf.org; Mon, 15 Mar 2004 04:01:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15428 for ; Mon, 15 Mar 2004 04:01:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2nyi-0002ih-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 04:01:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2nxo-0002by-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 04:00:48 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1B2nxS-0002Uz-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 04:00:26 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i2F90JY5025184; Mon, 15 Mar 2004 18:00:20 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i2F90Jcu002614; Mon, 15 Mar 2004 18:00:19 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i2F90I95026938; Mon, 15 Mar 2004 18:00:18 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i2F90IAQ026931; Mon, 15 Mar 2004 18:00:18 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i2F90HJP024047; Mon, 15 Mar 2004 18:00:17 +0900 (JST) Received: from ime.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id SAA25739; Mon, 15 Mar 2004 18:00:17 +0900 (JST) Received: from lab.ntt.co.jp by ime.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id SAA28254; Mon, 15 Mar 2004 18:00:16 +0900 (JST) Message-ID: <40557188.8050803@lab.ntt.co.jp> Date: Mon, 15 Mar 2004 18:04:08 +0900 From: Mayumi Yanagiya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: Ralph Droms CC: dhcwg@ietf.org Subject: Re: [dhcwg] Last Call: 'RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option' to Proposed Standard References: <4.3.2.7.2.20040312074820.01f47388@flask.cisco.com> In-Reply-To: <4.3.2.7.2.20040312074820.01f47388@flask.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Ralph, Thank you for your answer. Mayumi > Yes, it is required that the authenticator and the relay agent are located > in the same network element for the protocol specified in this draft. > > > - Ralph Droms > > At 12:01 PM 3/10/2004 +0900, Mayumi Yanagiya wrote: > >> Hi, >> >> I have a question that is related to this draft. >> >> In this daft, it is assumed that authenticator and >> dhcp relay are located in same network element such >> as access point. >> >> When we use dhcp relay in access controlled network, >> is it indispensable requirement? >> Or, it is an assumption when we use this sub-option? >> >> Mayumi, >> >> The IESG wrote: >> >> > The IESG has received a request from the Dynamic Host Configuration >> WG to >> > consider the following document: >> > >> > - 'RADIUS Attributes Sub-option for the DHCP Relay Agent Information >> Option' >> > as a Proposed Standard >> > >> > The IESG plans to make a decision in the next few weeks, and solicits >> > final comments on this action. Please send any comments to the >> > iesg@ietf.org or ietf@ietf.org mailing lists by 2004-03-23. >> > >> > The file can be obtained via >> > >> http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentopt-radius-04.txt >> > >> > >> > _______________________________________________ >> > dhcwg mailing list >> > dhcwg@ietf.org >> > https://www1.ietf.org/mailman/listinfo/dhcwg >> > >> >> -- >> >> *++++++++++++++++++++++++++++++++++++++++++ >> NTT Network Service Systems Laboratories >> Mayumi Yanagiya >> tel: +81 422 59 6783 fax: +81 422 37 7688 >> E-mail: yanagiya.mayumi@lab.ntt.co.jp >> +++++++++++++++++++++++++++++++++++++++++++* >> >> >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/dhcwg > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > -- *++++++++++++++++++++++++++++++++++++++++++ NTT Network Service Systems Laboratories Mayumi Yanagiya tel: +81 422 59 6783 fax: +81 422 37 7688 E-mail: yanagiya.mayumi@lab.ntt.co.jp +++++++++++++++++++++++++++++++++++++++++++* _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 15 08:19:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25678; Mon, 15 Mar 2004 08:19:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2rzh-0001oC-1L; Mon, 15 Mar 2004 08:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1dER-00043m-Qb for dhcwg@optimus.ietf.org; Thu, 11 Mar 2004 22:21:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14257 for ; Thu, 11 Mar 2004 22:21:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1dEO-0001LL-00 for dhcwg@ietf.org; Thu, 11 Mar 2004 22:21:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1dDR-0001Ew-00 for dhcwg@ietf.org; Thu, 11 Mar 2004 22:20:05 -0500 Received: from [203.199.83.38] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 1B1dCx-00018Z-00 for dhcwg@ietf.org; Thu, 11 Mar 2004 22:19:35 -0500 Received: (qmail 30138 invoked by uid 510); 12 Mar 2004 03:19:31 -0000 Date: 12 Mar 2004 03:19:31 -0000 Message-ID: <20040312031931.30137.qmail@webmail28.rediffmail.com> Received: from unknown (203.200.24.204) by rediffmail.com via HTTP; 12 mar 2004 03:19:31 -0000 MIME-Version: 1.0 From: "narassimha reddy reddy" Reply-To: "narassimha reddy reddy" To: dhcwg@ietf.org Content-type: multipart/alternative; boundary="Next_1079061571---0-203.199.83.38-30135" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.3 required=5.0 tests=HTML_30_40,HTML_IMAGE_ONLY_06, HTML_MESSAGE,MSGID_FROM_MTA_HEADER,REPLY_TO_ULINE_NUMS autolearn=no version=2.60 Subject: [dhcwg] dhcv6 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multipart mime message --Next_1079061571---0-203.199.83.38-30135 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AHi,
=0A
=0AHere i am sending one big problem pls try find solut= ion and send to reply,
=0A
=0Aif iwant to test dhcpv6 code , what par= ameters i have to give , what it gives output
=0A
=0Aif knows send b= ack your results,
=0A
=0A
=0A
=0Awith regards,
=0ANarasimha = Reddy.K=0A

=0A

=0A=0A --Next_1079061571---0-203.199.83.38-30135 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi,=0A=0AHere i am sending one big problem pls try find solution and send t= o reply,=0A=0Aif iwant to test dhcpv6 code , what parameters i have to give= , what it gives output =0A=0Aif knows send back your results,=0A=0A=0A=0Aw= ith regards,=0ANarasimha Reddy.K --Next_1079061571---0-203.199.83.38-30135-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 15 08:42:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27072; Mon, 15 Mar 2004 08:42:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2sLx-0003uX-2w; Mon, 15 Mar 2004 08:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2sL3-0003t0-84 for dhcwg@optimus.ietf.org; Mon, 15 Mar 2004 08:41:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27058 for ; Mon, 15 Mar 2004 08:41:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2sL1-0000YP-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 08:41:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2sK0-0000Kp-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 08:40:01 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1B2sIb-0007fS-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 08:38:33 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 15 Mar 2004 05:44:07 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2FDc0Uk009820; Mon, 15 Mar 2004 08:38:01 -0500 (EST) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-195.cisco.com [10.82.224.195]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGT88768; Mon, 15 Mar 2004 08:37:59 -0500 (EST) Message-Id: <4.3.2.7.2.20040315082841.01f54a98@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Mar 2004 08:37:56 -0500 To: "narassimha reddy reddy" From: Ralph Droms Subject: Re: [dhcwg] dhcv6 Cc: dhcwg@ietf.org In-Reply-To: <20040312031931.30137.qmail@webmail28.rediffmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , You need a DHCP server that implements the DHCPv6 protocol as specified in RFC 3315... - Ralph Droms At 03:19 AM 3/12/2004 +0000, narassimha reddy reddy wrote: >Hi, > >Here i am sending one big problem pls try find solution and send to reply, > >if iwant to test dhcpv6 code , what parameters i have to give , what it >gives output > >if knows send back your results, > > > >with regards, >Narasimha Reddy.K > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 15 09:44:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00023; Mon, 15 Mar 2004 09:44:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2tJx-0000u1-Qn; Mon, 15 Mar 2004 09:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2tJ2-0000eK-Aa for dhcwg@optimus.ietf.org; Mon, 15 Mar 2004 09:43:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29977 for ; Mon, 15 Mar 2004 09:43:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2tJ0-0001IS-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 09:43:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2tI1-0001B2-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 09:42:02 -0500 Received: from ovaron.uni-muenster.de ([128.176.191.5] helo=ovaron.join.uni-muenster.de) by ietf-mx with esmtp (Exim 4.12) id 1B2tHP-00013z-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 09:41:23 -0500 Received: from kummerog.uni-muenster.de (kummerog.ipv6.uni-muenster.de [IPv6:2001:638:500:200:210:5aff:fe4c:cfd1]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.12.11/8.12.9) with ESMTP id i2FEfBU5000518 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 15 Mar 2004 15:41:16 +0100 (CET) Subject: Re: [dhcwg] dhcv6 From: Christian Strauf To: narassimha reddy reddy Cc: dhcwg@ietf.org In-Reply-To: <20040312031931.30137.qmail@webmail28.rediffmail.com> References: <20040312031931.30137.qmail@webmail28.rediffmail.com> Content-Type: text/plain; charset=ISO-8859-15 Organization: JOIN-Team, WWU-Muenster Message-Id: <1079361671.5499.8.camel@kummerog.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 15 Mar 2004 15:41:11 +0100 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ovaron.join.uni-muenster.de id i2FEfBU5000518 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > if iwant to test dhcpv6 code , what parameters i have to give , what it= gives output=20 >=20 > if knows send back your results, There're two free implementations of DHCPv6 that you might find interesting: http://dhcpv6.sourceforge.net/ and http://klub.com.pl/dhcpv6/?page=3D16 Cheers, Christian --=20 JOIN - IP Version 6 in the WiN Christian Strauf A DFN project Westf=E4lische Wilhelms-Universit=E4t M=FC= nster http://www.join.uni-muenster.de Zentrum f=FCr Informationsverarbeitung Team: join@uni-muenster.de R=F6ntgenstrasse 9-13 Priv: strauf@uni-muenster.de D-48149 M=FCnster / Germany GPG-/PGP-Key-ID: 1DFAAA9A Fon: +49 251 83 31639, Fax: +49 251 83 31= 653 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 15 10:56:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05165; Mon, 15 Mar 2004 10:56:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2uRg-0007dJ-IQ; Mon, 15 Mar 2004 10:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2uQg-0007TS-Nz for dhcwg@optimus.ietf.org; Mon, 15 Mar 2004 10:55:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04987 for ; Mon, 15 Mar 2004 10:54:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2uQe-0002pX-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 10:55:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2uPj-0002hm-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 10:54:03 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1B2uOj-0002T5-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 10:53:01 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 15 Mar 2004 07:58:36 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2FFqSUk015966 for ; Mon, 15 Mar 2004 10:52:29 -0500 (EST) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-434.cisco.com [10.82.225.178]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGT99143; Mon, 15 Mar 2004 10:52:28 -0500 (EST) Message-Id: <4.3.2.7.2.20040315104633.01f70fc0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Mar 2004 10:52:25 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Drafts ready for WG last call Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Several drafts were considered for dhc WG last call at the WG meeting in Seoul. I'm writing to confirm consensus for WG last call on these drafts. Please respond (affirm, comment, disagree selectively) to the dhcwg mailing list about initiating a WG last call on the following drafts: DHCP Option for Proxy Server Configuration Vendor-Identifying Vendor Options for DHCPv4 Node-Specific Client Identifiers for DHCPv4 Rapid Commit Option for DHCPv4 Reclassifying DHCPv4 Options - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 15 10:59:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05509; Mon, 15 Mar 2004 10:59:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2uUX-00085E-Oh; Mon, 15 Mar 2004 10:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2uUU-00084Q-Gm for dhcwg@optimus.ietf.org; Mon, 15 Mar 2004 10:58:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05412 for ; Mon, 15 Mar 2004 10:58:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2uUS-0003P0-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 10:58:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2uTQ-0003EU-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 10:57:52 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B2uSQ-0002zj-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 10:56:50 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 15 Mar 2004 07:59:38 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2FFuHaD027054 for ; Mon, 15 Mar 2004 07:56:18 -0800 (PST) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-434.cisco.com [10.82.225.178]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGT99514; Mon, 15 Mar 2004 10:56:15 -0500 (EST) Message-Id: <4.3.2.7.2.20040315105339.027882f0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Mar 2004 10:56:13 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Drafts to accept as dhc WG work items Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Several drafts were considered for acceptance as dhc WG work items at the WG meeting in Seoul. I'm writing to confirm consensus on these actions. Please respond with comment about accepting the following drafts as dhc WG work items: Vendor-Specific Suboption for the DHCP RAIO Renumbering Requirements for Stateless DHCPv6 (pending dhc WG charter update) Lifetime Option for DHCPv6 (pending dhc WG charter update) IPv4 and IPv6 Dual-Stack Issues for DHCPv6 (pending dhc WG charter update) - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 15 11:28:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08219; Mon, 15 Mar 2004 11:28:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2uwb-0002FE-OX; Mon, 15 Mar 2004 11:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2uvh-0002D0-RF for dhcwg@optimus.ietf.org; Mon, 15 Mar 2004 11:27:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08071 for ; Mon, 15 Mar 2004 11:27:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2uvg-0000Xg-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 11:27:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2uu3-00005F-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 11:25:24 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1B2urz-0007FZ-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 11:23:15 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 15 Mar 2004 08:22:15 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2FGMfU7022442 for ; Mon, 15 Mar 2004 11:22:41 -0500 (EST) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-434.cisco.com [10.82.225.178]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGU02591; Mon, 15 Mar 2004 11:22:40 -0500 (EST) Message-Id: <4.3.2.7.2.20040315111808.01f5b8b0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Mar 2004 11:22:37 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Charter update Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , It's time to update the dhc WG charter. The major changes to consider include: * Add "renumbering for DHCPv6-lite" as a charter item * Add "IPv4-IPv6 dual-stack issues for DHCP" as a charter item * Delete the list of drafts currently under consideration * Various editorial updates * Update WG milestones Please respond to the WG mailing list with comments, including other updates to the charter we should consider. I will initiate separate e-mail threads, including draft text, for each of the bullet items in the list above. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 15 11:52:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09636; Mon, 15 Mar 2004 11:52:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2vJp-0004py-3D; Mon, 15 Mar 2004 11:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2vJ0-0004nf-Qo for dhcwg@optimus.ietf.org; Mon, 15 Mar 2004 11:51:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09584 for ; Mon, 15 Mar 2004 11:51:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2vIz-000455-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 11:51:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2vI9-0003xT-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 11:50:17 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B2vHB-0003gJ-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 11:49:17 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 15 Mar 2004 08:52:06 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2FGmjaD021373 for ; Mon, 15 Mar 2004 08:48:46 -0800 (PST) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-434.cisco.com [10.82.225.178]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGU05369; Mon, 15 Mar 2004 11:48:44 -0500 (EST) Message-Id: <4.3.2.7.2.20040315114735.028073f0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Mar 2004 11:48:42 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Here is proposed text for a dhc WG charter item to address renumbering stateless DHCPv6: The DHCPv6 specification in RFC3315 includes a mechanism through which clients can obtain other configuration information without obtaining an address or addresses. This mechanisms is sometimes called "stateless DHCPv6". RFC3315 includes no provision for notifying DHCPv6 clients using stateless DHCPv6 of changes in the configuration information supplied to the client. The dhc WG will assess the requirements for informing DHCPv6 clients of changes in configuration information, review alternative solutions and select a solution, and develop, review and publish a specification for the chosen solution. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 15 12:06:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10320; Mon, 15 Mar 2004 12:06:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2vXP-0006uB-0C; Mon, 15 Mar 2004 12:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2vWS-0006sM-IK for dhcwg@optimus.ietf.org; Mon, 15 Mar 2004 12:05:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10224 for ; Mon, 15 Mar 2004 12:05:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2vWQ-0005pp-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 12:05:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2vVf-0005m6-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 12:04:16 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B2vVC-0005dE-01 for dhcwg@ietf.org; Mon, 15 Mar 2004 12:03:47 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 15 Mar 2004 09:07:05 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2FH3iaD009279 for ; Mon, 15 Mar 2004 09:03:44 -0800 (PST) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-434.cisco.com [10.82.225.178]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGU06894; Mon, 15 Mar 2004 12:03:42 -0500 (EST) Message-Id: <4.3.2.7.2.20040315120224.027b6e38@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Mar 2004 12:03:38 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Dual-stack hosts using DHCP as dhc WG charter item Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Here is proposed text for a dhc WG charter item to address dual-stack hosts using DHCP: Hosts that include implementations of both IPv4 and IPv6 ("dual-stack hosts") may use DHCP to obtain configuration settings (including assigned addresses) for both IPv4 and IPv6. The DHCPv4 and DHCPv6 specifications (RFC2131, RFC2132, RFC3315 and subsequent RFCs) do not explicitly explain how a dual-stack host uses DHCP to obtain configuration settings for both IP stacks. The dhc WG will assess the requirements for a dual-stack host to use DHCP to obtain configuration settings for both IPv4 and IPv6, review alternative solutions and select a solution, and develop, review and publish a document that defines the chosen solution. Please respond with comments to the dhcwg mailing list. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 15 12:12:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10637; Mon, 15 Mar 2004 12:12:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2vdC-0007kk-5v; Mon, 15 Mar 2004 12:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2vdA-0007kZ-N7 for dhcwg@optimus.ietf.org; Mon, 15 Mar 2004 12:12:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10620 for ; Mon, 15 Mar 2004 12:11:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2vd9-0006Dj-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 12:11:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2vcI-0006B5-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 12:11:06 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B2vbR-00065W-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 12:10:13 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 15 Mar 2004 09:14:11 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i2FH9fWK024700 for ; Mon, 15 Mar 2004 09:09:41 -0800 (PST) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-434.cisco.com [10.82.225.178]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGU07463; Mon, 15 Mar 2004 12:09:40 -0500 (EST) Message-Id: <4.3.2.7.2.20040315120854.027a7ef0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Mar 2004 12:09:35 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Delete the list of drafts currently under consideration from dhc WG charter Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Is there any objection to simply deleting the list of drafts currently under consideration from the dhc WG charter? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 15 12:55:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12990; Mon, 15 Mar 2004 12:55:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wIp-0002LD-CX; Mon, 15 Mar 2004 12:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wIi-0002KE-6l for dhcwg@optimus.ietf.org; Mon, 15 Mar 2004 12:54:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12956 for ; Mon, 15 Mar 2004 12:54:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2wIg-000170-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 12:54:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2wHj-000143-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 12:53:55 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1B2wGn-00010H-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 12:52:57 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i2FHpj9u010747; Mon, 15 Mar 2004 09:51:55 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Mar 2004 09:51:45 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C77B@MONTEREY.netscreen.com> From: Changming Liu To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item Date: Mon, 15 Mar 2004 09:51:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Ralph, Will this "changes in the configuration" include "planned" and "unplanned" changes? What are their definitions in your mind? We had such discussion in the mailing list and it does not appear to me it has been cleanly understood by all the folks. Thanks. Changming > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Monday, March 15, 2004 8:49 AM > To: dhcwg@ietf.org > Subject: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item > > > Here is proposed text for a dhc WG charter item to address > renumbering > stateless DHCPv6: > > The DHCPv6 specification in RFC3315 includes a mechanism through which > clients can obtain other configuration information without obtaining > an address or addresses. This mechanisms is sometimes called > "stateless DHCPv6". RFC3315 includes no provision for notifying > DHCPv6 clients using stateless DHCPv6 of changes in the configuration > information supplied to the client. The dhc WG will assess the > requirements for informing DHCPv6 clients of changes in configuration > information, review alternative solutions and select a solution, and > develop, review and publish a specification for the chosen solution. > > - Ralph > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 15 12:58:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13217; Mon, 15 Mar 2004 12:58:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wLh-0002Xe-Hi; Mon, 15 Mar 2004 12:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wLc-0002XH-Qf for dhcwg@optimus.ietf.org; Mon, 15 Mar 2004 12:57:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13209 for ; Mon, 15 Mar 2004 12:57:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2wLb-0001In-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 12:57:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2wKd-0001FG-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 12:56:55 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1B2wJg-00019c-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 12:55:56 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i2FHt59u011032; Mon, 15 Mar 2004 09:55:15 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Mar 2004 09:55:05 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C77C@MONTEREY.netscreen.com> From: Changming Liu To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] Drafts to accept as dhc WG work items Date: Mon, 15 Mar 2004 09:55:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Ralph, As I pointed out in the mailing list, the last item "IPv4 and IPv6 Dual-Stack Issues for DHCPv6" is a local administrative issue. I have not heard any objection or more dicussions on this subject. If no more interest, we may just drop it. Thanks. Changming > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Monday, March 15, 2004 7:56 AM > To: dhcwg@ietf.org > Subject: [dhcwg] Drafts to accept as dhc WG work items > > > Several drafts were considered for acceptance as dhc WG work > items at the WG > meeting in Seoul. I'm writing to confirm consensus on these actions. > Please respond with comment about accepting the following > drafts as dhc WG > work items: > > Vendor-Specific Suboption for the DHCP RAIO > > > Renumbering Requirements for Stateless DHCPv6 > > (pending dhc WG charter update) > > Lifetime Option for DHCPv6 > > (pending dhc WG charter update) > > IPv4 and IPv6 Dual-Stack Issues for DHCPv6 > > (pending dhc WG charter update) > > > - Ralph > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 15 13:05:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13493; Mon, 15 Mar 2004 13:05:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wSV-0005VA-4X; Mon, 15 Mar 2004 13:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wRV-0005Tn-37 for dhcwg@optimus.ietf.org; Mon, 15 Mar 2004 13:04:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13447 for ; Mon, 15 Mar 2004 13:03:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2wRT-0001Z7-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 13:03:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2wQR-0001XH-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 13:02:56 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1B2wPY-0001VY-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 13:02:00 -0500 Received: from [66.93.187.232] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id F335E1B21B2; Mon, 15 Mar 2004 11:56:31 -0600 (CST) In-Reply-To: <4.3.2.7.2.20040315105339.027882f0@flask.cisco.com> References: <4.3.2.7.2.20040315105339.027882f0@flask.cisco.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] Drafts to accept as dhc WG work items Date: Mon, 15 Mar 2004 12:01:57 -0600 To: Ralph Droms X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mar 15, 2004, at 9:56 AM, Ralph Droms wrote: > Vendor-Specific Suboption for the DHCP RAIO > > Renumbering Requirements for Stateless DHCPv6 > > (pending dhc WG charter update) > Lifetime Option for DHCPv6 > > (pending dhc WG charter update) > IPv4 and IPv6 Dual-Stack Issues for DHCPv6 > > (pending dhc WG charter update) I'm in favor of advancing these. Already discussed in Seoul, but if anybody wants to know why, Ill go into more detail. :') _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 15 13:06:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13575; Mon, 15 Mar 2004 13:06:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wTT-0005bA-It; Mon, 15 Mar 2004 13:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wSa-0005Xp-67 for dhcwg@optimus.ietf.org; Mon, 15 Mar 2004 13:05:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13477 for ; Mon, 15 Mar 2004 13:05:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2wSY-0001dO-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 13:05:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2wRe-0001ah-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 13:04:10 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1B2wR1-0001Xf-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 13:03:31 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2004 10:03:24 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i2FI2t8P019102; Mon, 15 Mar 2004 10:02:56 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.128]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGU12590; Mon, 15 Mar 2004 13:02:54 -0500 (EST) Message-Id: <4.3.2.7.2.20040315130007.020f6968@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Mar 2004 13:02:52 -0500 To: Changming Liu From: Ralph Droms Subject: RE: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item Cc: dhcwg@ietf.org In-Reply-To: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C77B@MONTEREY.netscree n.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The WG should consider both planned and unplanned changes, and come to consensus about whether both scenarios need to be addressed as part of the "requirements for informing DHCPv6 clients of changes in configuration information." We could add text to make the consideration of planned and unplanned changes explicit; if anyone thinks that text is needed, please send suggested text to the mailing list for review and comment. - Ralph At 09:51 AM 3/15/2004 -0800, Changming Liu wrote: >Hi Ralph, > >Will this "changes in the configuration" include "planned" and "unplanned" >changes? What are their definitions in your mind? > >We had such discussion in the mailing list and it does not appear to me it >has been cleanly understood by all the folks. > >Thanks. > >Changming > > > -----Original Message----- > > From: Ralph Droms [mailto:rdroms@cisco.com] > > Sent: Monday, March 15, 2004 8:49 AM > > To: dhcwg@ietf.org > > Subject: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item > > > > > > Here is proposed text for a dhc WG charter item to address > > renumbering > > stateless DHCPv6: > > > > The DHCPv6 specification in RFC3315 includes a mechanism through which > > clients can obtain other configuration information without obtaining > > an address or addresses. This mechanisms is sometimes called > > "stateless DHCPv6". RFC3315 includes no provision for notifying > > DHCPv6 clients using stateless DHCPv6 of changes in the configuration > > information supplied to the client. The dhc WG will assess the > > requirements for informing DHCPv6 clients of changes in configuration > > information, review alternative solutions and select a solution, and > > develop, review and publish a specification for the chosen solution. > > > > - Ralph > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 15 13:08:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13743; Mon, 15 Mar 2004 13:08:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wVO-00062L-31; Mon, 15 Mar 2004 13:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wUP-0005lB-6T for dhcwg@optimus.ietf.org; Mon, 15 Mar 2004 13:07:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13615 for ; Mon, 15 Mar 2004 13:06:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2wUN-0001jG-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 13:06:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2wTU-0001ff-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 13:06:04 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1B2wSU-0001cl-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 13:05:03 -0500 Received: from [66.93.187.232] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id E6F351B2230; Mon, 15 Mar 2004 11:59:34 -0600 (CST) In-Reply-To: <4.3.2.7.2.20040315114735.028073f0@flask.cisco.com> References: <4.3.2.7.2.20040315114735.028073f0@flask.cisco.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <46F3CCDB-76AB-11D8-8D56-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item Date: Mon, 15 Mar 2004 12:05:00 -0600 To: Ralph Droms X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mar 15, 2004, at 10:48 AM, Ralph Droms wrote: > Here is proposed text for a dhc WG charter item to address renumbering > stateless DHCPv6: Needless to say, I'm in favor of adding this to the charter. The text looks fine. :') _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 15 13:10:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13961; Mon, 15 Mar 2004 13:10:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wXK-0006Iy-KL; Mon, 15 Mar 2004 13:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wWT-0006Cn-20 for dhcwg@optimus.ietf.org; Mon, 15 Mar 2004 13:09:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13834 for ; Mon, 15 Mar 2004 13:09:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2wWR-0001s0-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 13:09:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2wVd-0001pE-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 13:08:17 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1B2wUo-0001lw-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 13:07:26 -0500 Received: from [66.93.187.232] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 24C341B2230; Mon, 15 Mar 2004 12:01:58 -0600 (CST) In-Reply-To: <4.3.2.7.2.20040315120224.027b6e38@flask.cisco.com> References: <4.3.2.7.2.20040315120224.027b6e38@flask.cisco.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9C185D22-76AB-11D8-8D56-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] Dual-stack hosts using DHCP as dhc WG charter item Date: Mon, 15 Mar 2004 12:07:23 -0600 To: Ralph Droms X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mar 15, 2004, at 11:03 AM, Ralph Droms wrote: > Here is proposed text for a dhc WG charter item to address dual-stack > hosts > using DHCP: The text looks fine to me, and I think we need to do this work. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 15 15:56:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24469; Mon, 15 Mar 2004 15:56:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2z7y-0003LQ-7K; Mon, 15 Mar 2004 15:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2z7B-0003Ie-VH for dhcwg@optimus.ietf.org; Mon, 15 Mar 2004 15:55:13 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24074; Mon, 15 Mar 2004 15:55:10 -0500 (EST) Message-Id: <200403152055.PAA24074@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 15 Mar 2004 15:55:10 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dna-ipv4-06.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Detection of Network Attachment (DNA) in IPv4 Author(s) : B. Aboba Filename : draft-ietf-dhc-dna-ipv4-06.txt Pages : 16 Date : 2004-3-15 The time required to detect movement (or lack of movement) between subnets, and to obtain (or continue to use) a valid IPv4 address may be significant as a fraction of the total delay in moving between points of attachment. This specification synthesizes experience garnered over the years in the deployment of hosts supporting ARP, DHCP and IPv4 Link-Local addresses, in order to optimize detection of network attachment by mobile hosts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dna-ipv4-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dna-ipv4-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-15142602.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dna-ipv4-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dna-ipv4-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-15142602.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 15 16:30:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28579; Mon, 15 Mar 2004 16:30:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2zes-0005Nk-Rb; Mon, 15 Mar 2004 16:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2zdw-0005Mn-0f for dhcwg@optimus.ietf.org; Mon, 15 Mar 2004 16:29:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28512 for ; Mon, 15 Mar 2004 16:29:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2zdt-00012j-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 16:29:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2zd5-00010n-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 16:28:12 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1B2zcN-0000ww-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 16:27:28 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 15 Mar 2004 13:26:22 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2FLQoU7026336 for ; Mon, 15 Mar 2004 16:26:56 -0500 (EST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-95.cisco.com [10.86.240.95]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGU33650; Mon, 15 Mar 2004 16:26:50 -0500 (EST) Message-Id: <4.3.2.7.2.20040315161655.028ffcf8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Mar 2004 16:26:47 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] Dual-stack hosts using DHCP as dhc WG charter item In-Reply-To: <4.3.2.7.2.20040315120224.027b6e38@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Regardless of whether we decide to add the issue of dual-stack hosts to the dhc WG charter, we have two drafts in the IESG today that have "Discuss" notes: Simple Network Time Protocol Configuration Option for DHCPv6 draft-ietf-dhc-dhcpv6-opt-sntp-00 NIS Configuration Options for DHCPv6 draft-ietf-dhc-dhcpv6-opt-nisconfig-05 The WG needs to decide how to proceed with these two drafts. So, I would like to determine WG consensus on the following questions: 1. Does the WG want to request the IESG to advance the drafts unchanged? 2. If the answer to 1 is no, does the WG want to revise the drafts in parallel with the resolution of the dual-stack hosts issue, or does the WG want to postpone advancement of these drafts until the dual-stack hosts issue is resolved? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 15 16:46:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24470; Mon, 15 Mar 2004 15:56:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2z7x-0003L6-Ek; Mon, 15 Mar 2004 15:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2z77-0003IZ-Ou for dhcwg@optimus.ietf.org; Mon, 15 Mar 2004 15:55:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24058 for ; Mon, 15 Mar 2004 15:55:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2z76-0004fl-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 15:55:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2z60-0004UF-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 15:54:02 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1B2z4a-0004C2-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 15:52:32 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2004 12:52:29 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i2FKpx8P015500; Mon, 15 Mar 2004 12:52:00 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-95.cisco.com [10.86.240.95]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGU30005; Mon, 15 Mar 2004 15:51:58 -0500 (EST) Message-Id: <4.3.2.7.2.20040315154830.02896fb8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Mar 2004 15:51:55 -0500 To: Changming Liu From: Ralph Droms Subject: RE: [dhcwg] Drafts to accept as dhc WG work items Cc: dhcwg@ietf.org In-Reply-To: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C77C@MONTEREY.netscree n.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Changming - based on the discussion at the WG meeting in Seoul, there is some support for your view that management of information received from multiple interfaces is a local policy issue on the host. There is also some support for adding machinery to DHCP to disambiguate the information received by a host. We need to work through the issue to come to consensus about whether there is a problem that DHCP can solve, and then what that solution might be... - Ralph At 09:55 AM 3/15/2004 -0800, Changming Liu wrote: >Hi Ralph, > >As I pointed out in the mailing list, the last item "IPv4 and IPv6 >Dual-Stack Issues for DHCPv6" is a local administrative issue. I have not >heard any objection or more dicussions on this subject. If no more interest, >we may just drop it. > >Thanks. > >Changming > > > -----Original Message----- > > From: Ralph Droms [mailto:rdroms@cisco.com] > > Sent: Monday, March 15, 2004 7:56 AM > > To: dhcwg@ietf.org > > Subject: [dhcwg] Drafts to accept as dhc WG work items > > > > > > Several drafts were considered for acceptance as dhc WG work > > items at the WG > > meeting in Seoul. I'm writing to confirm consensus on these actions. > > Please respond with comment about accepting the following > > drafts as dhc WG > > work items: > > > > Vendor-Specific Suboption for the DHCP RAIO > > > > > > Renumbering Requirements for Stateless DHCPv6 > > > > (pending dhc WG charter update) > > > > Lifetime Option for DHCPv6 > > > > (pending dhc WG charter update) > > > > IPv4 and IPv6 Dual-Stack Issues for DHCPv6 > > > > (pending dhc WG charter update) > > > > > > - Ralph > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 15 17:06:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00894; Mon, 15 Mar 2004 17:06:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30Dj-0008C8-89; Mon, 15 Mar 2004 17:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30Cz-0008Ab-HX for dhcwg@optimus.ietf.org; Mon, 15 Mar 2004 17:05:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00860 for ; Mon, 15 Mar 2004 17:05:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B30Cx-0003hA-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 17:05:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B30Bs-0003fG-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 17:04:09 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1B30B7-0003Zl-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 17:03:21 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i2FM2T9u028651; Mon, 15 Mar 2004 14:02:34 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Mar 2004 14:02:29 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C78A@MONTEREY.netscreen.com> From: Changming Liu To: "'Ralph Droms'" Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Drafts to accept as dhc WG work items Date: Mon, 15 Mar 2004 14:02:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Ralph, Fair enough. We can continue to work through the issue until it is clear. My point is that DHCP can definitely help solve the problem to certain degree. But if there is a solution without changing DHCP and can also support DHCP, will it be better? Changming > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Monday, March 15, 2004 12:52 PM > To: Changming Liu > Cc: dhcwg@ietf.org > Subject: RE: [dhcwg] Drafts to accept as dhc WG work items > > > Changming - based on the discussion at the WG meeting in > Seoul, there is > some support for your view that management of information > received from > multiple interfaces is a local policy issue on the host. > There is also some > support for adding machinery to DHCP to disambiguate the information > received by a host. > > We need to work through the issue to come to consensus about > whether there > is a problem that DHCP can solve, and then what that solution > might be... > > - Ralph > > At 09:55 AM 3/15/2004 -0800, Changming Liu wrote: > >Hi Ralph, > > > >As I pointed out in the mailing list, the last item "IPv4 and IPv6 > >Dual-Stack Issues for DHCPv6" is a local administrative > issue. I have not > >heard any objection or more dicussions on this subject. If > no more interest, > >we may just drop it. > > > >Thanks. > > > >Changming > > > > > -----Original Message----- > > > From: Ralph Droms [mailto:rdroms@cisco.com] > > > Sent: Monday, March 15, 2004 7:56 AM > > > To: dhcwg@ietf.org > > > Subject: [dhcwg] Drafts to accept as dhc WG work items > > > > > > > > > Several drafts were considered for acceptance as dhc WG work > > > items at the WG > > > meeting in Seoul. I'm writing to confirm consensus on > these actions. > > > Please respond with comment about accepting the following > > > drafts as dhc WG > > > work items: > > > > > > Vendor-Specific Suboption for the DHCP RAIO > > > > > > > > > Renumbering Requirements for Stateless DHCPv6 > > > > > > (pending dhc WG charter update) > > > > > > Lifetime Option for DHCPv6 > > > > > > (pending dhc WG charter update) > > > > > > IPv4 and IPv6 Dual-Stack Issues for DHCPv6 > > > > > > (pending dhc WG charter update) > > > > > > > > > - Ralph > > > > > > > > > _______________________________________________ > > > dhcwg mailing list > > > dhcwg@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 15 17:36:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03483; Mon, 15 Mar 2004 17:36:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30gp-0002aK-Af; Mon, 15 Mar 2004 17:36:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30gH-0002VC-Ad for dhcwg@optimus.ietf.org; Mon, 15 Mar 2004 17:35:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03300 for ; Mon, 15 Mar 2004 17:35:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B30gE-0006fP-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 17:35:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B30ei-0006LL-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 17:33:57 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1B30bW-0005w6-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 17:30:38 -0500 Received: from [66.93.187.232] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id C29DF1B2230; Mon, 15 Mar 2004 16:25:02 -0600 (CST) In-Reply-To: <4.3.2.7.2.20040315161655.028ffcf8@flask.cisco.com> References: <4.3.2.7.2.20040315161655.028ffcf8@flask.cisco.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5D9A3DC6-76D0-11D8-8D56-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] Dual-stack hosts using DHCP as dhc WG charter item Date: Mon, 15 Mar 2004 16:30:30 -0600 To: Ralph Droms X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Isn't the problem with the nis draft a question of whether it really needs that section that says in what packet types the option is allowed? Personally, I think we should advance the drafts unchanged - I don't see how a solution to the dual-stack issue is going to work if it requires that all the existing option drafts be changed, and furthermore I don't really see a reason why we'd do it that way even if it were an option. I think it might be worth discussing whether or not there's a better way to handle the "this option allowed in packets of type X" boilerplate, though, without holding this draft hostage to the discussion. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 15 18:10:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05413; Mon, 15 Mar 2004 18:10:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B31Dd-0000QI-6S; Mon, 15 Mar 2004 18:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B31Cy-0000H3-MU for dhcwg@optimus.ietf.org; Mon, 15 Mar 2004 18:09:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05293 for ; Mon, 15 Mar 2004 18:09:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B31Cw-0001CH-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 18:09:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B31Bz-00019n-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 18:08:20 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1B31Bb-00016h-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 18:07:55 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 15 Mar 2004 15:06:47 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2FN7OU7016619 for ; Mon, 15 Mar 2004 18:07:24 -0500 (EST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-95.cisco.com [10.86.240.95]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGU43002; Mon, 15 Mar 2004 18:07:22 -0500 (EST) Message-Id: <4.3.2.7.2.20040315170154.02944ed8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Mar 2004 18:06:19 -0500 To: dhcwg@ietf.org From: Ralph Droms In-Reply-To: <17287.1076497871@munnari.OZ.AU> References: <2015037.1076400623@localhost> <2015037.1076400623@localhost> <2435506122.1076323711@localhost> <000801c3ef35$831e44d0$6401a8c0@BVolz> <2134.1076399906@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Dual-stack hosts using DHCP (was Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , In the interest of forward movement, I would like the WG to pick up the conversation about dual-stack issues around the two specific drafts draft-ietf-dhc-dhcpv6-opt-sntp-00 and draft-ietf-dhc-dhcpv6-opt-nisconfig-05. After re-reading draft-ietf-dhc-dual-stack-00 and considering the discussion of dual-stack issues at the WG meeting in Seoul, I find myself in agreement with kre's analysis (included below). Fundamentally, there is a problem here that rightfully belongs in the administrative or management policy in the host itself. A host may receive configuration information from a variety of sources: PPP, RAs (IPv6), well-known addresses for services, SLP, DNS SRV RRS, DHCP, manual configuration, etc. The host itself may be connected to multiple physical interfaces or multiple logical interfaces (e.g., VPN). I can imagine constructing multiple plausible scenarios in which the host would use configuration information from multiple sources in different ways. And, looking at the problem from the DHCP point of view, there is no way for the DHCP server to determine how the host is configured, and, therefore no way for the DHCP server to determine the right way to deliver the configuration information to the host. Therefore, it seems to me the right thing to do is for the various sources of configuration information to operate independently, allowing the host to make any decisions about integrating the information from the various sources. In the case of DHCP, I think the right thing to do is to keep DHCPv4 and DHCPv6 separate, so the host treats information from DHCPv4 and DHCPv6 as arriving from different sources, and makes its own decisions about how to integrate the information. In the case of draft-ietf-dhc-dhcpv6-opt-sntp-00 and draft-ietf-dhc-dhcpv6-opt-nisconfig-05, the right thing to do would be to carry only IPv6 address in these options, leaving the decision about how to use those addresses up to the receiving host. - Ralph At 06:11 PM 2/11/2004 +0700, Robert Elz wrote: > Date: Tue, 10 Feb 2004 08:10:23 -0800 > From: Harald Tveit Alvestrand > Message-ID: <2015037.1076400623@localhost> > > | Apologies - just because I think you're wrong is no excuse for > snapping at > | you. > >No apologies needed, at least not for me - the message I replied to >wasn't directed (specifically) at me. In any case, I didn't view your >comment as in any way objectionable, just farcical... > > | I still think you're wrong. > >I fully understand your point of view. And I certainly agree, >getting different config info from different sources is a problem, >and one that it would be nice to have a clean solution to. > >But I don't think you can really expect DHCP to suddenly provide it, >or not in the context of the DHCPv6 NIS configuration option in >any case. > >The problem is much broader than that - there are many more sources >of config info than just N interfaces each providing host config >information via DHCP. > >Config info is also available via well known addresses (ie: SNTP could >be using the well known multicast address, instead of a particular server) >or via SLP, or perhaps even DNS SRV records, or ... > >Any and all of that might conflict with any other of it. What a host >should do in circumstances like those isn't easy to specify. > >DHCP on the other hand has been as it is now since day 1 - it gets config >info about an interface, and throws in all kinds of host configuration >at the same time - naturally leading to (potentially) multiple different >configs being received. DHCPv4 is like that, DHCPv6 isn't any different. >Altering that would be a major project, and NIS configuration just isn't >important enough to embark upon that! > >kre > >ps: I haven't read today's list traffic yet (the last message I saw >was my own - the one full of typos). _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 15 18:26:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06778; Mon, 15 Mar 2004 18:26:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B31T8-0004Ud-G0; Mon, 15 Mar 2004 18:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B31SK-00047M-02 for dhcwg@optimus.ietf.org; Mon, 15 Mar 2004 18:25:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06663 for ; Mon, 15 Mar 2004 18:25:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B31SG-000202-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 18:25:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B31RK-0001ww-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 18:24:11 -0500 Received: from smtp814.mail.sc5.yahoo.com ([66.163.170.84]) by ietf-mx with smtp (Exim 4.12) id 1B31QP-0001tc-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 18:23:14 -0500 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.119.83 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 15 Mar 2004 23:03:31 -0000 Reply-To: From: "Richard Barr Hibbs" To: "Dhcwg" Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-3315id-for-v4-02.txt Date: Mon, 15 Mar 2004 15:09:53 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ted and Bill-- the proposal to modify the definition of DHCP(v4) 'client identifiers' to be compatible with RFC3315 'DHCP Unique Identifiers' (DUIDs) represents a good approach to solving some of our long-standing issues about the identification and recognition of DHCP(v4) clients, especially in an environment where transition between DHCPv4 and DHCPv6 is planned. I disagree on a number of points, which I'd like to present here. First, a DHCPv6 DUID is intended to be globally unique, while a DHCPv4 'client identifier' is not [from section 9 of RFC3315: "The motivation for having more than one type of DUID is that the DUID must be globally unique, and must also be easy to generate."] A second problem that you point out in section 4.2 of the draft is, "... some DHCPv4 servers can be configured not to conform to RFC2131 and RFC2131 [sic], in the sense that they ignore the 'client identifier' option and use the client's hardware address instead. A clarification of the RFCs seems in order. I posit another problem that arises from the current definition of 'client identifier.' RFC2132 _suggests_ a method for generating an appropriately [subnet-] unique identifier, but several known implementations treat RFC2132's "MAY" as "MUST" and "SHOULD" as "MAY." [from section 9.14 of RFC2132, "Identifiers SHOULD be treated as opaque objects by DHCP servers. The client identifier MAY consist of type-value pairs similar to the 'htype'/'chaddr' fields...."] Finally, during our conference calls discussing the RFC2131 implementation issues we reached a rough consensus about the DHCPv4 client identifier, including the following points: 1. the 'client identifier' is an opaque octet string [not null terminated] from which a DHCPv4 server SHOULD NOT infer or expect any structure. 2. all description of how a 'client identifier' MAY be generated by a DHCPv4 client will be removed from RFC2131 and contained ONLY in RFC2132. 3. description of alternative methods for generating a subnet-unique 'client identifier' will be included in RFC2132. 4. the wording of both RFCs would be carefully checked to ensure that both are completely consistent describing the generation and use of 'client identifiers' and that any wording changes will not alter our consensus on the use of 'client identifier' to recognize and identify a DHCPv4 client. So, my proposal for this draft is that it should define a NEW DHCPv4 option, to be used IN PLACE OF 'client identifier' option 61 where interoperability with DHCPv6 is required or anticipated. Separately, we would update RFC2131 and RFC2132 according to the consensus we reached earlier. With this in mind, I offer the following edits to your draft (proposed changes marked by quotation marks): Abstract This document "specifies a new option" for encoding DHCPv4 [RFC2131 and RFC2132] client identifiers, so that those identifiers will be interchangeable with identifiers used in the DHCPv6 protocol [RFC3315]. Introduction This document specifies the way in which DHCPv4 clients should identify themselves "when operated in an environment that includes or is anticipated to include DHCPv6 clients, such as during a transition from DHCPv4 to DHCPv6." DHCPv4 client implementations that conform to this specification use a DHCPv6-style DHCP Unique Identifier (DUID) "in a new DHCPv4 option." This "updates" the behaviour specified in RFC2131 and RFC2132. 2.4. RFC2131 does not require the use of a client identifier RFC2131 allows the DHCP server to identify clients either by using the client identifier option sent by the client, or, if the client did not send one, the client's link-layer address. Like the client identifier format "suggested" by RFC2131, this suffers from the problems previously described in "sections 2.2 and 2.3." 3. Solutions The solution to problem (2.4) is to deprecate the use of the contents of the 'chaddr' field in the DHCP packet as a means of identifying the client. "For backwards compatibility in a DHCPv4-only environment, this behavior must remain as a default, whose use is strongly discouraged." 4.1. DHCP Client behavior DHCP clients conforming to this specification MUST use stable DHCP node identifiers in the "new DHCP unique identifier" option. DHCP clients MUST NOT use "DHCP unique" identifiers based solely on layer two addresses that are hard-wired to the layer two device (e.g., the ethernet MAC address) as suggested in RFC2131 "and RFC2132 for 'client identifiers'", except as allowed in section 9.2 of RFC3315. DHCP clients MUST send a '"DHCP unique" identifier' "option if interoperation with DHCPv6 clients and servers is anticipated, or MAY send a 'client identifier' option if interoperation is not anticipated, but MUST NOT send both." "If the DHCPv4 client sends a 'DHCP unique identifier' option it MUST be composed of" an Identity Association Unique Identifier, as defined in section 10 of RFC3315, and a DHCP Unique Identifier, as defined in section 9 of RFC3315. These together constitute an RFC3315-style binding identifier. The general format of the DHCPv4 'client identifier' option is defined in section 9.14 of RFC2132, "and remains unchanged by this proposal." The format of the proposed '"DHCP unique" identifier' option is as follows: Code Len /----- IAID ------\ /------ DUID ------- ... +-----+----+----+----+----+----+----+----+----+----+---- | TBD | n | i1 | i2 | i3 | i4 | d1 | d2 | d3 | d4 | ... +-----+----+----+----+----+----+----+----+----+----+---- octets 1 2 3 4 5 6 7 8 9 10 ... Any DHCPv4 or DHCPv6 client that conforms to this specification SHOULD provide a means by which an operator can learn what DUID the client has chosen. Such clients SHOULD also provide a means by which the operator can configure the DUID. A device that is normally configured with both a DHCPv4 and DHCPv6 client SHOULD automatically use the same DUID for DHCPv4 and DHCPv6 without any operator intervention. DHCP clients that support more than one network interface SHOULD use the same DUID on every interface. DHCP clients that support more than one network interface SHOULD use a different IAID on each interface. 4.3. Changes from RFC2131 In section 2 of RFC2131, on page 9, the text that reads, "for example, the 'client identifier' may contain a hardware address, identical to the contents of the 'chaddr' field, or it may contain another type of identifier, such as a DNS name" is deleted. [rbh--this is probably what the RFC2131 implementation issues draft will eventually propose] In section 4.2 of RFC2131, the text "The client MAY choose to explicitly provide the identifier through the 'client identifier' option. If the client supplies a 'client identifier', the client MUST use the same 'client identifier' in all subsequent messages, and the server MUST use that identifier to identify the client. If the client does not provide a 'client identifier' option, the server MUST use the contents of the 'chaddr' field to identify the client" is replaced by the text, "The client MUST explicitly provide a client identifier through the 'client identifier' option." [rbh--while I agree this is desirable, I think that MUST ought to be SHOULD to allow existing implementations to remain conformant to RFC2131, and because I'm proposing that we create a new option, the wording should reflect this] In the same section, the text "Use of 'chaddr' as the client's unique identifier may cause unexpected results, as that identifier may be associated with a hardware interface that could be moved to a new client. Some sites may choose to use a manufacturer's serial number as the 'client identifier', to avoid unexpected changes in a clients network address due to transfer of hardware interfaces among computers. Sites may also choose to use a DNS name as the 'client identifier', causing address leases to be associated with the DNS name rather than a specific hardware box." is replaced by the text "The DHCP client MUST NOT rely on the 'chaddr' field to identify it." [rbh--I'd like to see the word "uniquely" inserted here: "... field to uniquely identify it."] In section 4.4.1 of RFC2131, the text "The client MAY include a different unique identifier" is replaced with "The client MUST include a unique identifier". [rbh--again, although I agree this is most desirable, I think SHOULD is appropriate for backwards compatibility] In sections 3.1, item 4 and 6, 3.2 item 3 and 4, and 4.3.1, where RFC2131 says that 'chaddr' may be used instead of the 'client identifier' option, the text that says "or 'chaddr'" and "'chaddr' or" is deleted. [rbh--wording should favor use of 'DUID' option (proposed by this memo, but permits 'client identifier' option] Note that these changes do not relieve the DHCP server of the obligation to use 'chaddr' as an identifier if the client does not send a 'client identifier' option. Rather, they oblige clients that conform with this document to send a "'DHCP unique identifier' option (preferred) or a 'client identifier' option, and not rely on 'chaddr' for identification. DHCP servers MUST use 'chaddr' as an identifier in cases where "'DHCP unique identifier' or" 'client identifier' is not sent, in order to support old clients that do not conform with this document. 4.4. Changes from RFC2132 The text in section 9.14, beginning with "The client identifier MAY consist of" through "that meet this requirement for uniqueness." is replaced with "the client identifier consists of a type field whose value is normally 255, followed by a two-byte type field, followed by the contents of the identifier. The two-byte type field and the format of the contents of the identifier are defined in RF3315,section 9." The text "its minimum length is 2" in the following paragraph is deleted. [rbh--the implementation issues group will hopefully soon decide on a new definition for option 61, so I'd suggest leaving this text alone for the moment] --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 15 21:19:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15270; Mon, 15 Mar 2004 21:19:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B34AX-0007Zc-0X; Mon, 15 Mar 2004 21:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B349m-0007YL-9u for dhcwg@optimus.ietf.org; Mon, 15 Mar 2004 21:18:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15219 for ; Mon, 15 Mar 2004 21:18:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B349j-0007F0-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 21:18:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B348l-0007BM-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 21:17:11 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1B347n-00076e-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 21:16:11 -0500 Received: from [66.93.187.232] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 00BFB1B22B2; Mon, 15 Mar 2004 20:10:40 -0600 (CST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Dhcwg" From: Ted Lemon Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-3315id-for-v4-02.txt Date: Mon, 15 Mar 2004 20:16:11 -0600 To: X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mar 15, 2004, at 5:09 PM, Richard Barr Hibbs wrote: > So, my proposal for this draft is that it should define a > NEW DHCPv4 option, to be used IN PLACE OF 'client > identifier' option 61 where interoperability with DHCPv6 is > required or anticipated. I must respectfully disagree. This will create huge interoperability problems. Really, what will happen is that nobody will ever implement it. I am sorry to hear that the conference call came to a decision that was in conflict with this draft, but it has been the intention in writing the draft to fix the DHCP client identifier, not break it. Adding a new DHCP option that serves the same purpose would break it. > First, a DHCPv6 DUID is intended to be globally unique, > while a DHCPv4 'client identifier' is not [from section 9 The 3315id draft fixes this bug in RFC2131/RFC2132. This is very much one of the intended outcomes of the adoption of this draft. I don't see any benefit to perpetuating this bug. > ignore the 'client identifier' option and use the client's > hardware address instead. A clarification of the RFCs seems > in order. The 3315id draft makes such a clarification. > [from section 9.14 of RFC2132, "Identifiers SHOULD be > treated as opaque objects by DHCP servers. The client > identifier MAY consist of type-value pairs similar to the > 'htype'/'chaddr' fields...."] If you conform to the 3315id specification, the client identifier MUST NOT be of this form. > 1. the 'client identifier' is an opaque octet string [not > null terminated] from which a DHCPv4 server SHOULD NOT > infer or expect any structure. In the abstract, I think this is a fine thing to say. However, if clients conform to the 3315id draft, this definitely isn't correct. If the changes specified in the 3315id draft are folded into the replacement for RFC2131/2132, I don't see any benefit to retaining this old language with respect to conforming client identifier options. Backward compatibility is of course still needed, and I don't mind saying that for cases where the 3315id-style identifier is not sent by the client, the server should treat the identifier as opaque. I think the other three points are fine - of course the format of the option should be specified in only one place, and of course the two RFCs should be consistent in their use of the option. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 15 23:17:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21863; Mon, 15 Mar 2004 23:17:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B360i-0007f8-Sp; Mon, 15 Mar 2004 23:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B35zm-0007bQ-2D for dhcwg@optimus.ietf.org; Mon, 15 Mar 2004 23:16:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21690 for ; Mon, 15 Mar 2004 23:15:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B35zj-00024G-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 23:15:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B35yi-0001sr-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 23:14:58 -0500 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx with esmtp (Exim 4.12) id 1B35wg-0001cf-00 for dhcwg@ietf.org; Mon, 15 Mar 2004 23:12:50 -0500 Received: from localhost ([130.194.13.81]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01L7SRK3BRHI8ZGV96@vaxc.its.monash.edu.au> for dhcwg@ietf.org; Tue, 16 Mar 2004 14:49:16 +1100 Received: from kapow.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id DD0481B000D; Tue, 16 Mar 2004 14:49:15 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id C7F91124011; Tue, 16 Mar 2004 14:49:15 +1100 (EST) Date: Tue, 16 Mar 2004 14:49:15 +1100 From: Greg Daley Subject: Re: [dhcwg] Dual-stack hosts using DHCP (was Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt) To: Ralph Droms Cc: dhcwg@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <4056793B.5070604@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <2015037.1076400623@localhost> <2015037.1076400623@localhost> <2435506122.1076323711@localhost> <000801c3ef35$831e44d0$6401a8c0@BVolz> <2134.1076399906@munnari.OZ.AU> <4.3.2.7.2.20040315170154.02944ed8@flask.cisco.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi Ralph, Ralph Droms wrote: > > In the interest of forward movement, I would like the WG to pick up the > conversation about dual-stack issues around the two specific drafts > draft-ietf-dhc-dhcpv6-opt-sntp-00 and > draft-ietf-dhc-dhcpv6-opt-nisconfig-05. > I've not read these deeply, but perhaps I can contribute for the wider context. > > After re-reading draft-ietf-dhc-dual-stack-00 and considering the > discussion > of dual-stack issues at the WG meeting in Seoul, I find myself in agreement > with kre's analysis (included below). > > Fundamentally, there is a problem here that rightfully belongs in the > administrative or management policy in the host itself. A host > may receive configuration information from a variety of sources: PPP, > RAs (IPv6), well-known addresses for services, SLP, DNS SRV RRS, DHCP, > manual configuration, etc. The host itself may be connected to multiple > physical interfaces or multiple logical interfaces (e.g., VPN). I'd guess that part of this is what's motivating the work on DNAv4 and DNAv6, where the host is essentially trying to determine what's authoritative configuration for basic connectivity. Eventually, we may see some ideas about IPv4 and IPv6 interoperation in DNA heading in the same direction, so I'm interested in seeing how things pan out here. > I can imagine constructing multiple plausible scenarios in which > the host would use configuration information from multiple > sources in different ways. And, looking at the problem from the > DHCP point of view, there is no way for the DHCP server to > determine how the host is configured, and, therefore no way > for the DHCP server to determine the right way to deliver > the configuration information to the host. > > Therefore, it seems to me the right thing to do is for the > various sources of configuration information to operate > independently, allowing the host to make any decisions about > integrating the information from the various sources. It's been said before, but I'd guess that the security associations for IPv4 and IPv6 based configuration information may (in general) be difficult to reconcile here too. I'd guess that the role of joining the v4/v6 configuration systems together is principally to limit signalling. At this stage, I don't know if there's a compelling idea otherwise. This may be a real driver for hosts on wireless access networks though. > In the case of DHCP, I think the right thing to do is to > keep DHCPv4 and DHCPv6 separate, so the host treats information from > DHCPv4 and DHCPv6 as arriving from different sources, and makes its > own decisions about how to integrate the information. Perhaps this isn't entirely in agreement with what you stated above. I'd guess that a host which is capable of both IPv4 and IPv6 configuration could explicitly request version specific information on either configuration path. This could potentially be a host decision, based on logic above either DHCPv4 or DHCPv6. As kre says, this may not be something which can just be written up yet, since it presupposes co-ordination of the procedures which isn't available in either protocol yet, or may be done more fruitfully in general, rather than just for DHC or even DNA. > In the case of draft-ietf-dhc-dhcpv6-opt-sntp-00 and > draft-ietf-dhc-dhcpv6-opt-nisconfig-05, the right thing to do would > be to carry only IPv6 address in these options, leaving the > decision about how to use those addresses up to the > receiving host. > I'd guess that's right at the moment, but it may be worth looking at the host based mechanisms to co-ordinate these things: Whether there's a need to combine the DHCPv4/v6, or even a more general need to co-ordinate further configuration signalling may affect how this is done. Greg > - Ralph > > At 06:11 PM 2/11/2004 +0700, Robert Elz wrote: > >> Date: Tue, 10 Feb 2004 08:10:23 -0800 >> From: Harald Tveit Alvestrand >> Message-ID: <2015037.1076400623@localhost> >> >> | Apologies - just because I think you're wrong is no excuse for >> snapping at >> | you. >> >> No apologies needed, at least not for me - the message I replied to >> wasn't directed (specifically) at me. In any case, I didn't view your >> comment as in any way objectionable, just farcical... >> >> | I still think you're wrong. >> >> I fully understand your point of view. And I certainly agree, >> getting different config info from different sources is a problem, >> and one that it would be nice to have a clean solution to. >> >> But I don't think you can really expect DHCP to suddenly provide it, >> or not in the context of the DHCPv6 NIS configuration option in >> any case. >> >> The problem is much broader than that - there are many more sources >> of config info than just N interfaces each providing host config >> information via DHCP. >> >> Config info is also available via well known addresses (ie: SNTP could >> be using the well known multicast address, instead of a particular >> server) >> or via SLP, or perhaps even DNS SRV records, or ... >> >> Any and all of that might conflict with any other of it. What a host >> should do in circumstances like those isn't easy to specify. >> >> DHCP on the other hand has been as it is now since day 1 - it gets config >> info about an interface, and throws in all kinds of host configuration >> at the same time - naturally leading to (potentially) multiple different >> configs being received. DHCPv4 is like that, DHCPv6 isn't any >> different. >> Altering that would be a major project, and NIS configuration just isn't >> important enough to embark upon that! >> >> kre >> >> ps: I haven't read today's list traffic yet (the last message I saw >> was my own - the one full of typos). > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 16 08:06:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28856; Tue, 16 Mar 2004 08:06:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3EGg-0005Jk-KA; Tue, 16 Mar 2004 08:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3EGY-0005J4-4V for dhcwg@optimus.ietf.org; Tue, 16 Mar 2004 08:05:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28828 for ; Tue, 16 Mar 2004 08:05:52 -0500 (EST) From: Janne.Tuononen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3EGX-000139-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:05:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3EFW-0000wS-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:04:51 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1B3EEs-0000rB-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:04:10 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2GD49A05418 for ; Tue, 16 Mar 2004 15:04:09 +0200 (EET) X-Scanned: Tue, 16 Mar 2004 15:03:55 +0200 Nokia Message Protector V1.3.20 2004022613 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i2GD3tWc022478 for ; Tue, 16 Mar 2004 15:03:55 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00KRcsgM; Tue, 16 Mar 2004 15:03:53 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2GD3ms28478 for ; Tue, 16 Mar 2004 15:03:48 +0200 (EET) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 16 Mar 2004 15:03:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-lifetime-00.txt Date: Tue, 16 Mar 2004 15:03:48 +0200 Message-ID: <143131738AF93F428B4A8A9360747AD00162BF51@esebe004.ntc.nokia.com> Thread-Topic: [dhcwg] I-D ACTION:draft-ietf-dhc-lifetime-00.txt thread-index: AcQGGTn+Pc9SzjZtTJCcOed4U8FJ6QFPb4eA To: X-OriginalArrivalTime: 16 Mar 2004 13:03:48.0120 (UTC) FILETIME=[1EDEE180:01C40B57] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Heya, I read through the draft and I have to say this really is something that = is needed or will be needed soon. However, while reading the draft one = issue in it caught my attention. Proposed Lifetime option is defined in the draft... 3. Lifetime option definition The lifetime option specifies a lifetime for all configuration data contained in other options in an advertise or reply message that = have no associated lifetime. This means that it does not effect e.g. the IA Address option which contains a lifetime. My comment and question is: What is the reason to limit usage of this = option to 1/message? Doesn't this (unnecessarily?) limit the use of the = option, especially in the server? =20 If existence of more than 1 lifetime option would be allowed, server = could group options according to their lifetimes in the Reply message. = This would not just optimize traffic between clients and servers in = certain cases, but also make the option more versatile in general. At = least in the future DHCPv6 option space assumable will contain options = that prefer different lifetimes and still server would like to put them = all into same message. Modified definition for the option that would allow 1+ lifetime options = would be: The lifetime option specifies a lifetime for all configuration data contained in other options following the lifetime option in an = advertise or reply message that have no associated lifetime. = This means that it does not effect e.g. the IA Address option which = contains a lifetime. This definition would also enable possibility to have options in the = message that are not affected by any lifetime option (put them before = any lifetime option in the message). Semantics for using several lifetime options in the same message could = be=20 a) Sequential, where lifetime option defines lifetime for DHCPv6 options = (not having associated lifetime) following it in the message until the = next lifetime option.=20 or=20 b) Structured (encapsulated) use similar semantics as Vendor-specific = Information option aka encapsulate those options inside the Lifetime = option that are wanted to be affected by certain lifetime. =20 Regards, Janne Tuononen > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On=20 > Behalf Of ext > Internet-Drafts@ietf.org > Sent: 09 March, 2004 22:55 > Cc: dhcwg@ietf.org > Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-lifetime-00.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 16 08:32:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00010; Tue, 16 Mar 2004 08:32:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Efq-0007dr-C5; Tue, 16 Mar 2004 08:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Efk-0007dI-G0 for dhcwg@optimus.ietf.org; Tue, 16 Mar 2004 08:31:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29980 for ; Tue, 16 Mar 2004 08:31:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Efj-0003Pn-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:31:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Eem-0003KD-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:30:57 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B3EeI-0003E1-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:30:26 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2GDTrM7016217; Tue, 16 Mar 2004 05:29:53 -0800 (PST) Received: from volzw2k ([161.44.65.203]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGU69102; Tue, 16 Mar 2004 08:29:52 -0500 (EST) From: "Bernie Volz" To: "'Ralph Droms'" , Subject: RE: [dhcwg] Delete the list of drafts currently under consideration from dhc WG charter Date: Tue, 16 Mar 2004 08:29:52 -0500 Organization: Cisco Message-ID: <002401c40b5a$c3160960$cb412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal In-Reply-To: <4.3.2.7.2.20040315120854.027a7ef0@flask.cisco.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit No objection from me. And, as you may notice I'm now employed by Cisco Systems. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ralph Droms Sent: Monday, March 15, 2004 12:10 PM To: dhcwg@ietf.org Subject: [dhcwg] Delete the list of drafts currently under consideration from dhc WG charter Is there any objection to simply deleting the list of drafts currently under consideration from the dhc WG charter? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 16 08:32:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00009; Tue, 16 Mar 2004 08:32:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Efp-0007dj-UC; Tue, 16 Mar 2004 08:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Efg-0007dB-7p for dhcwg@optimus.ietf.org; Tue, 16 Mar 2004 08:31:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29976 for ; Tue, 16 Mar 2004 08:31:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Eff-0003PD-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:31:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Eel-0003K5-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:30:56 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3EeE-0003Dt-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:30:22 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 16 Mar 2004 05:34:26 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2GDTIib008129; Tue, 16 Mar 2004 14:29:19 +0100 (MET) Received: from volzw2k ([161.44.65.203]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGU69099; Tue, 16 Mar 2004 08:29:47 -0500 (EST) From: "Bernie Volz" To: "'Ralph Droms'" , Subject: RE: [dhcwg] Dual-stack hosts using DHCP (was Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt) Date: Tue, 16 Mar 2004 08:29:47 -0500 Organization: Cisco Message-ID: <002301c40b5a$c030ead0$cb412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal In-Reply-To: <4.3.2.7.2.20040315170154.02944ed8@flask.cisco.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ralph, et al: I fully agree with your "wg_member" comments. I too believe this is a host issue and not a DHCP protocol issue. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ralph Droms Sent: Monday, March 15, 2004 6:06 PM To: dhcwg@ietf.org Subject: [dhcwg] Dual-stack hosts using DHCP (was Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt) In the interest of forward movement, I would like the WG to pick up the conversation about dual-stack issues around the two specific drafts draft-ietf-dhc-dhcpv6-opt-sntp-00 and draft-ietf-dhc-dhcpv6-opt-nisconfig-05. After re-reading draft-ietf-dhc-dual-stack-00 and considering the discussion of dual-stack issues at the WG meeting in Seoul, I find myself in agreement with kre's analysis (included below). Fundamentally, there is a problem here that rightfully belongs in the administrative or management policy in the host itself. A host may receive configuration information from a variety of sources: PPP, RAs (IPv6), well-known addresses for services, SLP, DNS SRV RRS, DHCP, manual configuration, etc. The host itself may be connected to multiple physical interfaces or multiple logical interfaces (e.g., VPN). I can imagine constructing multiple plausible scenarios in which the host would use configuration information from multiple sources in different ways. And, looking at the problem from the DHCP point of view, there is no way for the DHCP server to determine how the host is configured, and, therefore no way for the DHCP server to determine the right way to deliver the configuration information to the host. Therefore, it seems to me the right thing to do is for the various sources of configuration information to operate independently, allowing the host to make any decisions about integrating the information from the various sources. In the case of DHCP, I think the right thing to do is to keep DHCPv4 and DHCPv6 separate, so the host treats information from DHCPv4 and DHCPv6 as arriving from different sources, and makes its own decisions about how to integrate the information. In the case of draft-ietf-dhc-dhcpv6-opt-sntp-00 and draft-ietf-dhc-dhcpv6-opt-nisconfig-05, the right thing to do would be to carry only IPv6 address in these options, leaving the decision about how to use those addresses up to the receiving host. - Ralph At 06:11 PM 2/11/2004 +0700, Robert Elz wrote: > Date: Tue, 10 Feb 2004 08:10:23 -0800 > From: Harald Tveit Alvestrand > Message-ID: <2015037.1076400623@localhost> > > | Apologies - just because I think you're wrong is no excuse for > snapping at > | you. > >No apologies needed, at least not for me - the message I replied to >wasn't directed (specifically) at me. In any case, I didn't view your >comment as in any way objectionable, just farcical... > > | I still think you're wrong. > >I fully understand your point of view. And I certainly agree, >getting different config info from different sources is a problem, and >one that it would be nice to have a clean solution to. > >But I don't think you can really expect DHCP to suddenly provide it, or >not in the context of the DHCPv6 NIS configuration option in any case. > >The problem is much broader than that - there are many more sources of >config info than just N interfaces each providing host config >information via DHCP. > >Config info is also available via well known addresses (ie: SNTP could >be using the well known multicast address, instead of a particular >server) or via SLP, or perhaps even DNS SRV records, or ... > >Any and all of that might conflict with any other of it. What a host >should do in circumstances like those isn't easy to specify. > >DHCP on the other hand has been as it is now since day 1 - it gets >config info about an interface, and throws in all kinds of host >configuration at the same time - naturally leading to (potentially) multiple different >configs being received. DHCPv4 is like that, DHCPv6 isn't any different. >Altering that would be a major project, and NIS configuration just >isn't important enough to embark upon that! > >kre > >ps: I haven't read today's list traffic yet (the last message I saw was >my own - the one full of typos). _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 16 08:33:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00109; Tue, 16 Mar 2004 08:33:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Egn-0007uZ-Eh; Tue, 16 Mar 2004 08:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3EgP-0007sO-Ec for dhcwg@optimus.ietf.org; Tue, 16 Mar 2004 08:32:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00074 for ; Tue, 16 Mar 2004 08:32:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3EgO-0003TO-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:32:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3EfP-0003N3-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:31:36 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B3EeQ-0003EE-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:30:34 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 16 Mar 2004 05:33:33 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2GDU1M7016323; Tue, 16 Mar 2004 05:30:01 -0800 (PST) Received: from volzw2k ([161.44.65.203]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGU69110; Tue, 16 Mar 2004 08:30:00 -0500 (EST) From: "Bernie Volz" To: "'Ralph Droms'" , Subject: RE: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item Date: Tue, 16 Mar 2004 08:30:00 -0500 Organization: Cisco Message-ID: <002501c40b5a$c7e5b9e0$cb412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal In-Reply-To: <4.3.2.7.2.20040315114735.028073f0@flask.cisco.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Would it make sense to revise the text to also include "suggested" client-detected events, such as receiving Router Advertisements with a new prefix, that might trigger a client generated request? Other than that, the proposed text is fine. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ralph Droms Sent: Monday, March 15, 2004 11:49 AM To: dhcwg@ietf.org Subject: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item Here is proposed text for a dhc WG charter item to address renumbering stateless DHCPv6: The DHCPv6 specification in RFC3315 includes a mechanism through which clients can obtain other configuration information without obtaining an address or addresses. This mechanisms is sometimes called "stateless DHCPv6". RFC3315 includes no provision for notifying DHCPv6 clients using stateless DHCPv6 of changes in the configuration information supplied to the client. The dhc WG will assess the requirements for informing DHCPv6 clients of changes in configuration information, review alternative solutions and select a solution, and develop, review and publish a specification for the chosen solution. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 16 08:39:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00499; Tue, 16 Mar 2004 08:39:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Ema-00006V-Jv; Tue, 16 Mar 2004 08:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3EmI-000065-Eo for dhcwg@optimus.ietf.org; Tue, 16 Mar 2004 08:38:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00490 for ; Tue, 16 Mar 2004 08:38:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3EmH-00044h-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:38:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3ElP-00041G-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:37:47 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1B3Ekq-0003v9-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:37:12 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 16 Mar 2004 05:36:39 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2GDadU7000047; Tue, 16 Mar 2004 08:36:39 -0500 (EST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-72.cisco.com [10.86.242.72]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGU69442; Tue, 16 Mar 2004 08:36:38 -0500 (EST) Message-Id: <4.3.2.7.2.20040316083605.01f79270@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Mar 2004 08:36:36 -0500 To: "Bernie Volz" From: Ralph Droms Subject: RE: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item Cc: In-Reply-To: <002501c40b5a$c7e5b9e0$cb412ca1@amer.cisco.com> References: <4.3.2.7.2.20040315114735.028073f0@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Bernie - sounds like a reasonable revision. Please suggest some specific text... - Ralph At 08:30 AM 3/16/2004 -0500, Bernie Volz wrote: >Would it make sense to revise the text to also include "suggested" >client-detected events, such as receiving Router Advertisements with a >new prefix, that might trigger a client generated request? > >Other than that, the proposed text is fine. > >- Bernie > >-----Original Message----- >From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of >Ralph Droms >Sent: Monday, March 15, 2004 11:49 AM >To: dhcwg@ietf.org >Subject: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item > > >Here is proposed text for a dhc WG charter item to address renumbering >stateless DHCPv6: > >The DHCPv6 specification in RFC3315 includes a mechanism through which >clients can obtain other configuration information without obtaining an >address or addresses. This mechanisms is sometimes called "stateless >DHCPv6". RFC3315 includes no provision for notifying DHCPv6 clients >using stateless DHCPv6 of changes in the configuration information >supplied to the client. The dhc WG will assess the requirements for >informing DHCPv6 clients of changes in configuration information, review >alternative solutions and select a solution, and develop, review and >publish a specification for the chosen solution. > >- Ralph > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 16 08:43:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00661; Tue, 16 Mar 2004 08:43:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3EqT-0000LM-27; Tue, 16 Mar 2004 08:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Eq9-0000KE-Bf for dhcwg@optimus.ietf.org; Tue, 16 Mar 2004 08:42:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00639 for ; Tue, 16 Mar 2004 08:42:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Eq8-0004KC-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:42:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3EpA-0004Gt-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:41:40 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3EoV-0004Dh-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:40:59 -0500 Received: from pigeon.ecs.soton.ac.uk (pigeon [152.78.68.1]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i2GDewOr011399 for ; Tue, 16 Mar 2004 13:40:58 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA14162 for ; Tue, 16 Mar 2004 13:40:56 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i2GDeuR30484 for dhcwg@ietf.org; Tue, 16 Mar 2004 13:40:56 GMT Date: Tue, 16 Mar 2004 13:40:56 +0000 From: Tim Chown To: dhcwg@ietf.org Subject: Re: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item Message-ID: <20040316134056.GP25659@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org References: <4.3.2.7.2.20040315114735.028073f0@flask.cisco.com> <002501c40b5a$c7e5b9e0$cb412ca1@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002501c40b5a$c7e5b9e0$cb412ca1@amer.cisco.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Tue, Mar 16, 2004 at 08:30:00AM -0500, Bernie Volz wrote: > Would it make sense to revise the text to also include "suggested" > client-detected events, such as receiving Router Advertisements with a > new prefix, that might trigger a client generated request? > > Other than that, the proposed text is fine. I agree there are other "events" and scenarios to maybe consider, especially from the client perspective. I think whoever said we'll get a better picture from the DNA WG work has a good point, so we should track that closely. Basically I think we should adopt the lifetime draft as a "general fit" solution to refine (as there is currently a gap) and in parallel think about other cues and scenarios that can be described in the problem statement draft. There may then be a need for other work to emerge, for specific identified scenarios. Getting both drafts adopted will help us focus on that task. Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 16 08:50:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00981; Tue, 16 Mar 2004 08:50:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ExI-0000gZ-FB; Tue, 16 Mar 2004 08:50:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Eww-0000es-6h for dhcwg@optimus.ietf.org; Tue, 16 Mar 2004 08:49:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00946 for ; Tue, 16 Mar 2004 08:49:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Ewu-0004qT-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:49:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Ew5-0004m7-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:48:49 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B3EvD-0004dW-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:47:55 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 16 Mar 2004 05:52:03 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2GDlMK2000978; Tue, 16 Mar 2004 05:47:22 -0800 (PST) Received: from volzw2k ([161.44.65.203]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGU69966; Tue, 16 Mar 2004 08:47:20 -0500 (EST) From: "Bernie Volz" To: "'Ralph Droms'" Cc: Subject: RE: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item Date: Tue, 16 Mar 2004 08:47:20 -0500 Organization: Cisco Message-ID: <002601c40b5d$3434dc00$cb412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal In-Reply-To: <4.3.2.7.2.20040316083605.01f79270@flask.cisco.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit BTW: Isn't the statement "RFC3315 includes no provision" incorrect? There is the Reconfigure message (provided the client supports it). How about: The DHCPv6 specification in RFC3315 includes a mechanism through which clients can obtain other configuration information without obtaining an address or addresses. This mechanisms is sometimes called "stateless DHCPv6". RFC3315 includes no provision for notifying DHCPv6 clients using stateless DHCPv6 of changes in the configuration information supplied to the client or any recommendations as to when a client should obtain possibly updated information. The dhc WG will assess the requirements for informing DHCPv6 clients of changes in configuration information, review alternative solutions and select a solution, and develop, review and publish a specification for the chosen solution. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Tuesday, March 16, 2004 8:37 AM To: Bernie Volz Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item Bernie - sounds like a reasonable revision. Please suggest some specific text... - Ralph At 08:30 AM 3/16/2004 -0500, Bernie Volz wrote: >Would it make sense to revise the text to also include "suggested" >client-detected events, such as receiving Router Advertisements with a >new prefix, that might trigger a client generated request? > >Other than that, the proposed text is fine. > >- Bernie > >-----Original Message----- >From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of >Ralph Droms >Sent: Monday, March 15, 2004 11:49 AM >To: dhcwg@ietf.org >Subject: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item > > >Here is proposed text for a dhc WG charter item to address renumbering >stateless DHCPv6: > >The DHCPv6 specification in RFC3315 includes a mechanism through which >clients can obtain other configuration information without obtaining an >address or addresses. This mechanisms is sometimes called "stateless >DHCPv6". RFC3315 includes no provision for notifying DHCPv6 clients >using stateless DHCPv6 of changes in the configuration information >supplied to the client. The dhc WG will assess the requirements for >informing DHCPv6 clients of changes in configuration information, >review alternative solutions and select a solution, and develop, review >and publish a specification for the chosen solution. > >- Ralph > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 16 08:59:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01375; Tue, 16 Mar 2004 08:59:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3F5w-0001km-OT; Tue, 16 Mar 2004 08:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3F5i-0001kA-01 for dhcwg@optimus.ietf.org; Tue, 16 Mar 2004 08:58:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01349 for ; Tue, 16 Mar 2004 08:58:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3F5g-0005eJ-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:58:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3F4j-0005Xv-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:57:46 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3F3q-0005Rd-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:56:50 -0500 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i2GDukOr012067 for ; Tue, 16 Mar 2004 13:56:46 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA19912 for ; Tue, 16 Mar 2004 13:56:44 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i2GDuie30901 for dhcwg@ietf.org; Tue, 16 Mar 2004 13:56:44 GMT Date: Tue, 16 Mar 2004 13:56:44 +0000 From: Tim Chown To: dhcwg@ietf.org Subject: Re: [dhcwg] Dual-stack hosts using DHCP (was Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt) Message-ID: <20040316135644.GR25659@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org References: <4.3.2.7.2.20040315170154.02944ed8@flask.cisco.com> <002301c40b5a$c030ead0$cb412ca1@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002301c40b5a$c030ead0$cb412ca1@amer.cisco.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I think that's probably fair comment, but have not yet read all the mail thread and IETF WG minutes. I think there is an open question here for the dual-stack case. In other WGs, esp. v6ops, where such questions arise a discussion is held and then documented (e.g. for dual-stack SMTP best practice). If the result is that we decide it is a host issue, I think there is still value in documenting the issues and explaining why we came to a certain conclusion. The problem of manual configurations "clashing" with DHCP is mentioned in the draft. That exists for v4 now of course, without dual-stack. This would also allow us to document what the issues are for the host in handling the information it receives from DHCPv4 and DHCPv6 servers, if we assume best practice is to not carry IPv4 options in DHCPv6. Consistency of information seems to be a pillar in the argument; and that is a local administrative issue. There are some cases where this may not be possible, e.g. where the v4 and v6 provider is different, but these may be fringe cases. Tim On Tue, Mar 16, 2004 at 08:29:47AM -0500, Bernie Volz wrote: > Ralph, et al: > > I fully agree with your "wg_member" comments. I too believe this is a > host issue and not a DHCP protocol issue. > > - Bernie > > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of > Ralph Droms > Sent: Monday, March 15, 2004 6:06 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Dual-stack hosts using DHCP (was Re: [dhcwg] > draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt) > > > > In the interest of forward movement, I would like the WG to pick up the > conversation about dual-stack issues around the two specific drafts > draft-ietf-dhc-dhcpv6-opt-sntp-00 and > draft-ietf-dhc-dhcpv6-opt-nisconfig-05. > > > > After re-reading draft-ietf-dhc-dual-stack-00 and considering the > discussion of dual-stack issues at the WG meeting in Seoul, I find > myself in agreement with kre's analysis (included below). > > Fundamentally, there is a problem here that rightfully belongs in the > administrative or management policy in the host itself. A host may > receive configuration information from a variety of sources: PPP, RAs > (IPv6), well-known addresses for services, SLP, DNS SRV RRS, DHCP, > manual configuration, etc. The host itself may be connected to multiple > physical interfaces or multiple logical interfaces (e.g., VPN). > > I can imagine constructing multiple plausible scenarios in which the > host would use configuration information from multiple sources in > different ways. And, looking at the problem from the DHCP point of > view, there is no way for the DHCP server to determine how the host is > configured, and, therefore no way for the DHCP server to determine the > right way to deliver the configuration information to the host. > > Therefore, it seems to me the right thing to do is for the various > sources of configuration information to operate independently, allowing > the host to make any decisions about integrating the information from > the various sources. > > In the case of DHCP, I think the right thing to do is to > keep DHCPv4 and DHCPv6 separate, so the host treats information from > DHCPv4 and DHCPv6 as arriving from different sources, and makes its own > decisions about how to integrate the information. > > In the case of draft-ietf-dhc-dhcpv6-opt-sntp-00 and > draft-ietf-dhc-dhcpv6-opt-nisconfig-05, the right thing to do would be > to carry only IPv6 address in these options, leaving the decision about > how to use those addresses up to the receiving host. > > - Ralph > > At 06:11 PM 2/11/2004 +0700, Robert Elz wrote: > > Date: Tue, 10 Feb 2004 08:10:23 -0800 > > From: Harald Tveit Alvestrand > > Message-ID: <2015037.1076400623@localhost> > > > > | Apologies - just because I think you're wrong is no excuse for > > snapping at > > | you. > > > >No apologies needed, at least not for me - the message I replied to > >wasn't directed (specifically) at me. In any case, I didn't view your > >comment as in any way objectionable, just farcical... > > > > | I still think you're wrong. > > > >I fully understand your point of view. And I certainly agree, > >getting different config info from different sources is a problem, and > >one that it would be nice to have a clean solution to. > > > >But I don't think you can really expect DHCP to suddenly provide it, or > > >not in the context of the DHCPv6 NIS configuration option in any case. > > > >The problem is much broader than that - there are many more sources of > >config info than just N interfaces each providing host config > >information via DHCP. > > > >Config info is also available via well known addresses (ie: SNTP could > >be using the well known multicast address, instead of a particular > >server) or via SLP, or perhaps even DNS SRV records, or ... > > > >Any and all of that might conflict with any other of it. What a host > >should do in circumstances like those isn't easy to specify. > > > >DHCP on the other hand has been as it is now since day 1 - it gets > >config info about an interface, and throws in all kinds of host > >configuration at the same time - naturally leading to (potentially) > multiple different > >configs being received. DHCPv4 is like that, DHCPv6 isn't any > different. > >Altering that would be a major project, and NIS configuration just > >isn't important enough to embark upon that! > > > >kre > > > >ps: I haven't read today's list traffic yet (the last message I saw was > > >my own - the one full of typos). > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 16 09:00:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01486; Tue, 16 Mar 2004 09:00:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3F6w-0001sc-Rg; Tue, 16 Mar 2004 09:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3F6j-0001qX-5y for dhcwg@optimus.ietf.org; Tue, 16 Mar 2004 08:59:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01448 for ; Tue, 16 Mar 2004 08:59:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3F6h-0005lK-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:59:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3F5o-0005fl-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:58:53 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1B3F4u-0005U1-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 08:57:56 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 16 Mar 2004 06:03:41 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2GDvNU7003026; Tue, 16 Mar 2004 08:57:24 -0500 (EST) Received: from volzw2k ([161.44.65.203]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGU70635; Tue, 16 Mar 2004 08:57:23 -0500 (EST) From: "Bernie Volz" To: "'Tim Chown'" , Subject: RE: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item Date: Tue, 16 Mar 2004 08:57:23 -0500 Organization: Cisco Message-ID: <003401c40b5e$9b3e9de0$cb412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal In-Reply-To: <20040316134056.GP25659@login.ecs.soton.ac.uk> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I agree. Having the lifetime should be able to reasonably handle the planned events. Other client-side triggers, such as new prefixes in an RA or expired prefixes, should be able to handle some unplanned events. An individual server failing and being replaced at a different address will likely always be a tricky situation and is best handled by using redundancy or DNS names (instead of addresses) whenever possible. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Tim Chown Sent: Tuesday, March 16, 2004 8:41 AM To: dhcwg@ietf.org Subject: Re: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item On Tue, Mar 16, 2004 at 08:30:00AM -0500, Bernie Volz wrote: > Would it make sense to revise the text to also include "suggested" > client-detected events, such as receiving Router Advertisements with a > new prefix, that might trigger a client generated request? > > Other than that, the proposed text is fine. I agree there are other "events" and scenarios to maybe consider, especially from the client perspective. I think whoever said we'll get a better picture from the DNA WG work has a good point, so we should track that closely. Basically I think we should adopt the lifetime draft as a "general fit" solution to refine (as there is currently a gap) and in parallel think about other cues and scenarios that can be described in the problem statement draft. There may then be a need for other work to emerge, for specific identified scenarios. Getting both drafts adopted will help us focus on that task. Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 16 09:02:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01645; Tue, 16 Mar 2004 09:02:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3F8s-00020Z-AO; Tue, 16 Mar 2004 09:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3F8i-000200-55 for dhcwg@optimus.ietf.org; Tue, 16 Mar 2004 09:01:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01615 for ; Tue, 16 Mar 2004 09:01:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3F8g-0005xw-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 09:01:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3F7m-0005sb-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 09:00:54 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3F74-0005nL-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 09:00:10 -0500 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i2GE0AOr012167 for ; Tue, 16 Mar 2004 14:00:10 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA20004 for ; Tue, 16 Mar 2004 14:00:09 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i2GE09b31130 for dhcwg@ietf.org; Tue, 16 Mar 2004 14:00:09 GMT Date: Tue, 16 Mar 2004 14:00:08 +0000 From: Tim Chown To: dhcwg@ietf.org Subject: Re: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item Message-ID: <20040316140008.GS25659@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org References: <4.3.2.7.2.20040316083605.01f79270@flask.cisco.com> <002601c40b5d$3434dc00$cb412ca1@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002601c40b5d$3434dc00$cb412ca1@amer.cisco.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Tue, Mar 16, 2004 at 08:47:20AM -0500, Bernie Volz wrote: > BTW: Isn't the statement "RFC3315 includes no provision" incorrect? > There > is the Reconfigure message (provided the client supports it). Isn't that only the case though where the server knows the IP addresses of the clients to unicast the reconfigure message to? It won't know this in the stateless case because the server has no IP state for leases? > How about: > > The DHCPv6 specification in RFC3315 includes a mechanism through which > clients can obtain other configuration information without obtaining an > address or addresses. This mechanisms is sometimes called "stateless > DHCPv6". RFC3315 includes no provision for notifying DHCPv6 clients > using stateless DHCPv6 of changes in the configuration information > supplied to the client or any recommendations as to when a client should > obtain possibly updated information. The dhc WG will assess the > requirements for informing DHCPv6 clients of changes in configuration > information, review alternative solutions and select a solution, and > develop, review and publish a specification for the chosen solution. Sounds good. Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 16 09:10:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01948; Tue, 16 Mar 2004 09:10:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3FGd-0003Ic-Ag; Tue, 16 Mar 2004 09:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3FGK-000387-2M for dhcwg@optimus.ietf.org; Tue, 16 Mar 2004 09:09:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01940 for ; Tue, 16 Mar 2004 09:09:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3FGI-0006Zo-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 09:09:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3FFP-0006WB-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 09:08:47 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B3FF2-0006Rr-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 09:08:24 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 16 Mar 2004 06:12:32 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2GE7oK2018399; Tue, 16 Mar 2004 06:07:51 -0800 (PST) Received: from volzw2k ([161.44.65.203]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGU71302; Tue, 16 Mar 2004 09:07:49 -0500 (EST) From: "Bernie Volz" To: "'Tim Chown'" , Subject: RE: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item Date: Tue, 16 Mar 2004 09:07:49 -0500 Organization: Cisco Message-ID: <003f01c40b60$105ea2e0$cb412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal In-Reply-To: <20040316140008.GS25659@login.ecs.soton.ac.uk> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Yes, it all depends on the server. The DHCP server *COULD* keep a list of the addresses to which it sent Reply messages (in response to Information-Request) for those clients that support Reconfigure and unicast Reconfigures. Just because the client is using stateless, does not mean that the server needs to be. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Tim Chown Sent: Tuesday, March 16, 2004 9:00 AM To: dhcwg@ietf.org Subject: Re: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item On Tue, Mar 16, 2004 at 08:47:20AM -0500, Bernie Volz wrote: > BTW: Isn't the statement "RFC3315 includes no provision" incorrect? > There is the Reconfigure message (provided the client supports it). Isn't that only the case though where the server knows the IP addresses of the clients to unicast the reconfigure message to? It won't know this in the stateless case because the server has no IP state for leases? > How about: > > The DHCPv6 specification in RFC3315 includes a mechanism through which > clients can obtain other configuration information without obtaining an > address or addresses. This mechanisms is sometimes called "stateless > DHCPv6". RFC3315 includes no provision for notifying DHCPv6 clients > using stateless DHCPv6 of changes in the configuration information > supplied to the client or any recommendations as to when a client should > obtain possibly updated information. The dhc WG will assess the > requirements for informing DHCPv6 clients of changes in configuration > information, review alternative solutions and select a solution, and > develop, review and publish a specification for the chosen solution. Sounds good. Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 16 09:17:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02105; Tue, 16 Mar 2004 09:17:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3FNN-0003tW-5J; Tue, 16 Mar 2004 09:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3FN2-0003t1-2g for dhcwg@optimus.ietf.org; Tue, 16 Mar 2004 09:16:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02097 for ; Tue, 16 Mar 2004 09:16:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3FN0-0006zi-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 09:16:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3FM4-0006wX-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 09:15:41 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3FLD-0006tT-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 09:14:47 -0500 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i2GEEgOr012527 for ; Tue, 16 Mar 2004 14:14:42 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA20693 for ; Tue, 16 Mar 2004 14:14:39 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i2GEEdD31462 for dhcwg@ietf.org; Tue, 16 Mar 2004 14:14:39 GMT Date: Tue, 16 Mar 2004 14:14:39 +0000 From: Tim Chown To: dhcwg@ietf.org Subject: Re: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item Message-ID: <20040316141439.GW25659@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org References: <20040316140008.GS25659@login.ecs.soton.ac.uk> <003f01c40b60$105ea2e0$cb412ca1@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003f01c40b60$105ea2e0$cb412ca1@amer.cisco.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Tue, Mar 16, 2004 at 09:07:49AM -0500, Bernie Volz wrote: > Yes, it all depends on the server. The DHCP server *COULD* keep a list > of the > addresses to which it sent Reply messages (in response to > Information-Request) > for those clients that support Reconfigure and unicast Reconfigures. > > Just because the client is using stateless, does not mean that the > server needs > to be. OK, if that's the case (and I had assumed it wasn't, sorry :) then I'll update the text in the problem statement. I had assumed a key point of stateless DHCPv6 was that the server did not have to keep the state information, so was easier/cheaper to implement. I note that from Ralph's comments all DHCPv6 implementations to date (albeit not a lot of them!) are full 3315 implementations, not stateless subset ones. This may or may not remain the case... Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 16 09:43:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03136; Tue, 16 Mar 2004 09:43:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3FmX-0006Dh-5L; Tue, 16 Mar 2004 09:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3FmG-0006Bh-9g for dhcwg@optimus.ietf.org; Tue, 16 Mar 2004 09:42:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03127 for ; Tue, 16 Mar 2004 09:42:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3FmE-0001Eh-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 09:42:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3FlH-0001B2-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 09:41:43 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1B3FkP-00013W-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 09:40:49 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i2GEeGYE091545 for ; Tue, 16 Mar 2004 15:40:17 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i2GEeGlA091544 for ; Tue, 16 Mar 2004 15:40:16 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i2GEeGYC091542; Tue, 16 Mar 2004 15:40:16 +0100 (CET) Received: from cadar.office (cadar.office [10.1.1.118]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id EA43683CDA; Tue, 16 Mar 2004 15:40:15 +0100 (CET) From: Cristian Cadar Organization: NEC Europe Ltd. To: Tim Chown , dhcwg@ietf.org Subject: Re: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item Date: Tue, 16 Mar 2004 15:44:36 +0100 User-Agent: KMail/1.5.4 References: <20040316140008.GS25659@login.ecs.soton.ac.uk> <003f01c40b60$105ea2e0$cb412ca1@amer.cisco.com> <20040316141439.GW25659@login.ecs.soton.ac.uk> In-Reply-To: <20040316141439.GW25659@login.ecs.soton.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200403161544.36124.Cristian.Cadar@netlab.nec.de> X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Tim, On Tuesday 16 March 2004 15:14, Tim Chown wrote: > On Tue, Mar 16, 2004 at 09:07:49AM -0500, Bernie Volz wrote: > > Yes, it all depends on the server. The DHCP server *COULD* keep a list > > of the > > addresses to which it sent Reply messages (in response to > > Information-Request) > > for those clients that support Reconfigure and unicast Reconfigures. > > > > Just because the client is using stateless, does not mean that the > > server needs > > to be. > > OK, if that's the case (and I had assumed it wasn't, sorry :) then I'll > update the text in the problem statement. I had assumed a key point > of stateless DHCPv6 was that the server did not have to keep the state > information, so was easier/cheaper to implement. > > I note that from Ralph's comments all DHCPv6 implementations to date > (albeit not a lot of them!) are full 3315 implementations, not stateless > subset ones. This may or may not remain the case... > In my view (and implementation) stateful and stateless are completely separated I mean in stateless mode the server does not mantain any information on the IP leases since it is distributed by the RA daemon. How should the server guess the IP addresses of the clients which was provided by the RA daemon? I mean it would be a big overhead for the administrator to do so and useless . Should the server in stateless mode send Reconfigure messages to clients with unicast to force them to update their non IP address information? I think a much simpler solution would be to define for example an All-Clients IPv6 multicast address instead, the server to notify easily the clients on planned and unplanned events too. Cristian _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 16 09:51:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03554; Tue, 16 Mar 2004 09:51:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3FuH-0006oS-PT; Tue, 16 Mar 2004 09:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3FtJ-0006lC-5o for dhcwg@optimus.ietf.org; Tue, 16 Mar 2004 09:50:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03502 for ; Tue, 16 Mar 2004 09:49:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3FtH-000249-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 09:49:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3FsI-0001y0-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 09:48:59 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1B3Frs-0001rj-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 09:48:32 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 16 Mar 2004 06:54:17 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2GEm0U7012654 for ; Tue, 16 Mar 2004 09:48:00 -0500 (EST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-72.cisco.com [10.86.242.72]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGU74474; Tue, 16 Mar 2004 09:47:59 -0500 (EST) Message-Id: <4.3.2.7.2.20040316092704.029c66c8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Mar 2004 09:47:56 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item In-Reply-To: <20040316141439.GW25659@login.ecs.soton.ac.uk> References: <003f01c40b60$105ea2e0$cb412ca1@amer.cisco.com> <20040316140008.GS25659@login.ecs.soton.ac.uk> <003f01c40b60$105ea2e0$cb412ca1@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Tim, Bernie - just because the server can keep a list of clients that has contacted it doesn't mean it has to keep that list. So, the Reconfigure message would require a server with enough complexity to keep a list of clients (and security information for those clients). Most of the point of "stateless DHCPv6" is to reduce server complexity, not client complexity (note that if we had some sort of lifetime option, we require that the client keep that lifetime as "state"). Even a server that fully implements RFC 3315 might not bother to keep state for clients that use an Information-request message to obtain configuration information. If I remember correctly, that is the case with the IOS DHCPv6 server. - Ralph At 02:14 PM 3/16/2004 +0000, Tim Chown wrote: >On Tue, Mar 16, 2004 at 09:07:49AM -0500, Bernie Volz wrote: > > Yes, it all depends on the server. The DHCP server *COULD* keep a list > > of the > > addresses to which it sent Reply messages (in response to > > Information-Request) > > for those clients that support Reconfigure and unicast Reconfigures. > > > > Just because the client is using stateless, does not mean that the > > server needs > > to be. > >OK, if that's the case (and I had assumed it wasn't, sorry :) then I'll >update the text in the problem statement. I had assumed a key point >of stateless DHCPv6 was that the server did not have to keep the state >information, so was easier/cheaper to implement. > >I note that from Ralph's comments all DHCPv6 implementations to date (albeit >not a lot of them!) are full 3315 implementations, not stateless subset ones. >This may or may not remain the case... > >Tim > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 16 10:02:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03976; Tue, 16 Mar 2004 10:02:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3G4u-0000Yt-Uo; Tue, 16 Mar 2004 10:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3G4j-0000Vr-Tp for dhcwg@optimus.ietf.org; Tue, 16 Mar 2004 10:01:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03939 for ; Tue, 16 Mar 2004 10:01:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3G4h-00031X-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 10:01:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3G3k-0002wr-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 10:00:48 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3G3G-0002si-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 10:00:18 -0500 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i2GF0GOr014372 for ; Tue, 16 Mar 2004 15:00:16 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id PAA23098 for ; Tue, 16 Mar 2004 15:00:13 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i2GF0Dj00437 for dhcwg@ietf.org; Tue, 16 Mar 2004 15:00:13 GMT Date: Tue, 16 Mar 2004 15:00:13 +0000 From: Tim Chown To: dhcwg@ietf.org Subject: Re: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item Message-ID: <20040316150013.GD25659@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org References: <20040316140008.GS25659@login.ecs.soton.ac.uk> <003f01c40b60$105ea2e0$cb412ca1@amer.cisco.com> <20040316141439.GW25659@login.ecs.soton.ac.uk> <200403161544.36124.Cristian.Cadar@netlab.nec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403161544.36124.Cristian.Cadar@netlab.nec.de> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Tue, Mar 16, 2004 at 03:44:36PM +0100, Cristian Cadar wrote: > > In my view (and implementation) stateful and stateless are completely > separated I mean in stateless mode the server does not mantain any > information on the IP leases since it is distributed by the RA daemon. > How should the server guess the IP addresses of the clients which was provided > by the RA daemon? I mean it would be a big overhead for the administrator to > do so and useless . I think it would see the requests for "other configured data" and could cache the source IP addresses seen for such requests. But I agree with Ralph's summise. Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 16 10:03:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04030; Tue, 16 Mar 2004 10:03:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3G5s-0001HJ-WC; Tue, 16 Mar 2004 10:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3G5f-00019G-7Z for dhcwg@optimus.ietf.org; Tue, 16 Mar 2004 10:02:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04024 for ; Tue, 16 Mar 2004 10:02:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3G5d-00036M-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 10:02:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3G4m-00032S-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 10:01:53 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1B3G44-0002xc-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 10:01:08 -0500 Received: from [66.93.187.232] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 06D831B229A; Tue, 16 Mar 2004 08:55:30 -0600 (CST) In-Reply-To: <143131738AF93F428B4A8A9360747AD00162BF51@esebe004.ntc.nokia.com> References: <143131738AF93F428B4A8A9360747AD00162BF51@esebe004.ntc.nokia.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: From: Ted Lemon Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-lifetime-00.txt Date: Tue, 16 Mar 2004 09:01:04 -0600 To: Janne.Tuononen@nokia.com X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mar 16, 2004, at 7:03 AM, Janne.Tuononen@nokia.com wrote: > If existence of more than 1 lifetime option would be allowed, server > could group options according to their lifetimes in the Reply message. > This would not just optimize traffic between clients and servers in > certain cases, but also make the option more versatile in general. At > least in the future DHCPv6 option space assumable will contain options > that prefer different lifetimes and still server would like to put > them all into same message. We talked about this and rejected it as unnecessary. Consider if you have two groups of options, one with a lifetime of 30 seconds and one with a lifetime of a day. How is the server going to know, when it gets an information request from the client, that the client already has the values that are good for a day? It's not, so it has to send them anyway. So there's no benefit to this added complexity. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 16 19:22:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07711; Tue, 16 Mar 2004 19:22:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Oos-0005vv-BK; Tue, 16 Mar 2004 19:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3OoA-0005uw-J3 for dhcwg@optimus.ietf.org; Tue, 16 Mar 2004 19:21:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07682 for ; Tue, 16 Mar 2004 19:21:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Oo9-0001EF-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 19:21:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3OnZ-00017Q-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 19:20:41 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1B3Oma-0000zb-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 19:19:40 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i2H0J9WA009571 for ; Tue, 16 Mar 2004 16:19:09 -0800 (PST) Received: from bobo (bobo.SFBay.Sun.COM [129.146.89.81]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2H0J7Q26235; Wed, 17 Mar 2004 01:19:07 +0100 (MET) Date: Tue, 16 Mar 2004 16:19:11 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark To: dhcwg@ietf.org Cc: erik.nordmark@sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [dhcwg] DHCPv6 on link with no router? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I don't know if this has come up with before so here it goes... Suppose I want to use DHCPv6 to configure the hosts on a standadlone link i.e. a link which is not connected to any other link; hence there is no need for a router on the link. The DHCP server can hand out addresses to the hosts, but DHCPv6 doesn't appear to have a way to say "this prefix is on-link" hence, in the absense of that information in Router Advertisement messages, the hosts will not know that they are all on link. Did I get that right, or am I missing something? An obvious fix would be to have a device on the link which sends RAs with the on-link prefix specified. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 16 21:10:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13085; Tue, 16 Mar 2004 21:10:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3QVO-00052G-Ip; Tue, 16 Mar 2004 21:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3QV8-00051d-78 for dhcwg@optimus.ietf.org; Tue, 16 Mar 2004 21:09:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13074 for ; Tue, 16 Mar 2004 21:09:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3QV5-0005lK-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 21:09:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3QTp-0005fU-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 21:08:26 -0500 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3QTE-0005ZA-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 21:07:48 -0500 Received: from localhost ([130.194.13.84]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01L7U25DYN288WWWKT@vaxc.its.monash.edu.au> for dhcwg@ietf.org; Wed, 17 Mar 2004 13:02:46 +1100 Received: from blammo.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 987C039C015; Wed, 17 Mar 2004 13:02:46 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 6F6952DC013; Wed, 17 Mar 2004 13:02:46 +1100 (EST) Date: Wed, 17 Mar 2004 13:02:46 +1100 From: Greg Daley Subject: Re: [dhcwg] DHCPv6 on link with no router? To: Erik Nordmark Cc: dhcwg@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <4057B1C6.3010306@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi Erik, Erik Nordmark wrote: > I don't know if this has come up with before so here it goes... > > Suppose I want to use DHCPv6 to configure the hosts on a standadlone > link i.e. a link which is not connected to any other link; hence > there is no need for a router on the link. > > The DHCP server can hand out addresses to the hosts, but DHCPv6 doesn't > appear to have a way to say "this prefix is on-link" hence, in > the absense of that information in Router Advertisement messages, > the hosts will not know that they are all on link. > > Did I get that right, or am I missing something? > > An obvious fix would be to have a device on the link which > sends RAs with the on-link prefix specified. I'd guess that the Router Lifetime would be zero then. I can't really see a problem except the router authorization/ delegation issue. If the policy is such that hosts have tried router discovery first before undertaking DHC, then I'd guess that they've already determined that there's no other routers. Is it really a DHC issue or an ND issue? If it is, is it better to have an information option in DHCP indicating this otherwise? Greg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 16 21:56:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14788; Tue, 16 Mar 2004 21:56:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3RDt-0007f0-6B; Tue, 16 Mar 2004 21:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3RDf-0007cy-3D for dhcwg@optimus.ietf.org; Tue, 16 Mar 2004 21:55:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14691 for ; Tue, 16 Mar 2004 21:55:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3RDb-0002ZY-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 21:55:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3RCn-0002SZ-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 21:54:53 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1B3RBU-0002Ia-00 for dhcwg@ietf.org; Tue, 16 Mar 2004 21:53:32 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 16 Mar 2004 18:52:44 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2H2r0Uk029471; Tue, 16 Mar 2004 21:53:00 -0500 (EST) Received: from volzw2k (sjc-vpn4-470.cisco.com [10.21.81.214]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGV43834; Tue, 16 Mar 2004 21:52:58 -0500 (EST) From: "Bernie Volz" To: "'Erik Nordmark'" , Subject: RE: [dhcwg] DHCPv6 on link with no router? Date: Tue, 16 Mar 2004 21:52:57 -0500 Organization: Cisco Message-ID: <000c01c40bca$f4a8d0a0$5b00000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In this case, what need is there for anything but the link local addresses as there is no way to communicate with anyone off-link - no router. DHCPv6 may still be used for "other" configuration parameters if they may be useful. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Erik Nordmark Sent: Tuesday, March 16, 2004 7:19 PM To: dhcwg@ietf.org Cc: erik.nordmark@sun.com Subject: [dhcwg] DHCPv6 on link with no router? I don't know if this has come up with before so here it goes... Suppose I want to use DHCPv6 to configure the hosts on a standadlone link i.e. a link which is not connected to any other link; hence there is no need for a router on the link. The DHCP server can hand out addresses to the hosts, but DHCPv6 doesn't appear to have a way to say "this prefix is on-link" hence, in the absense of that information in Router Advertisement messages, the hosts will not know that they are all on link. Did I get that right, or am I missing something? An obvious fix would be to have a device on the link which sends RAs with the on-link prefix specified. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 17 00:42:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21489; Wed, 17 Mar 2004 00:42:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ToX-0000Yb-E7; Wed, 17 Mar 2004 00:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Tnx-0000SQ-PE for dhcwg@optimus.ietf.org; Wed, 17 Mar 2004 00:41:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21475 for ; Wed, 17 Mar 2004 00:41:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Tnl-0005JW-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 00:41:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Tmm-0005E0-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 00:40:13 -0500 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx with esmtp (Exim 4.12) id 1B3Tlu-00057I-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 00:39:19 -0500 Received: from localhost ([130.194.13.81]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01L7U90PQDRU8ZH30K@vaxc.its.monash.edu.au> for dhcwg@ietf.org; Wed, 17 Mar 2004 16:19:50 +1100 Received: from kapow.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id DFE041B000C; Wed, 17 Mar 2004 16:19:49 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id C48FF124016; Wed, 17 Mar 2004 16:19:49 +1100 (EST) Date: Wed, 17 Mar 2004 16:19:49 +1100 From: Greg Daley Subject: Re: [dhcwg] DHCPv6 on link with no router? To: Bernie Volz Cc: "'Erik Nordmark'" , dhcwg@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <4057DFF5.5080607@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <000c01c40bca$f4a8d0a0$5b00000a@amer.cisco.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi Bernie, This is just a guess: Bernie Volz wrote: > In this case, what need is there for anything but the link local > addresses as there is no way to communicate with anyone off-link - no > router. DHCPv6 may still be used for "other" configuration parameters if > they may be useful. Some applications may be interested in having long term bindings to stable non-locally scoped ip addresses for local communication (like NFS). In the case that the network is intermittently connected or at least the router is (perhaps it is a LEO satellite??) you may wish to still have some network prefix advertisement or allocation. The current set of specifications for globally unique non provider aggregatable addresses in IPv6 may meet the stability requirement for such addressing. Alternatively, global addresses sub-delegated within an organization may have this sort of application in some environments Greg > - Bernie > > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of > Erik Nordmark > Sent: Tuesday, March 16, 2004 7:19 PM > To: dhcwg@ietf.org > Cc: erik.nordmark@sun.com > Subject: [dhcwg] DHCPv6 on link with no router? > > > > I don't know if this has come up with before so here it goes... > > Suppose I want to use DHCPv6 to configure the hosts on a standadlone > link i.e. a link which is not connected to any other link; hence there > is no need for a router on the link. > > The DHCP server can hand out addresses to the hosts, but DHCPv6 doesn't > appear to have a way to say "this prefix is on-link" hence, in the > absense of that information in Router Advertisement messages, the hosts > will not know that they are all on link. > > Did I get that right, or am I missing something? > > An obvious fix would be to have a device on the link which > sends RAs with the on-link prefix specified. > > Erik > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 17 09:48:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08596; Wed, 17 Mar 2004 09:48:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3cKw-0005yx-RN; Wed, 17 Mar 2004 09:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3c6q-0004vC-3Z for dhcwg@optimus.ietf.org; Wed, 17 Mar 2004 09:33:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07982 for ; Wed, 17 Mar 2004 09:33:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3c6o-000496-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 09:33:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3c5s-00043P-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 09:32:28 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3c4w-0003su-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 09:31:30 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2HEUvh10028; Wed, 17 Mar 2004 16:30:57 +0200 Date: Wed, 17 Mar 2004 16:30:57 +0200 (EET) From: Pekka Savola To: dhcwg@ietf.org cc: vijayak@india.hp.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] comments on draft-vijay-dhc-dhcpv6-mcast-reconf-00 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi, Vijay asked me to look at this, so blame him.. comments below. substantial ----------- 1) you assume the deployment of DHCPv6 relays. DHCPv6 can work without relays as well, right? What if those do not exist? 2) Using "reconfigure" messages to relays, instead of hosts, seems a bit hackish -- but I don't know DHCPv6 spec in enough detail to know whether there might be some other ways of redistributing this information. 3) I'm not sure if I understand the applicability correctly. I guess this is useful when you're using stateless DHCPv6, use DHCPv6 relays, and would like to trigger the updates automatically, not through a manual (or otherwise automated) process? Note that I don't think the interaction with this and the host-side protocol (draft-vijay-ipv6-icmp-other-refresh-otherconf) has been explicitly spelled out? 4) the security requirements are not considered sufficiently. reconfigure messages, when used end-to-end must have been secured -- but you're using them (secured) up to the DHCPv6 relay. What about authentication from the relay to the clients? editorial --------- Abstract Stateless DHCPv6 [DHCPv6Light] is a light-weight DHCPv6 [DHCPv6] protocol in which the server manages only the service parameters like ==> no refs in the abstract!! 2. For the model suggested in this specification to work better, the DHCPv6 server SHOULD be configured with information about all relay agents in the DHCPv6 administrative domain. If it is not configured so, then it MUST learn about the relay agents in the DHCPv6 administrative domain. ==> isn't this SHOULD/MUST an operational mandate, which the implementations cannot check? If so, the uppercase keyword may not be appropriate (I think there are other such keywords elsewhere in the document as well) IPv6Sec. Thus, this is not a new constraint introduced by the ==> s/IPv6Sec/IPsec/ Note: Throughout this specification DHCPv6 means stateless DHCPv6 unless or otherwise, it is explicitly mentioned as stateful DHCPv6. ==> remove "or otherwise, it is". ==> this should probably be stated earlier, in the Introduction, maybe. The server constructs a Reconfigure message with a non-zero transaction id generated through some random number generation mechanism or through some incremental counter, but the transaction id generator mechanism should make sure that the same value is not repeated in minimal iterations. ==> what do you mean with "minimal iterations" ? DHCPv6 specification constraint of having "0" as transaction id for reconfigure message. The reason will be discussed in the following ==> use consistent style throughout the document for "transaction-id". Full Copyright Statement ==> add IPR statement around here. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 17 09:48:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08597; Wed, 17 Mar 2004 09:48:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3cKx-0005z8-9x; Wed, 17 Mar 2004 09:48:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3c6u-0004vK-8R for dhcwg@optimus.ietf.org; Wed, 17 Mar 2004 09:33:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08002 for ; Wed, 17 Mar 2004 09:33:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3c6s-00049Y-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 09:33:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3c5w-000449-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 09:32:33 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3c5k-0003yK-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 09:32:21 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2HEVme10040; Wed, 17 Mar 2004 16:31:48 +0200 Date: Wed, 17 Mar 2004 16:31:48 +0200 (EET) From: Pekka Savola To: dhcwg@ietf.org cc: vijayak@india.hp.com, , Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Subject: [dhcwg] comments on draft-vijay-ipv6-icmp-refresh-otherconf-00 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi, Vijay wanted me to look at these, so blame him.. Comments below ;-) substantial ----------- First, I note that the document talks about "administered protocol". This is interesting, if you want to have this procedure also work if you'd use a different protocol than DHCPv6 to get information (e.g., another DNS discovery method, etc.). But this little detail should probably be discussed in a couple of sentences in a new paragraph in the introduction. Second, as the other DHCPv6 reconfigure protocol (draft-vijay-dhc-dhcpv6-mcast-reconf) is limited to stateless DHCPv6 only, how does this interact with stateful DHCPv6? That is, I guess the assumption is that stateful DHCPv6 uses reconfigure messages, not these signals? Should that be made explicit? (note that the stateful DHCPv6 reconfigure messages may have different security requirements/assumptions) .... This option SHOULD NOT be sent in RAs, if O bit is unset. ==> is it worth spelling out what happens if it is sent even so? Maybe not? Once this option is enabled in RA, it SHOULD appear in the subsequent RAs for a minimum time period for better reliability. This time SHOULD be configurable in the routers. If it cannot be configurable, then RAs SHOULD contain this option till the routers are triggered to send this option with a new Transaction-id or to disable the option. ==> make it clearer what you mean by the last sentence. It could be read that if it isn't configurable, the option should be included forever, only with new Transaction-id's..? Maybe just 2-3 times to all nodes is enough? 3) In this case, either the DHCPv6 or the administrator will trigger the routers to send RAs with Refresh Other Configuration Option. The RAs can be retransmitted as per the retransmission mechanism specific to DHCPv6 for reliability. ==> DHCPv6 on its own doesn't trigger anything -- right? Administrator is making the change, which is reflected by DHCPv6 -- which might cause sending out these messages (if you use the DHCPv6 counterpart of the spec, which is not given). Maybe a bit of reword here? 9. Security Considerations ==> this section fails to mention the reason why DHCPv6 reconfigure messages must be authenticated, and why these messages should also be authenticated. That is, if you are able to get a window of opportunity for e.g., MitM for a while, being able to get all the clients to reconfigure, pointing at you, creates a new security threat (when, before, you'd have to wait if someone happened to reconfigure during that attack time window). So, being able to initiate reconfiguration at will on all the nodes of the link adds to the security threats. editorial --------- ND Support to trigger the nodes refresh the other configuration ==> uppercase the first chars, like: ND Support to Trigger the Nodes Refresh the Other Configuration (I guess ND would have to be spelled out here -- and the name made shorter, if possible.) Abstract Neighbor Discovery for IPv6 [RFC2461] provides a way by which the ==> no references in the abstract!! 1. Introduction ==> please split the looooong paragraph to 2 or more! nodes MUST ignore this option and they MUST not invoke the administered protocol to refresh their configuration. ==> s/MUST not/MUST NOT/ Security issues regarding the Neighbor Discovery protocol are being discussed in IETF SEND [SEND] WG. It can be used once it is ready. ==> SEND WG has almost concluded the work, working on WG LC issue resolution, so this statement could probably be a bit more positive than this. [SEND] J. Arkko, J. Kempf, B. Sommerfeld, B. Zill and P. Nikander, "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ipsec-01.txt, June 2003. ==> it's draft-ietf-send-ndopt now Full Copyright Statement ==> include IPR statement here as well. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 17 10:00:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09329; Wed, 17 Mar 2004 10:00:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3cWY-0006mt-N0; Wed, 17 Mar 2004 10:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3cW7-0006lu-Ix for dhcwg@optimus.ietf.org; Wed, 17 Mar 2004 09:59:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09224 for ; Wed, 17 Mar 2004 09:59:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3cW5-0007JO-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 09:59:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3cVG-0007Ch-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 09:58:43 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1B3cUQ-0006xl-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 09:57:50 -0500 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i2HEvFBv030017 for ; Wed, 17 Mar 2004 15:57:15 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i2HEvGgs021873 for dhcwg@ietf.org; Wed, 17 Mar 2004 15:57:16 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 17 Mar 2004 15:57:16 +0100 From: Stig Venaas To: dhcwg@ietf.org Subject: Re: [dhcwg] Dual-stack hosts using DHCP (was Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt) Message-ID: <20040317145716.GG21617@sverresborg.uninett.no> References: <4.3.2.7.2.20040315170154.02944ed8@flask.cisco.com> <002301c40b5a$c030ead0$cb412ca1@amer.cisco.com> <20040316135644.GR25659@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040316135644.GR25659@login.ecs.soton.ac.uk> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I agree that it may be possible to solve the issue on the host side, leaving to the host to decide what information to use. However, I still think it could be useful in some cases to learn IPv4 addresses of services from a DHCPv6 server, simply to reduce amount of signalling and not requiring DHCPv4 server. One simple, and I think pretty harmless, solution could be to use IPv4-mapped IPv6 addresses. If this is to be solved on the host, I wonder how I as an administrator can make sure the right thing happens. Can we (IETF) at least do some sort of bcp or guidelines? I think the guidelines may be just as important for implementers of DHCP clients. For the administrator to do something, there must be some knobs to turn or whatever. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 17 10:06:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09868; Wed, 17 Mar 2004 10:06:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ccO-0001WA-4l; Wed, 17 Mar 2004 10:06:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3cNJ-0006NR-G3 for dhcwg@optimus.ietf.org; Wed, 17 Mar 2004 09:50:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08776 for ; Wed, 17 Mar 2004 09:50:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3cNH-000697-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 09:50:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3cML-00060P-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 09:49:31 -0500 Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1B3cLT-0005sE-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 09:48:35 -0500 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id i2HECwMp007404 for ; Wed, 17 Mar 2004 09:12:58 -0500 (EST) Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Wed, 17 Mar 2004 09:48:25 -0500 Received: from source ([134.141.77.90]) by host ([134.141.79.124]) with SMTP; Wed, 17 Mar 2004 09:48:24 -0500 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC1.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 17 Mar 2004 09:48:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Mar 2004 09:48:23 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA017E0C9C@NHROCMBX1.ets.enterasys.com> Thread-Topic: DHCPv4 MIB review - detailed part one Thread-Index: AcPrVzYy8v5hYKD9QEGZBVYdW4UwDQLocg2wBTbshFA= From: "Harrington, David" To: "Harrington, David" , , , Cc: "Wijnen, Bert (Bert)" , , , X-OriginalArrivalTime: 17 Mar 2004 14:48:24.0653 (UTC) FILETIME=[E6638FD0:01C40C2E] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.5 X-pstn-levels: (C:98.9754 P:95.5390 R:95.9108 S:99.9000 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [dhcwg] RE: DHCPv4 MIB review - detailed part one Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, I'm doing a mib doctor review of the DHCPv4 server mib. This document is not ready for advancement, and needs through review by the WG. Part I: technical concerns Section 3.3 says "there will be differences in the counts reported by different servers." The purpose of a standard is to get all implementations to report the data the same way, so data can be compared reasonably across vendors. We don't want to standardize that implementors can count things in whatever non-interoperable manner they choose. Section 3.3.1 uses MUSTs in a manner that does not seem consistent with RFC2119 - [MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.] We standardize the format and semantics of values that pass on-the-wire between an agent and a manager; we do not dictate what a manager must do with the data it receives from the agent. In the first case, it says "a manager MUST be capable of recognizing this case." I would suggest that you tell an implementor HOW to recognize this case, without chance of error. I'm not sure it's always possible. Even with a method to do so, we should only recommend that a manager recognize this case, since we don't know whether this case is important to the purpose of the management application. A mibwalk application is a type of manager that doesn't even attempt to interpret counters; it may start and end without ever getting a counter twice. Why MUST it be capable of recognizing a counter discontinuity? Section 3.3.1, second case, says "a manager MUST discard data"; I don't believe that should be a MUST; it should be a SHOULD. The discontinuity between two GETs does not affect on-the-wire interoperability, and thus is not an absolute requirement; it only affects subsequent interpretation of the values. We should RECOMMEND that they discard the faulty data, but it is an application-implementor decision whether to do so, depending on the application needs. Therefore this should only be a SHOULD. --- MODULE IDENTITY - it is good practice to use consistent prefixes for the DEFINITIONS ::=3D BEGIN clause, the MODULE IDENTITY, and the objects in the mib. See appendix C in http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines -02.txt=20 In this MIB, they are inconsistent: DHCP-SERVER-MIB DEFINITIONS ::=3D BEGIN dhcp MODULE-IDENTITY dhcpv4ServerXXX objects These are just guidelines, but I suggest changing DHCP-SERVER-MIB to DHCPv4-SERVER-MIB, and I suggest using dhcpv4ServerMIB as the MODULE IDENTITY, to improve consistency. --- bootpXXXX objects - It is good practice (see Naming conventions in the guidelines document) to prefix all objects in the mib with the same prefix used in the module identity. This helps others not create objects with conflicting names. Have you considered having two mib modules in this document - one small one for bootp objects and the other for dhcpv4Server objects? Can bootp ever be used without dhcpv4Server? If so, they probably should be independent mib modules. If not, they should probably be named dhcpv4ServerBootpXXX for consistency. Could bootp packets be counted at the client or in transit as well as at the server? Should these be bootpServerXXX objects? bootpCountXXX - you don't need the "Count" in the name; bootpRequests/bootpInvalids/etc. would be consistent with established practice for naming counters. bootpCountInvalids might be ambiguous regarding the meaning of invalid. A standard should be written such that different implementors will not interpret the semantics differently. bootpCountDroppedUnknownClients and bootpCountDroppedNotServingSubnet seem ambiguous and overlapping. If I have not configured my server, and don't recognize the hardware address in a received packet, which counter(s) get incremented? If I do not provide service to the hardware address found in the received packet, and the packet was received from a subnet I am not configured to serve, which counter(s) do I increment? --- dhcpv4Server objects (all objects below start with dhcpv4Server prefix) SystemDescr - why is this a SHOULD and not a MUST for compliant implementations? Is there a technical reason why it may be impossible to provide this information in an implementation that complies with the standard? For comparison, sysDescr in RFC3418 calls for the hardware type, operating system, and networking software, but that information is not always available to the snmp subsystem, so the requirement can only be a SHOULD.=20 dhcpv4ServerSystemObjectID - I suspect this is a cut and paste error; "identification of the network management subsystem" is also the description of sysObjectId from the snmpMIB in RFC3418. Did you mean to duplicate that object here? If so, why? If not, what did you want here? dhcpv4CountXXX - don't need the "Count"; should use prefix of dhcpv4ServerXXX. Could these counters also be implemented on clients or transit points? (For example, I might want to monitor how much DHCP traffic is passing a given node in the network, which is neither client nor server). If so, it might be better to write one mib module with objects that can be used by either server or client, and another mib module for objects only meaningful on a server. Multiple mib modules can exist in a document. By separating the modules, an application doesn't need to import object definitions that are not important. A developer that uses a utility to generate stub code from a mib module won't need to generate stub code for a server when they are implementing a client, if you divide the mib accordingly. Counters that count multiple conditions can lead to different interpretations and overlap. In your mib, I get nervous when such OR conditions have no reference clause, while the unambiguous counters do have reference clauses; this makes me think the counter is ill-defined. Can you write CountInvalids, UnknownClient, NotServingSubnet without using an OR in the description? Can you provide a reference to ensure that there is one unambiguous reference to the condition to be counted? Wouldn't it be better to count
separately from
? Wouldn't it be better to count separately from ? Would it be better to count separately from ? --- SharedNetXXX objects SharedNetTable. The description says this table is present ONLY under certain conditions, but the Compliance statement shows this as unconditionally mandatory. See section 4.8 in the guidelines document for how to specify conditionally mandatory sections of the mib. (Note that if you make this unconditionally optional, I will probably suggest removing it from the mib altogether, since many implementations wouldn't bother implementing a fully optional section.) SharedNetName is a SnmpAdminString, a T-C defined to allow administrators to define names that would be meaningful to them. The Security Considerations treats this as a read-only mib. Who decides on the value of the names? How is the name set? Is there a reference to how one determines what a name should be? Or is it freeform, up to the operator? How is it set on a device with only an SNMP interface? Why 100 for a length? Is there a reference? LowThreshold/HighThreshold - what's an event? Is there a reference for the term event in DHCPv4? Is this an snmp notification?=20 LowThreshold/HighThreshold - must the HighThreshold be greater than the LowThreshold? Can they be equal? Can High be less than Low? Is there a reference someplace? How are the thresholds set? They're read-only, but they appear to be user-configurable values, possibly set through some backdoor mechanism like the CLI. If they are meant to be user configured, why not make the objects read-write so those who want to can use snmp SETs to modify them? You can always write two compliance clauses - one for a read-write implementation and one for read-only implementation, and allow the implementor to choose whether to support SETs. For implementations that support read-write, a disable-writes object can be used by the operation to disable the set capability for the mib (or a global one can be used to disable all sets to the agent). SNMP SETs of SNMP objects expected to be user-configured shouldn't be **prohibited** by the standard. Consistency - SharedNetTable.sharedNetName vs. Subnettable.SharedNetworkName; they should both be NetName or both be NetworkName. Cut-and-paste error? Subnet..LowThreshold ... generated for this **shared network**.=20 It would be nice if all accesible-for-notify tables were located near the notifications. Currently there are readable objects, then accessible-for-notify objects, then readable objects, then notifications in the mib. --- ServerClientTable "an optional list" that "MUST contain addresses that have not expired". Is this list optional or "an absolute requirement of the specification"? I can't tell what is expected here. non-meaningful descriptions: ClientEntry - a logical row in the ClientTable (yeah, but what does it represent?) Client (IPv4 address type) - "the IPv4 address of this entry in the ClientTable". (does that mean I can send IPv4 messages to this row in the table using this address? Or do you mean this is the IPv4 address of the client represented in this row?) dhcpv4ServerClientSubnetMask "... MUST ... Appear as a row in the dhcpSubnetTable." Where do I find the dhcpSubnetTable? I did a general review of the document through page 24; I didn't review the rest. I'll wait for the next revision, which should be thoroughly reviewed by the WG first. --- There are some typos: Section 2: "[RFC3410], Managed" s/b "[RFC3410]. Managed" --- This module should have been checked against http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines -02.txt before being sent for IESG and mib doctor review. It appears to me the document has not been checked against the guidelines: 1) The boilerplate for snmp is just slightly incorrect (punctuation),=20 2) the references for SNMP don't match the template,=20 3) the security considerations don't quite follow the security boilerplate, 4) the MODULE-IDENTITY OID assignment doesn't follow the section 4.5 guidelines,=20 5) the abstract says it is experimental, And so on. I stopped mib-doctor-checking at this point. Can the WG please check the document against the guidelines before resubmitting? Thanks, dbh > -----Original Message----- > From: Harrington, David=20 > Sent: Thursday, February 19, 2004 3:03 PM > To: 'rbhibbs@pacbell.net'; Glenn Waters (gww@nortel.com) > Cc: 'Wijnen, Bert (Bert)'; margaret.wasserman@nokia.com;=20 > 'narten@us.ibm.com'; 'rdroms@cisco.com' > Subject: FW: DHCPv4 MIB review=20 >=20 > Hi, >=20 > I don't think I've responded since you published -11- (0r the=20 > second -10-), so here you go.=20 >=20 > This is my first pass only, which includes only the result of=20 > using a diff utility to find text you changed. Since you also=20 > significantly changed the design of the mib, that will=20 > require at least another pass to understand the ramifications=20 > of your changes. Have you run all these chnages past the WG=20 > for review? >=20 > 1) I was a bit surprised to see a whole section dropped,=20 > apparently without discussion with the WG. The dropped=20 > "optional" stuff can of course be done as a separate mib later. >=20 > 2) In section 3.2.1, it states the MAC address is the layer 1=20 > physical address. The media access control (MAC) address is=20 > part of layer 2. >=20 > 3) 3.3 "Not all servers validate received packets in the same=20 > way, so there will be differences in the counts reported by=20 > different servers." I find this antithetical to a standards=20 > document. The MIB object interface should standardize what=20 > gets reported. If different servers count things differently=20 > now, then they should change to provide a consistent=20 > reporting metric. A counter that records different things on=20 > different servers is close to useless for a manager, because=20 > the values cannot be compared across vendors. For example, if=20 > an application sends an alarm to an operator if a counter=20 > exceeds some threshold, you don't want to have to write a=20 > separate rule for each vendor about what the threshold should=20 > be. You want consistency in reporting. >=20 > This also means that the counters which go into the formulae=20 > need to be consistent, or you get the GIGO effect. >=20 > 4) You dropped leasequery objects, but leasequeries are still=20 > in your total packets formula. Can you check the document for=20 > the use of any objects you eliminated, such as=20 > Dhcpv4CountLeaseQueries, please? >=20 > 5) Discontinutities. In the first case, it is hard to=20 > understand when the "point of restart" is, so an application=20 > in the process of two GETs for comparison should assume the=20 > first GET is worthless, and start over, because there is no=20 > way to quantify what occurred during the discontinuous period. >=20 > 6) 3.4 "should be able to provide" should be "SHOULD provide" >=20 > 7) Many counters were changed to Counter64. Do you really=20 > need 64-bit counters? They are much more expensive for most=20 > vendors to implement, and **critically important** they=20 > cannot be passed using SNMPv1 or SNMPv2 messages. Counter64=20 > should only be used if rollover of a 32-bit counter is=20 > possible within an hour. A 32-bit counter can handle more=20 > than 1 million counted events per second; and "one of the=20 > busiest known to exist" only got to 100 transactions per=20 > second. Counter64 is for counting things like bytes=20 > transmitted on a Gig interface. >=20 > dbh >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Barr Hibbs [mailto:rbhibbs@pacbell.net] > Sent: Monday, February 02, 2004 7:58 PM > To: dbharrington@comcast.net; gww@NortelNetworks.com > Subject: RE: DHCPv4 MIB review >=20 >=20 >=20 > Dave-- >=20 > I've updated the DHCPv4 Server MIB per your suggestions and=20 > am attaching a > copy of it to this note, prior to submitting it to the I-D editor. >=20 > The MIB has been successfully compiled by the SMILINT=20 > compiler, save for the > warnings about use of IPv4-specific address components and=20 > the lack of a > display hint for an unsigned32 object. >=20 > I appreciate your efforts to date on our behalf. >=20 > --Barr >=20 >=20 > *** included message text *** >=20 > This is an automatically generated mail message in response to a mail > message > you (or someone else who used your address) sent to > . > If you want to learn more about this mail service, send a=20 > mail message with > the "Subject: help" to . >=20 > This command (smilint 0.4.3-pre1, as of Mon Jan 12 15:21:55 2004) > has been processed to get the following results: > smilint -m -s -l 6 -i namelength-32 mailbody >=20 > mailbody:64: [5] {type-without-format} warning: type=20 > `DhcpTimeInterval' has > no format specification > mailbody:812: [5] {inetaddress-specific} warning:=20 > `InetAddress' should be > used instead of `InetAddressIPv4' > mailbody:915: [5] {inetaddress-specific} warning:=20 > `InetAddress' should be > used instead of `InetAddressIPv4' > mailbody:925: [5] {inetaddress-specific} warning:=20 > `InetAddress' should be > used instead of `InetAddressIPv4' > mailbody:1010: [5] {inetaddress-specific} warning:=20 > `InetAddress' should be > used instead of `InetAddressIPv4' > mailbody:1031: [5] {inetaddress-specific} warning:=20 > `InetAddress' should be > used instead of `InetAddressIPv4' > mailbody:1226: [5] {inetaddress-specific} warning:=20 > `InetAddress' should be > used instead of `InetAddressIPv4' > mailbody:1296: [5] {inetaddress-specific} warning:=20 > `InetAddress' should be > used instead of `InetAddressIPv4' >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 17 10:13:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10650; Wed, 17 Mar 2004 10:13:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3cj7-0003q0-06; Wed, 17 Mar 2004 10:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3cis-0003l1-0k for dhcwg@optimus.ietf.org; Wed, 17 Mar 2004 10:12:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10577 for ; Wed, 17 Mar 2004 10:12:42 -0500 (EST) From: matthew.ford@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3cip-0001GU-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 10:12:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3chr-00018g-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 10:11:43 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151] helo=i2kc04-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1B3chS-0000zF-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 10:11:18 -0500 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 17 Mar 2004 15:08:11 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 17 Mar 2004 15:08:10 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Drafts to accept as dhc WG work items Date: Wed, 17 Mar 2004 15:08:08 -0000 Message-ID: <0AAF93247C75E3408638B965DEE11A700636B568@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: [dhcwg] Drafts to accept as dhc WG work items Thread-Index: AcQKpnaD0AZmiNkGQXKYWRSRkyZrRQBiwLvA To: X-OriginalArrivalTime: 17 Mar 2004 15:08:11.0026 (UTC) FILETIME=[A985B720:01C40C31] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > Please respond with comment about accepting the following=20 > drafts as dhc WG work items: >=20 > Renumbering Requirements for Stateless DHCPv6 > > (pending dhc WG charter update) >=20 > Lifetime Option for DHCPv6 > > (pending dhc WG charter update) >=20 > IPv4 and IPv6 Dual-Stack Issues for DHCPv6 > > (pending dhc WG charter update) FWIW I support these drafts being adopted as WG work items. Mat _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 17 10:28:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11803; Wed, 17 Mar 2004 10:28:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3cxe-0006jP-72; Wed, 17 Mar 2004 10:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3cxJ-0006iW-VB for dhcwg@optimus.ietf.org; Wed, 17 Mar 2004 10:27:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11772 for ; Wed, 17 Mar 2004 10:27:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3cxH-0003AD-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 10:27:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3cwJ-000334-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 10:26:40 -0500 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx with esmtp (Exim 4.12) id 1B3cvn-0002vM-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 10:26:07 -0500 Received: from consulintel02 ([217.126.187.160]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 41-md50000000492.tmp for ; Wed, 17 Mar 2004 16:30:57 +0100 Message-ID: <33c601c40c34$a8eaa840$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <0AAF93247C75E3408638B965DEE11A700636B568@i2km41-ukdy.domain1.systemhost.net> Subject: Re: [dhcwg] Drafts to accept as dhc WG work items Date: Wed, 17 Mar 2004 16:29:36 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Wed, 17 Mar 2004 16:30:57 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: dhcwg@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I also support those I-Ds becoming WG items. ----- Original Message -----=20 From: To: Sent: Wednesday, March 17, 2004 4:08 PM Subject: RE: [dhcwg] Drafts to accept as dhc WG work items > Please respond with comment about accepting the following=20 > drafts as dhc WG work items: >=20 > Renumbering Requirements for Stateless DHCPv6 > > (pending dhc WG charter update) >=20 > Lifetime Option for DHCPv6 > > (pending dhc WG charter update) >=20 > IPv4 and IPv6 Dual-Stack Issues for DHCPv6 > > (pending dhc WG charter update) FWIW I support these drafts being adopted as WG work items. Mat _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 17 10:57:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14630; Wed, 17 Mar 2004 10:57:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3dP2-0000Nk-OD; Wed, 17 Mar 2004 10:56:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3dFe-00081H-B6 for dhcwg@optimus.ietf.org; Wed, 17 Mar 2004 10:46:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13224 for ; Wed, 17 Mar 2004 10:46:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3dFb-0005lM-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 10:46:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3dF3-0005dH-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 10:46:03 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1B3dDr-0005Oj-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 10:44:47 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2HFiCf17125 for ; Wed, 17 Mar 2004 09:44:13 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <1699VT4K>; Wed, 17 Mar 2004 16:44:11 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503DB0873@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Harrington, David" , rbhibbs@pacbell.net, gww@nortel.com, dhcwg@ietf.org Cc: "Wijnen, Bert (Bert)" , margaret.wasserman@nokia.com, narten@us.ibm.com, rdroms@cisco.com Date: Wed, 17 Mar 2004 16:44:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Ad additional reeqview of: DHCPv4 MIB, revision 10 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Let me add my comments after a (very) quick scan. David, I am not intending to step on your toes here, just trying to help and trying to point out a few more things that I could quickly spot. May make it easier for authors to include fixes in next revision. 1.Sect 3.1.1. syasy: The DHCP MIBs share a Better: The DHCP MIB modules share a There is ONE MIB that is composed of many MIB modules! This may be true for other places in the doc. 2.Sect 3.1.2 talks about a Host System Mib with ref to RFC1123??? RFC1123 does not have a MIB Did you mean RFC1213, which does not contain a Host System Mib, but contains a "systemGroup" in the SNMP MIB II. But these days it would be betetr to point to RFC3418 SNMPv20MIB that conatins systemGroup) 3.Recently the RFC-Editor has requested notation for IMPORTs as follows: SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] So that there are citattions for normative refrences. 4.Things like: ::= { mib-2 9999 } -- IANA will make official assignment Are VERY BAD. Please use: ::= { mib-2 nnn } -- IANA please assign xxxx 5.I doubt that the use of OBJECT-IDENTITY is proper here. I will check with MIB DOctor team Thanks, Bert > -----Original Message----- > From: Harrington, David [mailto:dbh@enterasys.com] > Sent: woensdag 17 maart 2004 15:48 > To: Harrington, David; rbhibbs@pacbell.net; gww@nortel.com; > dhcwg@ietf.org > Cc: Wijnen, Bert (Bert); margaret.wasserman@nokia.com; > narten@us.ibm.com; rdroms@cisco.com > Subject: RE: DHCPv4 MIB review - detailed part one > > > Hi, > > I'm doing a mib doctor review of the DHCPv4 server mib. This > document is > not ready for advancement, and needs through review by the WG. > > Part I: technical concerns > > Section 3.3 says "there will be differences in the counts reported by > different servers." The purpose of a standard is to get all > implementations to report the data the same way, so data can > be compared > reasonably across vendors. We don't want to standardize that > implementors can count things in whatever non-interoperable > manner they > choose. > > Section 3.3.1 uses MUSTs in a manner that does not seem > consistent with > RFC2119 - [MUST This word, or the terms "REQUIRED" or "SHALL", mean > that the definition is an absolute requirement of the > specification.] We > standardize the format and semantics of values that pass on-the-wire > between an agent and a manager; we do not dictate what a > manager must do > with the data it receives from the agent. > > In the first case, it says "a manager MUST be capable of recognizing > this case." I would suggest that you tell an implementor HOW to > recognize this case, without chance of error. I'm not sure it's always > possible. Even with a method to do so, we should only recommend that a > manager recognize this case, since we don't know whether this case is > important to the purpose of the management application. A mibwalk > application is a type of manager that doesn't even attempt to > interpret > counters; it may start and end without ever getting a counter > twice. Why > MUST it be capable of recognizing a counter discontinuity? > > Section 3.3.1, second case, says "a manager MUST discard > data"; I don't > believe that should be a MUST; it should be a SHOULD. The > discontinuity > between two GETs does not affect on-the-wire > interoperability, and thus > is not an absolute requirement; it only affects subsequent > interpretation of the values. We should RECOMMEND that they > discard the > faulty data, but it is an application-implementor decision > whether to do > so, depending on the application needs. Therefore this should > only be a > SHOULD. > > --- > MODULE IDENTITY - it is good practice to use consistent > prefixes for the > DEFINITIONS ::= BEGIN clause, the MODULE IDENTITY, and the objects in > the mib. See appendix C in > http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review- > guidelines > -02.txt > > In this MIB, they are inconsistent: > > DHCP-SERVER-MIB DEFINITIONS ::= BEGIN > dhcp MODULE-IDENTITY > dhcpv4ServerXXX objects > > These are just guidelines, but I suggest changing DHCP-SERVER-MIB to > DHCPv4-SERVER-MIB, and I suggest using dhcpv4ServerMIB as the MODULE > IDENTITY, to improve consistency. > > --- > bootpXXXX objects - It is good practice (see Naming conventions in the > guidelines document) to prefix all objects in the mib with the same > prefix used in the module identity. This helps others not > create objects > with conflicting names. Have you considered having two mib modules in > this document - one small one for bootp objects and the other for > dhcpv4Server objects? Can bootp ever be used without dhcpv4Server? If > so, they probably should be independent mib modules. If not, > they should > probably be named dhcpv4ServerBootpXXX for consistency. > > Could bootp packets be counted at the client or in transit as > well as at > the server? Should these be bootpServerXXX objects? > > bootpCountXXX - you don't need the "Count" in the name; > bootpRequests/bootpInvalids/etc. would be consistent with established > practice for naming counters. > > bootpCountInvalids might be ambiguous regarding the meaning > of invalid. > A standard should be written such that different implementors will not > interpret the semantics differently. > > bootpCountDroppedUnknownClients and bootpCountDroppedNotServingSubnet > seem ambiguous and overlapping. If I have not configured my > server, and > don't recognize the hardware address in a received packet, which > counter(s) get incremented? If I do not provide service to > the hardware > address found in the received packet, and the packet was > received from a > subnet I am not configured to serve, which counter(s) do I increment? > > --- > dhcpv4Server objects (all objects below start with > dhcpv4Server prefix) > > SystemDescr - why is this a SHOULD and not a MUST for compliant > implementations? Is there a technical reason why it may be > impossible to > provide this information in an implementation that complies with the > standard? For comparison, sysDescr in RFC3418 calls for the hardware > type, operating system, and networking software, but that > information is > not always available to the snmp subsystem, so the > requirement can only > be a SHOULD. > > dhcpv4ServerSystemObjectID - I suspect this is a cut and paste error; > "identification of the network management subsystem" is also the > description of sysObjectId from the snmpMIB in RFC3418. Did > you mean to > duplicate that object here? If so, why? If not, what did you > want here? > > dhcpv4CountXXX - don't need the "Count"; should use prefix of > dhcpv4ServerXXX. > > Could these counters also be implemented on clients or transit points? > (For example, I might want to monitor how much DHCP traffic > is passing a > given node in the network, which is neither client nor server). If so, > it might be better to write one mib module with objects that > can be used > by either server or client, and another mib module for objects only > meaningful on a server. Multiple mib modules can exist in a > document. By > separating the modules, an application doesn't need to import object > definitions that are not important. A developer that uses a utility to > generate stub code from a mib module won't need to generate stub code > for a server when they are implementing a client, if you > divide the mib > accordingly. > > Counters that count multiple conditions can lead to different > interpretations and overlap. In your mib, I get nervous when such OR > conditions have no reference clause, while the unambiguous counters do > have reference clauses; this makes me think the counter is > ill-defined. > Can you write CountInvalids, UnknownClient, NotServingSubnet without > using an OR in the description? Can you provide a reference to ensure > that there is one unambiguous reference to the condition to > be counted? > Wouldn't it be better to count
> separately from >
? Wouldn't it be better to count > separately from addresses on that subnet>? Would it be better to count understood> > separately from ? > > --- > SharedNetXXX objects > > SharedNetTable. The description says this table is present ONLY under > certain conditions, but the Compliance statement shows this as > unconditionally mandatory. See section 4.8 in the guidelines document > for how to specify conditionally mandatory sections of the mib. (Note > that if you make this unconditionally optional, I will > probably suggest > removing it from the mib altogether, since many > implementations wouldn't > bother implementing a fully optional section.) > > SharedNetName is a SnmpAdminString, a T-C defined to allow > administrators to define names that would be meaningful to them. The > Security Considerations treats this as a read-only mib. Who decides on > the value of the names? How is the name set? Is there a > reference to how > one determines what a name should be? Or is it freeform, up to the > operator? How is it set on a device with only an SNMP interface? > > Why 100 for a length? Is there a reference? > > LowThreshold/HighThreshold - what's an event? Is there a reference for > the term event in DHCPv4? Is this an snmp notification? > > LowThreshold/HighThreshold - must the HighThreshold be > greater than the > LowThreshold? Can they be equal? Can High be less than Low? Is there a > reference someplace? > > How are the thresholds set? They're read-only, but they appear to be > user-configurable values, possibly set through some backdoor mechanism > like the CLI. If they are meant to be user configured, why > not make the > objects read-write so those who want to can use snmp SETs to modify > them? You can always write two compliance clauses - one for a > read-write > implementation and one for read-only implementation, and allow the > implementor to choose whether to support SETs. For > implementations that > support read-write, a disable-writes object can be used by > the operation > to disable the set capability for the mib (or a global one can be used > to disable all sets to the agent). SNMP SETs of SNMP objects > expected to > be user-configured shouldn't be **prohibited** by the standard. > > Consistency - SharedNetTable.sharedNetName vs. > Subnettable.SharedNetworkName; they should both be NetName or both be > NetworkName. > > Cut-and-paste error? Subnet..LowThreshold ... generated for this > **shared network**. > > It would be nice if all accesible-for-notify tables were located near > the notifications. Currently there are readable objects, then > accessible-for-notify objects, then readable objects, then > notifications > in the mib. > > --- > ServerClientTable "an optional list" that "MUST contain addresses that > have not expired". Is this list optional or "an absolute > requirement of > the specification"? I can't tell what is expected here. > > non-meaningful descriptions: > ClientEntry - a logical row in the ClientTable (yeah, but what does it > represent?) > Client (IPv4 address type) - "the IPv4 address of this entry in the > ClientTable". (does that mean I can send IPv4 messages to this row in > the table using this address? Or do you mean this is the IPv4 > address of > the client represented in this row?) > > dhcpv4ServerClientSubnetMask "... MUST ... Appear as a row in the > dhcpSubnetTable." Where do I find the dhcpSubnetTable? > > I did a general review of the document through page 24; I > didn't review > the rest. I'll wait for the next revision, which should be thoroughly > reviewed by the WG first. > > --- > There are some typos: > Section 2: "[RFC3410], Managed" s/b "[RFC3410]. Managed" > > --- > This module should have been checked against > http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review- > guidelines > -02.txt before being sent for IESG and mib doctor review. It > appears to > me the document has not been checked against the guidelines: > > 1) The boilerplate for snmp is just slightly incorrect (punctuation), > 2) the references for SNMP don't match the template, > 3) the security considerations don't quite follow the security > boilerplate, > 4) the MODULE-IDENTITY OID assignment doesn't follow the section 4.5 > guidelines, > 5) the abstract says it is experimental, > And so on. I stopped mib-doctor-checking at this point. > > Can the WG please check the document against the guidelines before > resubmitting? > > Thanks, > dbh > > > -----Original Message----- > > From: Harrington, David > > Sent: Thursday, February 19, 2004 3:03 PM > > To: 'rbhibbs@pacbell.net'; Glenn Waters (gww@nortel.com) > > Cc: 'Wijnen, Bert (Bert)'; margaret.wasserman@nokia.com; > > 'narten@us.ibm.com'; 'rdroms@cisco.com' > > Subject: FW: DHCPv4 MIB review > > > > Hi, > > > > I don't think I've responded since you published -11- (0r the > > second -10-), so here you go. > > > > This is my first pass only, which includes only the result of > > using a diff utility to find text you changed. Since you also > > significantly changed the design of the mib, that will > > require at least another pass to understand the ramifications > > of your changes. Have you run all these chnages past the WG > > for review? > > > > 1) I was a bit surprised to see a whole section dropped, > > apparently without discussion with the WG. The dropped > > "optional" stuff can of course be done as a separate mib later. > > > > 2) In section 3.2.1, it states the MAC address is the layer 1 > > physical address. The media access control (MAC) address is > > part of layer 2. > > > > 3) 3.3 "Not all servers validate received packets in the same > > way, so there will be differences in the counts reported by > > different servers." I find this antithetical to a standards > > document. The MIB object interface should standardize what > > gets reported. If different servers count things differently > > now, then they should change to provide a consistent > > reporting metric. A counter that records different things on > > different servers is close to useless for a manager, because > > the values cannot be compared across vendors. For example, if > > an application sends an alarm to an operator if a counter > > exceeds some threshold, you don't want to have to write a > > separate rule for each vendor about what the threshold should > > be. You want consistency in reporting. > > > > This also means that the counters which go into the formulae > > need to be consistent, or you get the GIGO effect. > > > > 4) You dropped leasequery objects, but leasequeries are still > > in your total packets formula. Can you check the document for > > the use of any objects you eliminated, such as > > Dhcpv4CountLeaseQueries, please? > > > > 5) Discontinutities. In the first case, it is hard to > > understand when the "point of restart" is, so an application > > in the process of two GETs for comparison should assume the > > first GET is worthless, and start over, because there is no > > way to quantify what occurred during the discontinuous period. > > > > 6) 3.4 "should be able to provide" should be "SHOULD provide" > > > > 7) Many counters were changed to Counter64. Do you really > > need 64-bit counters? They are much more expensive for most > > vendors to implement, and **critically important** they > > cannot be passed using SNMPv1 or SNMPv2 messages. Counter64 > > should only be used if rollover of a 32-bit counter is > > possible within an hour. A 32-bit counter can handle more > > than 1 million counted events per second; and "one of the > > busiest known to exist" only got to 100 transactions per > > second. Counter64 is for counting things like bytes > > transmitted on a Gig interface. > > > > dbh > > > > > > > > > > > > -----Original Message----- > > From: Barr Hibbs [mailto:rbhibbs@pacbell.net] > > Sent: Monday, February 02, 2004 7:58 PM > > To: dbharrington@comcast.net; gww@NortelNetworks.com > > Subject: RE: DHCPv4 MIB review > > > > > > > > Dave-- > > > > I've updated the DHCPv4 Server MIB per your suggestions and > > am attaching a > > copy of it to this note, prior to submitting it to the I-D editor. > > > > The MIB has been successfully compiled by the SMILINT > > compiler, save for the > > warnings about use of IPv4-specific address components and > > the lack of a > > display hint for an unsigned32 object. > > > > I appreciate your efforts to date on our behalf. > > > > --Barr > > > > > > *** included message text *** > > > > This is an automatically generated mail message in response > to a mail > > message > > you (or someone else who used your address) sent to > > . > > If you want to learn more about this mail service, send a > > mail message with > > the "Subject: help" to . > > > > This command (smilint 0.4.3-pre1, as of Mon Jan 12 15:21:55 2004) > > has been processed to get the following results: > > smilint -m -s -l 6 -i namelength-32 mailbody > > > > mailbody:64: [5] {type-without-format} warning: type > > `DhcpTimeInterval' has > > no format specification > > mailbody:812: [5] {inetaddress-specific} warning: > > `InetAddress' should be > > used instead of `InetAddressIPv4' > > mailbody:915: [5] {inetaddress-specific} warning: > > `InetAddress' should be > > used instead of `InetAddressIPv4' > > mailbody:925: [5] {inetaddress-specific} warning: > > `InetAddress' should be > > used instead of `InetAddressIPv4' > > mailbody:1010: [5] {inetaddress-specific} warning: > > `InetAddress' should be > > used instead of `InetAddressIPv4' > > mailbody:1031: [5] {inetaddress-specific} warning: > > `InetAddress' should be > > used instead of `InetAddressIPv4' > > mailbody:1226: [5] {inetaddress-specific} warning: > > `InetAddress' should be > > used instead of `InetAddressIPv4' > > mailbody:1296: [5] {inetaddress-specific} warning: > > `InetAddress' should be > > used instead of `InetAddressIPv4' > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 17 12:40:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24683; Wed, 17 Mar 2004 12:40:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3f08-0002Iu-QC; Wed, 17 Mar 2004 12:38:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ezN-00029l-14 for dhcwg@optimus.ietf.org; Wed, 17 Mar 2004 12:37:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24507 for ; Wed, 17 Mar 2004 12:37:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3ezB-0002ib-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 12:37:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3eyM-0002c4-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 12:36:55 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1B3exx-0002TD-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 12:36:29 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i2HHZnWA000296; Wed, 17 Mar 2004 09:35:50 -0800 (PST) Received: from bobo (bobo.SFBay.Sun.COM [129.146.89.81]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2HHZlQ13036; Wed, 17 Mar 2004 18:35:48 +0100 (MET) Date: Wed, 17 Mar 2004 09:35:50 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [dhcwg] DHCPv6 on link with no router? To: Bernie Volz Cc: "'Erik Nordmark'" , dhcwg@ietf.org In-Reply-To: "Your message with ID" <000c01c40bca$f4a8d0a0$5b00000a@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > In this case, what need is there for anything but the link local > addresses as there is no way to communicate with anyone off-link - no > router. DHCPv6 may still be used for "other" configuration parameters if > they may be useful. The issue is that hosts might be multihomed and dealing with link-locals on a multihomed host complicates the applications; being able to use global address is much easier. An example configuration where this might be useful is a load balancer in front of a bunch of (web) servers, with no router (hence no direct IP path) from the Internet to the web servers. In IPv4 the web servers might have net 10 addresses and the load balancer effectively doing NAT (while this is from far the only type of LB setup there are other cases when "backend" networks use private IPv4 addresses). In some cases the web servers then talk out the "back" to a second tier of servers running application logic, NFS, or databases. And those subnets might use private IPv4 addresses as well. Thus the web servers could be multihomed to multiple IPv4 private subnets. Being able to assign addresses to the above "internal" subnets from the site's global pool will remove the management complexity of dealing with private IPv4 addresses, without having the applications on the multihomed servers have to deal with IPv6 link-local addresses. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 17 12:40:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24774; Wed, 17 Mar 2004 12:40:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3f1N-0002WA-D4; Wed, 17 Mar 2004 12:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3f12-0002Rp-W4 for dhcwg@optimus.ietf.org; Wed, 17 Mar 2004 12:39:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24579 for ; Wed, 17 Mar 2004 12:39:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3f0v-0002tQ-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 12:39:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3ezz-0002oD-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 12:38:36 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1B3ezV-0002hK-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 12:38:06 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2HHbRng020575; Wed, 17 Mar 2004 09:37:28 -0800 (PST) Received: from bobo (bobo.SFBay.Sun.COM [129.146.89.81]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2HHbPQ13170; Wed, 17 Mar 2004 18:37:25 +0100 (MET) Date: Wed, 17 Mar 2004 09:37:27 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [dhcwg] DHCPv6 on link with no router? To: greg.daley@eng.monash.edu.au Cc: Erik Nordmark , dhcwg@ietf.org In-Reply-To: "Your message with ID" <4057B1C6.3010306@eng.monash.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > I'd guess that the Router Lifetime would be zero then. Yep. > I can't really see a problem except the router authorization/ > delegation issue. If the policy is such that hosts have tried > router discovery first before undertaking DHC, then I'd guess > that they've already determined that there's no other routers. > > Is it really a DHC issue or an ND issue? Your comment raises an issue. Today ND says that when there is no router on the link assume that all destinations are local. But rfc2461bis is about to change that (since it causes some problems during transition and there doesn't seem to be any utility for that rule). Well, in the case of DHCP-configured addresses (i.e. not link local) and no router it now seems like that feature has some use. > If it is, is it better to have an information option in DHCP > indicating this otherwise? A dhcpv6 option was what I started looking for in the RFC and didn't find one. I guess we've been assuming that there are always at least one router on each link. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 17 13:12:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27176; Wed, 17 Mar 2004 13:12:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3fWL-00054s-0S; Wed, 17 Mar 2004 13:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3fVx-00050t-W8 for dhcwg@optimus.ietf.org; Wed, 17 Mar 2004 13:11:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27165 for ; Wed, 17 Mar 2004 13:11:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3fVw-0000UQ-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 13:11:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3fV0-0000M3-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 13:10:39 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1B3fU9-0000FX-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 13:09:46 -0500 Received: from [10.0.1.2] (216-80-64-108.c3-0.snb-ubr1.chi-snb.il.cable.rcn.com [216.80.64.108]) by toccata.fugue.com (Postfix) with ESMTP id 672821B2685; Wed, 17 Mar 2004 12:06:55 -0600 (CST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <426C04BE-783E-11D8-8027-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Bernie Volz From: Ted Lemon Subject: Re: [dhcwg] DHCPv6 on link with no router? Date: Wed, 17 Mar 2004 12:09:40 -0600 To: Erik Nordmark X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In the load balancer example you describe, what's the benefit in having no "router" on the network? Even if the "router" just sends out RA messages and never forwards packets, it seems like that's the right way to handle this case. I don't think a DHCPv6 client will even try to operate if it doesn't see an RA message. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 17 13:27:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27958; Wed, 17 Mar 2004 13:27:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3fks-0005k0-12; Wed, 17 Mar 2004 13:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3fkZ-0005jN-Pg for dhcwg@optimus.ietf.org; Wed, 17 Mar 2004 13:26:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27928 for ; Wed, 17 Mar 2004 13:26:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3fkX-0002kJ-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 13:26:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3fjh-0002du-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 13:25:50 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B3fjG-0002Vu-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 13:25:23 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 17 Mar 2004 10:28:34 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2HIOlaD014602; Wed, 17 Mar 2004 10:24:48 -0800 (PST) Received: from volzw2k ([161.44.65.203]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGV96141; Wed, 17 Mar 2004 13:24:46 -0500 (EST) From: "Bernie Volz" To: "'Ted Lemon'" , "'Erik Nordmark'" Cc: Subject: RE: [dhcwg] DHCPv6 on link with no router? Date: Wed, 17 Mar 2004 13:24:46 -0500 Organization: Cisco Message-ID: <000401c40c4d$2057da20$cb412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <426C04BE-783E-11D8-8027-000A95D9C74C@fugue.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Well, RFC 2462 says: "If no routers are present, stateful autoconfiguration should be invoked." So, DHCP would be used. I too agree with you Ted - a router (or something serving that function in some limited capacity) should send out RAs if that is needed. Having DHCP send prefix information just opens a can of worms - which should a host believe if it receives ones from DHCP and a router's RAs. It is best if things come from only one place. So, if you need prefixes advertised, some entity on the network must send RAs. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ted Lemon Sent: Wednesday, March 17, 2004 1:10 PM To: Erik Nordmark Cc: dhcwg@ietf.org; Bernie Volz Subject: Re: [dhcwg] DHCPv6 on link with no router? In the load balancer example you describe, what's the benefit in having no "router" on the network? Even if the "router" just sends out RA messages and never forwards packets, it seems like that's the right way to handle this case. I don't think a DHCPv6 client will even try to operate if it doesn't see an RA message. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 17 15:03:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02675; Wed, 17 Mar 2004 15:03:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3hFk-0006c2-W3; Wed, 17 Mar 2004 15:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3hFT-0005SD-2o for dhcwg@optimus.ietf.org; Wed, 17 Mar 2004 15:02:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02644 for ; Wed, 17 Mar 2004 15:02:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3hFP-0000CZ-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 15:02:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3hEP-00004m-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 15:01:38 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1B3hDP-0007fN-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 15:00:35 -0500 Received: from [10.0.1.2] (216-80-64-108.c3-0.snb-ubr1.chi-snb.il.cable.rcn.com [216.80.64.108]) by toccata.fugue.com (Postfix) with ESMTP id 27C111B2C8F; Wed, 17 Mar 2004 13:57:46 -0600 (CST) In-Reply-To: <000401c40c4d$2057da20$cb412ca1@amer.cisco.com> References: <000401c40c4d$2057da20$cb412ca1@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "" From: Ted Lemon Subject: Re: [dhcwg] DHCPv6 on link with no router? Date: Wed, 17 Mar 2004 14:00:32 -0600 To: "Bernie Volz" X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mar 17, 2004, at 12:24 PM, Bernie Volz wrote: > Well, RFC 2462 says: > > "If no routers are present, stateful autoconfiguration should be > invoked." Oops, didn't know that. Thanks for pointing it out! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 17 17:03:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10922; Wed, 17 Mar 2004 17:03:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3j6Z-00006o-2p; Wed, 17 Mar 2004 17:01:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3j5k-00004t-Bn for dhcwg@optimus.ietf.org; Wed, 17 Mar 2004 17:00:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10819 for ; Wed, 17 Mar 2004 17:00:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3j5i-00027x-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 17:00:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3j4n-00021L-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 16:59:50 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1B3j4F-0001tI-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 16:59:15 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2HLwXng025619; Wed, 17 Mar 2004 13:58:33 -0800 (PST) Received: from bobo (bobo.SFBay.Sun.COM [129.146.89.81]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2HLwVQ08930; Wed, 17 Mar 2004 22:58:31 +0100 (MET) Date: Wed, 17 Mar 2004 13:58:34 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [dhcwg] DHCPv6 on link with no router? To: Bernie Volz Cc: "'Ted Lemon'" , "'Erik Nordmark'" , dhcwg@ietf.org In-Reply-To: "Your message with ID" <000401c40c4d$2057da20$cb412ca1@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > I too agree with you Ted - a router (or something serving that function > in some limited capacity) should send out RAs if that is needed. Having > DHCP send prefix information just opens a can of worms - which should a > host believe if it receives ones from DHCP and a router's RAs. It is > best if things come from only one place. So, if you need prefixes > advertised, some entity on the network must send RAs. I think that was what I suggested in the first post on the subject. It would probably imply that the same node(s) on the link which runs DHCP (be it a relay or a server) that would send these RAs, because otherwise you need to assign a (pair of) additional nodes to send the RAs. ["A pair" to avoid a single point of failure.] This removes the need for the host to try to resolve conflicting information it would need from different sources (DHCP vs. RA), but it still requires care in configuring these nodes to make sure that the DHC addresses are consistent with the subnet prefix that is advertised in the RA. I think the latter can be an implementation issue on the DHCP agent boxes that sending the RAs. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Mar 18 04:52:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29826; Thu, 18 Mar 2004 04:52:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uC9-0007Z2-Ja; Thu, 18 Mar 2004 04:52:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uBI-0007JL-Dg for dhcwg@optimus.ietf.org; Thu, 18 Mar 2004 04:51:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29776 for ; Thu, 18 Mar 2004 04:51:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3uBF-0000Ed-00 for dhcwg@ietf.org; Thu, 18 Mar 2004 04:51:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3uAI-00008b-00 for dhcwg@ietf.org; Thu, 18 Mar 2004 04:50:15 -0500 Received: from smtp.terra.es ([213.4.129.129] helo=tfsmtp2.mail.isp) by ietf-mx with esmtp (Exim 4.12) id 1B3uA7-00001y-00 for dhcwg@ietf.org; Thu, 18 Mar 2004 04:50:03 -0500 Received: from teleline.es ([10.20.4.99]) by tfsmtp2.mail.isp (Netscape Messaging Server 4.15 tfsmtp2 Mar 14 2002 21:29:48) with ESMTP id HURNBE00.I1U for ; Thu, 18 Mar 2004 10:50:02 +0100 From: CURRO_DOMINGUEZ To: dhcwg@ietf.org Message-ID: <931ed8f8af.8f8af931ed@teleline.es> Date: Thu, 18 Mar 2004 10:50:05 +0100 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: es X-Accept-Language: es Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCPv6 server implementation Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello all Excuse me whether this is not the correct list to ask this question. Can you recommend me some free DHCPv6 Server implementation for Linux? I've been searching but I have found nothing. Thank you very much Curro _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Mar 18 05:35:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01459; Thu, 18 Mar 2004 05:35:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3urf-0001GC-NB; Thu, 18 Mar 2004 05:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uqu-0001CZ-4g for dhcwg@optimus.ietf.org; Thu, 18 Mar 2004 05:34:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01358 for ; Thu, 18 Mar 2004 05:34:12 -0500 (EST) From: matthew.ford@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3uqq-0005Q4-00 for dhcwg@ietf.org; Thu, 18 Mar 2004 05:34:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3upo-0005A5-00 for dhcwg@ietf.org; Thu, 18 Mar 2004 05:33:08 -0500 Received: from smtp5.smtp.bt.com ([217.32.164.139] helo=i2kc05-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1B3ulp-0004cs-00 for dhcwg@ietf.org; Thu, 18 Mar 2004 05:29:01 -0500 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by i2kc05-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 18 Mar 2004 10:28:32 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 18 Mar 2004 10:28:31 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] DHCPv6 server implementation Date: Thu, 18 Mar 2004 10:28:31 -0000 Message-ID: <0AAF93247C75E3408638B965DEE11A700636B8DB@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: [dhcwg] DHCPv6 server implementation Thread-Index: AcQMzuCSLboEimdRTQql7CCLwtFTzQAA8E4Q To: , X-OriginalArrivalTime: 18 Mar 2004 10:28:32.0087 (UTC) FILETIME=[C2E88E70:01C40CD3] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On=20 > Behalf Of CURRO_DOMINGUEZ > Sent: 18 March 2004 09:50 > To: dhcwg@ietf.org > Subject: [dhcwg] DHCPv6 server implementation >=20 > Hello all >=20 > Excuse me whether this is not the correct list to ask this question.=20 >=20 > Can you recommend me some free DHCPv6 Server implementation=20 > for Linux?=20 > I've been searching but I have found nothing.=20 Search harder. Googling for 'DHCPv6 Linux' turns up both http://dhcpv6.sourceforge.net/ and http://klub.com.pl/dhcpv6/ - currently down in the first 5 hits. Mat _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Mar 18 06:22:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01458; Thu, 18 Mar 2004 05:35:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ure-0001G4-Gs; Thu, 18 Mar 2004 05:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uqs-0001CT-Ma for dhcwg@optimus.ietf.org; Thu, 18 Mar 2004 05:34:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01350 for ; Thu, 18 Mar 2004 05:34:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3uqp-0005Pt-00 for dhcwg@ietf.org; Thu, 18 Mar 2004 05:34:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3upm-00059i-00 for dhcwg@ietf.org; Thu, 18 Mar 2004 05:33:07 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B3ukv-0004WG-00 for dhcwg@ietf.org; Thu, 18 Mar 2004 05:28:05 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2IARYM7000854; Thu, 18 Mar 2004 02:27:34 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-38.cisco.com [10.86.240.38]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGW56374; Thu, 18 Mar 2004 05:27:33 -0500 (EST) Message-Id: <4.3.2.7.2.20040318052202.01f6e280@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Mar 2004 05:27:30 -0500 To: CURRO_DOMINGUEZ From: Ralph Droms Subject: Re: [dhcwg] DHCPv6 server implementation Cc: dhcwg@ietf.org In-Reply-To: <931ed8f8af.8f8af931ed@teleline.es> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Christian has pointed out a couple of freely available implementations: >Subject: Re: [dhcwg] dhcv6 >From: Christian Strauf >To: narassimha reddy reddy >Cc: dhcwg@ietf.org > >There're two free implementations of DHCPv6 that you might find >interesting: > >http://dhcpv6.sourceforge.net/ > >and > >http://klub.com.pl/dhcpv6/?page=3D16 > > >Cheers, >Christian At 10:50 AM 3/18/2004 +0100, CURRO_DOMINGUEZ wrote: >Hello all > >Excuse me whether this is not the correct list to ask this question. > >Can you recommend me some free DHCPv6 Server implementation for Linux? >I've been searching but I have found nothing. > >Thank you very much > >Curro _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Mar 18 15:39:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07368; Thu, 18 Mar 2004 15:39:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B44IB-0002ox-ST; Thu, 18 Mar 2004 15:39:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B44Hu-0002m6-FD for dhcwg@optimus.ietf.org; Thu, 18 Mar 2004 15:38:46 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07232; Thu, 18 Mar 2004 15:38:43 -0500 (EST) Message-Id: <200403182038.PAA07232@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 18 Mar 2004 15:38:43 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-rapid-commit-opt-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Rapid Commit Option for DHCPv4 Author(s) : P. Kim, B. Volz, S. Park Filename : draft-ietf-dhc-rapid-commit-opt-01.txt Pages : 11 Date : 2004-3-18 This document defines a new DHCPv4 option, modeled on the DHCPv6 Rapid Commit option, for obtaining IP address and configuration information using a 2-message exchange rather than the usual 4- message exchange, expediting client configuration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-rapid-commit-opt-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-rapid-commit-opt-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-rapid-commit-opt-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-18153339.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-rapid-commit-opt-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-rapid-commit-opt-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-18153339.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Mar 19 16:07:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22774; Fri, 19 Mar 2004 16:07:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4RCn-0007Zb-Ja; Fri, 19 Mar 2004 16:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4RCR-0007Xt-RG for dhcwg@optimus.ietf.org; Fri, 19 Mar 2004 16:06:39 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22600; Fri, 19 Mar 2004 16:06:37 -0500 (EST) Message-Id: <200403192106.QAA22600@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 19 Mar 2004 16:06:37 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-rapid-commit-opt-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Rapid Commit Option for DHCPv4 Author(s) : P. Kim, B. Volz, S. Park Filename : draft-ietf-dhc-rapid-commit-opt-01.txt Pages : 11 Date : 2004-3-18 This document defines a new DHCPv4 option, modeled on the DHCPv6 Rapid Commit option, for obtaining IP address and configuration information using a 2-message exchange rather than the usual 4- message exchange, expediting client configuration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-rapid-commit-opt-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-rapid-commit-opt-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-rapid-commit-opt-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-18153339.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-rapid-commit-opt-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-rapid-commit-opt-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-18153339.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 22 11:28:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04395; Mon, 22 Mar 2004 11:28:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5SHT-0007Au-3S; Mon, 22 Mar 2004 11:28:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5SGQ-00071Y-1j for dhcwg@optimus.ietf.org; Mon, 22 Mar 2004 11:26:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04039 for ; Mon, 22 Mar 2004 11:26:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5SGG-0007jY-00 for dhcwg@ietf.org; Mon, 22 Mar 2004 11:26:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5SF6-0007X7-00 for dhcwg@ietf.org; Mon, 22 Mar 2004 11:25:36 -0500 Received: from atlrel9.hp.com ([156.153.255.214]) by ietf-mx with esmtp (Exim 4.12) id 1B5SEJ-0007Mj-00 for dhcwg@ietf.org; Mon, 22 Mar 2004 11:24:47 -0500 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by atlrel9.hp.com (Postfix) with ESMTP id 03FD01C006DB; Mon, 22 Mar 2004 11:24:39 -0500 (EST) Received: from india.hp.com (nt23056.india.hp.com [15.42.230.56]) by iconsrv6.india.hp.com (8.11.1 (PHNE_29912)/8.9.3 SMKit7.02) with ESMTP id i2MG4bA03862; Mon, 22 Mar 2004 21:34:38 +0530 (IST) Message-ID: <405F1342.4060803@india.hp.com> Date: Mon, 22 Mar 2004 21:54:34 +0530 From: Vijayabhaskar A K User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, venaas@uninett.no References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: comments on draft-vijay-ipv6-icmp-refresh-otherconf-00 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Pekka Thanks for your comments Pekka Savola wrote: >Hi, > >Vijay wanted me to look at these, so blame him.. Comments below ;-) > >substantial >----------- > >First, I note that the document talks about "administered protocol". This >is interesting, if you want to have this procedure also work if you'd use a >different protocol than DHCPv6 to get information (e.g., another DNS >discovery method, etc.). But this little detail should probably be >discussed in a couple of sentences in a new paragraph in the introduction. > > Ok fine. Will add more details >Second, as the other DHCPv6 reconfigure protocol >(draft-vijay-dhc-dhcpv6-mcast-reconf) is limited to stateless DHCPv6 only, >how does this interact with stateful DHCPv6? > Its true that multicast reconf protocol will be used only for stateless dhcpv6, but it can be extended to use in the stateful dhcpv6 also > That is, I guess the >assumption is that stateful DHCPv6 uses reconfigure messages, not these >signals? Should that be made explicit? (note that the stateful DHCPv6 >reconfigure messages may have different security requirements/assumptions) > > Thats the reason why it is not explicitly mentioned. >.... > > This option SHOULD NOT be sent in RAs, if O bit is unset. > >==> is it worth spelling out what happens if it is sent even so? Maybe not? > > Ok. Will add. > Once this option is enabled in RA, it SHOULD appear in the subsequent > RAs for a minimum time period for better reliability. This time > SHOULD be configurable in the routers. If it cannot be configurable, > then RAs SHOULD contain this option till the routers are triggered to > send this option with a new Transaction-id or to disable the option. > >==> make it clearer what you mean by the last sentence. It could be read >that if it isn't configurable, the option should be included forever, only >with new Transaction-id's..? Maybe just 2-3 times to all nodes is enough? > > Good point.. The text needs to be modified to "If it cannot be configurable, then RAs SHOULD contain this option for fixed X (may be 2-3 as you said) number of times, till a new reconfiguration is triggered (identified by new xid) or to disable the option" > 3) In this case, either the DHCPv6 or the administrator will trigger > the routers to send RAs with Refresh Other Configuration Option. > The RAs can be retransmitted as per the retransmission mechanism > specific to DHCPv6 for reliability. > >==> DHCPv6 on its own doesn't trigger anything -- right? > Correct >Administrator is >making the change, which is reflected by DHCPv6 -- which might cause sending >out these messages (if you use the DHCPv6 counterpart of the spec, which is >not given). Maybe a bit of reword here? > > Ok fine > >9. Security Considerations > >==> this section fails to mention the reason why DHCPv6 reconfigure messages >must be authenticated, and why these messages should also be authenticated. >That is, if you are able to get a window of opportunity for e.g., MitM for a >while, being able to get all the clients to reconfigure, pointing at you, >creates a new security threat (when, before, you'd have to wait if someone >happened to reconfigure during that attack time window). So, being able to >initiate reconfiguration at will on all the nodes of the link adds to the >security threats. > > Since it is explained in DHCPv6 spec, I thought its ok to not mention it. Will put some words here >editorial >--------- > > ND Support to trigger the nodes refresh the other configuration > >==> uppercase the first chars, like: > > ND Support to Trigger the Nodes Refresh the Other Configuration > >(I guess ND would have to be spelled out here -- and the name made shorter, >if possible.) > >Abstract > > Neighbor Discovery for IPv6 [RFC2461] provides a way by which the > >==> no references in the abstract!! > >1. Introduction > >==> please split the looooong paragraph to 2 or more! > > nodes MUST ignore this option and they MUST not invoke the > administered protocol to refresh their configuration. > >==> s/MUST not/MUST NOT/ > >Security issues regarding the Neighbor > Discovery protocol are being discussed in IETF SEND [SEND] WG. It > can be used once it is ready. > >==> SEND WG has almost concluded the work, working on WG LC issue >resolution, so this statement could probably be a bit more positive than >this. > > [SEND] J. Arkko, J. Kempf, B. Sommerfeld, B. Zill and P. Nikander, > "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ipsec-01.txt, > June 2003. > >==> it's draft-ietf-send-ndopt now > >Full Copyright Statement > >==> include IPR statement here as well. > > > > All the editorial comments looks fine, I will update. Thanks for your comments Vijay _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 22 15:43:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19481; Mon, 22 Mar 2004 15:43:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5WGD-0006vV-Oz; Mon, 22 Mar 2004 15:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5WFz-0006qy-4j for dhcwg@optimus.ietf.org; Mon, 22 Mar 2004 15:42:47 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19302; Mon, 22 Mar 2004 15:42:44 -0500 (EST) Message-Id: <200403222042.PAA19302@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 22 Mar 2004 15:42:44 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-leasequery-07.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Lease Query Author(s) : R. Woundy Filename : draft-ietf-dhc-leasequery-07.txt Pages : 26 Date : 2004-3-22 A DHCP server contains considerable authoritative information concerning the IP addresses it has leased to DHCP clients. Other processes and devices, many that already send and receive DHCP format packets, sometimes need to access this information. The leasequery protocol is designed to give these processes and devices a lightweight way to access information that may be critical to their operation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-leasequery-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-leasequery-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-22151203.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-leasequery-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-leasequery-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-22151203.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 22 16:10:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22589; Mon, 22 Mar 2004 16:10:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5WgM-00015r-GJ; Mon, 22 Mar 2004 16:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5WfZ-00012n-VV for dhcwg@optimus.ietf.org; Mon, 22 Mar 2004 16:09:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22296 for ; Mon, 22 Mar 2004 16:09:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5WfY-0004hM-00 for dhcwg@ietf.org; Mon, 22 Mar 2004 16:09:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5WeD-0004Qq-00 for dhcwg@ietf.org; Mon, 22 Mar 2004 16:07:51 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1B5Wcj-0003xn-00 for dhcwg@ietf.org; Mon, 22 Mar 2004 16:06:17 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 22 Mar 2004 13:13:06 -0800 X-BrightmailFiltered: true Received: from jschnizl-w2k.cisco.com (rtp-vpn2-592.cisco.com [10.82.242.80]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2ML5iUl004923 for ; Mon, 22 Mar 2004 16:05:44 -0500 (EST) Message-Id: <4.3.2.7.2.20040322160517.0242aa18@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 22 Mar 2004 16:05:42 -0500 To: dhcwg@ietf.org From: John Schnizlein In-Reply-To: <200403222042.PAA19326@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [dhcwg] Re: [Geopriv] I-D ACTION:draft-ietf-geopriv-dhcp-civil-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 03:42 PM 3/22/2004, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Geographic Location/Privacy Working Group of the IETF. > > Title : Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses > Author(s) : H. Schulzrinne > Filename : draft-ietf-geopriv-dhcp-civil-02.txt > Pages : 14 > Date : 2004-3-22 > >This document specifies a Dynamic Host Configuration Protocol (DHCPv4 >and DHCPv6) option for the civic (country, community and street) >location of the client or the DHCP server. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-civil-02.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-geopriv-dhcp-civil-02.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-geopriv-dhcp-civil-02.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2004-3-22151209.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-geopriv-dhcp-civil-02.txt > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 22 19:03:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05234; Mon, 22 Mar 2004 19:03:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ZNl-0006MH-UT; Mon, 22 Mar 2004 19:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ZMZ-0006EB-7d for dhcwg@optimus.ietf.org; Mon, 22 Mar 2004 19:01:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05119 for ; Mon, 22 Mar 2004 19:01:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ZMV-0003Hr-00 for dhcwg@ietf.org; Mon, 22 Mar 2004 19:01:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5ZLd-00039z-00 for dhcwg@ietf.org; Mon, 22 Mar 2004 19:00:50 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1B5ZKd-0002yk-00 for dhcwg@ietf.org; Mon, 22 Mar 2004 18:59:47 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 22 Mar 2004 15:57:42 -0800 X-BrightmailFiltered: true Received: from jschnizl-w2k.cisco.com (rtp-vpn2-592.cisco.com [10.82.242.80]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2MNxBUl020308; Mon, 22 Mar 2004 18:59:11 -0500 (EST) Message-Id: <4.3.2.7.2.20040322185724.023a3f00@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 22 Mar 2004 18:59:08 -0500 To: dhcwg@ietf.org From: John Schnizlein Cc: Henning Schulzrinne In-Reply-To: <405F77C4.7070704@cs.columbia.edu> References: <200403222042.PAA19326@ietf.org> <200403222042.PAA19326@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [dhcwg] Re: [Geopriv] I-D ACTION:draft-ietf-geopriv-dhcp-civil-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 06:33 PM 3/22/2004, Henning Schulzrinne wrote: >I believe that this draft incorporates the changes discussed in Seoul. The major changes are: > >- added, after consultation with Harald Alvestrand, two CAtypes for script and language, respectively; > >- added, after consultation with the WG chairs, material on use with DHCPv6; > >- added IANA considerations; > >- added a multi-lingual example; > >- added a description of the Korean administrative hierarchy. > >I think this is ready for WGLC. > >Henning > >Internet-Drafts@ietf.org wrote: > >>A New Internet-Draft is available from the on-line Internet-Drafts directories. >>This draft is a work item of the Geographic Location/Privacy Working Group of the IETF. >> Title : Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses >> Author(s) : H. Schulzrinne >> Filename : draft-ietf-geopriv-dhcp-civil-02.txt >> Pages : 14 >> Date : 2004-3-22 >> >>This document specifies a Dynamic Host Configuration Protocol (DHCPv4 >>and DHCPv6) option for the civic (country, community and street) >>location of the client or the DHCP server. >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-civil-02.txt >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 23 01:03:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22287; Tue, 23 Mar 2004 01:03:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5f08-0008AU-W1; Tue, 23 Mar 2004 01:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ezA-0007yu-Uy for dhcwg@optimus.ietf.org; Tue, 23 Mar 2004 01:02:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22210 for ; Tue, 23 Mar 2004 01:01:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ez8-0001GP-00 for dhcwg@ietf.org; Tue, 23 Mar 2004 01:01:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5eyC-000196-00 for dhcwg@ietf.org; Tue, 23 Mar 2004 01:01:01 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1B5exL-0000sH-00 for dhcwg@ietf.org; Tue, 23 Mar 2004 01:00:07 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i2N5xNWA002881; Mon, 22 Mar 2004 21:59:27 -0800 (PST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2N5xJQ16835; Tue, 23 Mar 2004 06:59:19 +0100 (MET) Date: Mon, 22 Mar 2004 21:59:20 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [dhcwg] DHCPv6 on link with no router? To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Erik Nordmark , Bernie Volz , "'Ted Lemon'" , dhcwg@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > > This removes the need for the host to try to resolve conflicting > > information it would need from different sources (DHCP vs. RA), > > but it still requires care in configuring these nodes to make sure > > that the DHC addresses are consistent with the subnet prefix that > > is advertised in the RA. I think the latter can be an implementation > > issue on the DHCP agent boxes that sending the RAs. > > (This is probably not a dhcp issue, but an ND issue) assuming we have > agreed that the "on-link by default" rule should be removed from > rfc2461bis, it should also note that we need to be careful that > the on-link prefixes may need to be advertised. > > Should we bring this to the ipv6 wg to help the 2461bis work? It might be useful to add a note about this (that prefixes need to be advertised on links that don't have routers but want to use non-link local addresses) in 2461bis - perhaps in the list of changes it could state this as an implication of changing the "on-link by default". Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 23 12:08:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12365; Tue, 23 Mar 2004 12:08:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5pNn-0002cU-1L; Tue, 23 Mar 2004 12:08:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5pNS-0002Wt-Pi for dhcwg@optimus.ietf.org; Tue, 23 Mar 2004 12:07:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12201 for ; Tue, 23 Mar 2004 12:07:43 -0500 (EST) From: rdroms@cisco.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5pNR-0001pk-00 for dhcwg@ietf.org; Tue, 23 Mar 2004 12:07:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5pKY-0001Do-00 for dhcwg@ietf.org; Tue, 23 Mar 2004 12:04:47 -0500 Received: from adsl-63-207-15-68.dsl.snfc21.pacbell.net ([63.207.15.68] helo=shade) by ietf-mx with smtp (Exim 4.12) id 1B5pFt-00008E-00 for dhcwg@ietf.org; Tue, 23 Mar 2004 11:59:58 -0500 Date: Tue, 23 Mar 2004 09:00:38 -0800 To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------tjydbmoaqplcvhewfcrn" Subject: [dhcwg] ^_^ meay-meay! Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , ----------tjydbmoaqplcvhewfcrn Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_FUNBAG.GEN in file TextDocument.zip The uncleanable file is deleted. --------------------------------------------------------- ----------tjydbmoaqplcvhewfcrn Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't bite, weah! pass: 27332 ----------tjydbmoaqplcvhewfcrn Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) TextDocument.zip is removed from here because it contains a virus. --------------------------------------------------------- ----------tjydbmoaqplcvhewfcrn-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 24 08:08:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19975; Wed, 24 Mar 2004 08:08:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B686z-0001Dn-4o; Wed, 24 Mar 2004 08:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B686N-00014H-Gs for dhcwg@optimus.ietf.org; Wed, 24 Mar 2004 08:07:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19895 for ; Wed, 24 Mar 2004 08:07:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B686M-0002Ha-00 for dhcwg@ietf.org; Wed, 24 Mar 2004 08:07:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B685R-00022y-00 for dhcwg@ietf.org; Wed, 24 Mar 2004 08:06:27 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1B684a-0001dW-00 for dhcwg@ietf.org; Wed, 24 Mar 2004 08:05:32 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 24 Mar 2004 05:12:40 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2OD4wbl018748 for ; Wed, 24 Mar 2004 08:05:00 -0500 (EST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-57.cisco.com [10.86.240.57]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHB14040; Wed, 24 Mar 2004 08:03:49 -0500 (EST) Message-Id: <4.3.2.7.2.20040324080222.023ddf88@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 24 Mar 2004 08:03:46 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_61855553==_" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] *DRAFT* minutes from WG meeting in Seoul Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --=====================_61855553==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Please review and respond with additions, corrections and deletions by Friday, 3/26. - Ralph Minutes Review of agenda. No changes. DHCP Option for Proxy Server Configuration Technical discussion; ready for WG last call? Vijay gave a short review of his draft: this option sends a list of proxy servers and ports to a client. ~8 WG members had read the draft. The chair asked about the difference between this option and existing DHCP options for carrying lists of servers; for example, WWW and NNTP. Vijay justified proxy server option because it provides port number as well as proxy server address. The WG expressed consensus for WGLC (which will be confirmed on the WG mailing list). Ted Lemon will publish editorial comments during WGLC. The Extended Remote Boot Option for DHCPv4 Technical discussion; ready for WG last call? Vijay gave a short review of his draft: this option gives a list of TFTP servers along with a list of files for each server. ~7 WG members had read the draft. There was discussion that this draft specifies multiple copies of the same option, with different semantics from those specified in RFCxxxx. Also, the list of servers needs to differentiate between IP addresses or FQDNs. There was a suggestion that the servers just be specified as IP addresses, and a suggestion that the file name be specified as a length followed by name string. Another question: what are the semantics of the list of servers in case of an error? Does the client skip to the next server, retry the file, or what? Vijay will revise the draft to eliminate requirement for sub-options and address other comments. There will be no WGLC at this time. Vendor-Identifying Vendor Options for DHCPv4 Technical discussion; ready for WG last call? The author has revised the draft based on discussion at last WG meeting. ~8 WG members have read the draft. There was one question about the vendor identifier, which was eventually recalled to be the enterprise number. There was WG consensus for WGLC (which will be confirmed on the mailing list). Node-Specific Client Identifiers for DHCPv4 Technical discussion; ready for WG last call? The author has revised the draft to simplify the generation of the DHCPv4 client identifier to match the DHCPv6 mechanism exactly. There was WG consensus for WGLC (which will be confirmed on the mailing list). Rapid Commit Option for DHCPv4 Technical discussion; ready for WG last call? The author gave a short presentation about this mechanism, which allows two message exchange in DHCPv4 (modeled on two message exchange in DHCPv6). No comments from WG. WG consensus for WGLC (which will be confirmed on the mailing list). Ted Lemon to publish editorial comments during WGLC. DHCPv6 Support for Remote Boot Technical discussion; ready for WG last call? The author gave a short presentation about this draft. This option may be impacted by dual-stack problem resolution. This option will not be affected by the multiple copies issue in the DHCPv4 option. Author to revise for editorial issues and for consistency (where possible) with similar DHCPv4 option. No WGLC at this time. Configured Tunnel End Point Option for DHCPv6 Technical discussion; ready for WG last call? The author gave a short introduction to this option. The WG expressed consensus that this option is intended for configuring routers, which is out-of-scope. The Internet Draft will be dropped as WG work item (which will be confirmed on the mailing list). Reclassifying DHCPv4 Options Technical discussion; ready for WG last call? There was no comment from WG and the WG expressed consensus for WGLC (which will be configrmed on the mailing list). DHCPv4 Support for Conf. IPv6-in-IPv4 Tunnels Accept as WG work item? The author gave a short presentation about the option. ~8 WG members had read this draft. There was some discussion of the draft on the mailing list prior to the WG meeting. The author will publish a revised draft based on those comments. The draft will be reviewed by the v6ops WG; the chair will contact the v6ops WG chairs to determine how to proceed. The WG also needs to confirm it fits in dhc WG charter. The draft was not accepted as WG work item at this time. Micro-block IP Addr. Alloc. With DHCP Proxy Server Accept as WG work item? The author gave a short presentation about the option. It fits in dhc WG charter under "address assignment". The chair will arrange for a discussion to reconcile this option with DHCPv6 prefix delegation and earlier ODAP work. The draft was not accepted as WG work item at this time. Vendor-Specific Suboption for the DHCP RAIO Ted Lemon expressed concern that this option will lead to unstandardized RAIO sub-options. The WG expressed consensus to accept as WG work item at this time (which will be confirmed on the mailing list). Renumbering Requirements for Stateless DHCPv6 This draft defines requirements for updating configuration information obtained through the Information-Request message ("stateless DHCPv6"). There was a comment that the security sectino could be clearer. The WG charter needs to be updated before the WG takes on this work. The WG expressed consensus to accept this draft as a WG work item (pending charter update; will be confirmed on miling list). Lifetime Option for DHCPv6 The author gave a short presentation about the draft. This option is a solution for the renumbering problem. The chair asked if other conditions under which a host performs an Information-Request under other conditions like getting a new prefix in an RA. The WG charter needs to be updated before the WG takes on this work. The WG expressed consensus to accept this draft as a WG work item (pending charter update; will be confirmed on miling list). Multicast Reconf. Protocol for Stateless DHCPv6 Accept as WG work item? The author gave a short presentation about the draft. This option is another solution for the renumbering problem, which is especially applicable to unplanned changes. The chair confirmed that there are two components: one that describes how hosts respond to the receonfigure message and one that describes how to trigger the router to send the reconfigure messages. Margaret Wassserman will take some concerns to the dhcwg mailing list. The WG compared this draft with the previous (lifetime option) draft; the WG consensus was that the two options are sufficiently different that they attack different problems. The WG charter needs to be updated before the WG takes on this work. The WG is very interested in this work, but ID was not accepted as WG work item. (restart at 2:05hrs in) IPv4 and IPv6 Dual-Stack Issues for DHCPv6 Stig Venaas gave an introduction to the problem based on draft-chown-dhc-dual-stack-00; this document also proposes some solutions. kre remarked that title is all wrong; the draft really discusses problem of accepting configuration from multiple interfaces. An alternative viewpoint is that information from two separate interfaces is different from having to make two answers to get all the information required. It may be possible to solve the dual-stack problem without solving the more general problem of getting information from multiple sources. The WG expressed consensus to accept this document as a WG work item (pending charter update; will confirm on mailing list). Update of dhc WG charter "Par. n" refers to the nth paragraph in the current dhc WG charter. Par. 1 - OK Par. 2 - OK Par. 3 - work in progress (security); Droms to ask design team about progress Par. 4 - work in progress; design team (Hibbs, chair) reviewing RFC 2131 The WG agreed that the list of drafts will be dropped from the charter; inactive IDs to be explicitly dropped from WG work items New charter items: * Stateless DHCpv6 renumbering () * Dual stack issues * DHCP proxy architecture - Narten to discuss with WG chair before adding to charter The WG chair will write up text for each of the three items and the WG will discuss the text on the mailing list Update on IPR issue with two drafts This agenda item was overtaken events; WG to review three new RFCs: RFC 3667, RFC 3668, RFC 3669: and discuss IPR issues on dhcwg mailing list. --=====================_61855553==_ Content-Type: text/plain; name="dhcwg-mtg-minutes.txt"; x-mac-type="42494E41"; x-mac-creator="74747874" Content-Disposition: attachment; filename="dhcwg-mtg-minutes.txt" Content-Transfer-Encoding: base64 TWludXRlcwoKUmV2aWV3IG9mIGFnZW5kYS4gIE5vIGNoYW5nZXMuCgpESENQIE9wdGlvbiBmb3Ig UHJveHkgU2VydmVyIENvbmZpZ3VyYXRpb24gCiAgPGRyYWZ0LWlldGYtZGhjLXByb3h5c2VydmVy LW9wdC0wMD4KICBUZWNobmljYWwgZGlzY3Vzc2lvbjsgcmVhZHkgZm9yIFdHIGxhc3QgY2FsbD8K CiAgVmlqYXkgZ2F2ZSBhIHNob3J0IHJldmlldyBvZiBoaXMgZHJhZnQ6IHRoaXMgb3B0aW9uIHNl bmRzIGEgbGlzdCBvZgogIHByb3h5IHNlcnZlcnMgYW5kIHBvcnRzIHRvIGEgY2xpZW50LiAgfjgg V0cgbWVtYmVycyBoYWQgcmVhZCB0aGUKICBkcmFmdC4gIFRoZSBjaGFpciBhc2tlZCBhYm91dCB0 aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoaXMgb3B0aW9uIGFuZAogIGV4aXN0aW5nIERIQ1Agb3B0 aW9ucyBmb3IgY2FycnlpbmcgbGlzdHMgb2Ygc2VydmVyczsgZm9yIGV4YW1wbGUsCiAgV1dXIGFu ZCBOTlRQLiAgVmlqYXkganVzdGlmaWVkIHByb3h5IHNlcnZlciBvcHRpb24gYmVjYXVzZSBpdAog IHByb3ZpZGVzIHBvcnQgbnVtYmVyIGFzIHdlbGwgYXMgcHJveHkgc2VydmVyIGFkZHJlc3MuICBU aGUgV0cKICBleHByZXNzZWQgY29uc2Vuc3VzIGZvciBXR0xDICh3aGljaCB3aWxsIGJlIGNvbmZp cm1lZCBvbiB0aGUgV0cKICBtYWlsaW5nIGxpc3QpLiAgVGVkIExlbW9uIHdpbGwgcHVibGlzaCBl ZGl0b3JpYWwgY29tbWVudHMgZHVyaW5nCiAgV0dMQy4KCgpUaGUgRXh0ZW5kZWQgUmVtb3RlIEJv b3QgT3B0aW9uIGZvciBESENQdjQKICA8ZHJhZnQtaWV0Zi1kaGMtb3B0LWV4dHJib290LTAwPgog IFRlY2huaWNhbCBkaXNjdXNzaW9uOyByZWFkeSBmb3IgV0cgbGFzdCBjYWxsPwoKICBWaWpheSBn YXZlIGEgc2hvcnQgcmV2aWV3IG9mIGhpcyBkcmFmdDogdGhpcyBvcHRpb24gZ2l2ZXMgYSBsaXN0 IG9mCiAgVEZUUCBzZXJ2ZXJzIGFsb25nIHdpdGggYSBsaXN0IG9mIGZpbGVzIGZvciBlYWNoIHNl cnZlci4gIH43IFdHCiAgbWVtYmVycyBoYWQgcmVhZCB0aGUgZHJhZnQuICBUaGVyZSB3YXMgZGlz Y3Vzc2lvbiB0aGF0IHRoaXMgZHJhZnQKICBzcGVjaWZpZXMgbXVsdGlwbGUgY29waWVzIG9mIHRo ZSBzYW1lIG9wdGlvbiwgd2l0aCBkaWZmZXJlbnQKICBzZW1hbnRpY3MgZnJvbSB0aG9zZSBzcGVj aWZpZWQgaW4gUkZDeHh4eC4gIEFsc28sIHRoZSBsaXN0IG9mCiAgc2VydmVycyBuZWVkcyB0byBk aWZmZXJlbnRpYXRlIGJldHdlZW4gSVAgYWRkcmVzc2VzIG9yIEZRRE5zLiAgVGhlcmUKICB3YXMg YSBzdWdnZXN0aW9uIHRoYXQgdGhlIHNlcnZlcnMganVzdCBiZSBzcGVjaWZpZWQgYXMgSVAgYWRk cmVzc2VzLAogIGFuZCBhIHN1Z2dlc3Rpb24gdGhhdCB0aGUgZmlsZSBuYW1lIGJlIHNwZWNpZmll ZCBhcyBhIGxlbmd0aAogIGZvbGxvd2VkIGJ5IG5hbWUgc3RyaW5nLiAgQW5vdGhlciBxdWVzdGlv bjogd2hhdCBhcmUgdGhlIHNlbWFudGljcwogIG9mIHRoZSBsaXN0IG9mIHNlcnZlcnMgaW4gY2Fz ZSBvZiBhbiBlcnJvcj8gIERvZXMgdGhlIGNsaWVudCBza2lwIHRvCiAgdGhlIG5leHQgc2VydmVy LCByZXRyeSB0aGUgZmlsZSwgb3Igd2hhdD8gIFZpamF5IHdpbGwgcmV2aXNlIHRoZQogIGRyYWZ0 IHRvIGVsaW1pbmF0ZSByZXF1aXJlbWVudCBmb3Igc3ViLW9wdGlvbnMgYW5kIGFkZHJlc3Mgb3Ro ZXIKICBjb21tZW50cy4gIFRoZXJlIHdpbGwgYmUgbm8gV0dMQyBhdCB0aGlzIHRpbWUuCgoKVmVu ZG9yLUlkZW50aWZ5aW5nIFZlbmRvciBPcHRpb25zIGZvciBESENQdjQKICA8ZHJhZnQtaWV0Zi1k aGMtdmVuZG9yLTAxPgogIFRlY2huaWNhbCBkaXNjdXNzaW9uOyByZWFkeSBmb3IgV0cgbGFzdCBj YWxsPwoKICBUaGUgYXV0aG9yIGhhcyByZXZpc2VkIHRoZSBkcmFmdCBiYXNlZCBvbiBkaXNjdXNz aW9uIGF0IGxhc3QgV0cKICBtZWV0aW5nLiAgfjggV0cgbWVtYmVycyBoYXZlIHJlYWQgdGhlIGRy YWZ0LiAgVGhlcmUgd2FzIG9uZSBxdWVzdGlvbgogIGFib3V0IHRoZSB2ZW5kb3IgaWRlbnRpZmll ciwgd2hpY2ggd2FzIGV2ZW50dWFsbHkgcmVjYWxsZWQgdG8gYmUgdGhlCiAgZW50ZXJwcmlzZSBu dW1iZXIuICBUaGVyZSB3YXMgV0cgY29uc2Vuc3VzIGZvciBXR0xDICh3aGljaCB3aWxsIGJlCiAg Y29uZmlybWVkIG9uIHRoZSBtYWlsaW5nIGxpc3QpLgoKCk5vZGUtU3BlY2lmaWMgQ2xpZW50IElk ZW50aWZpZXJzIGZvciBESENQdjQKICA8ZHJhZnQtaWV0Zi1kaGMtMzMxNWlkLWZvci12NC0wMT4K ICBUZWNobmljYWwgZGlzY3Vzc2lvbjsgcmVhZHkgZm9yIFdHIGxhc3QgY2FsbD8KCiAgVGhlIGF1 dGhvciBoYXMgcmV2aXNlZCB0aGUgZHJhZnQgdG8gc2ltcGxpZnkgdGhlIGdlbmVyYXRpb24gb2Yg dGhlCiAgREhDUHY0IGNsaWVudCBpZGVudGlmaWVyIHRvIG1hdGNoIHRoZSBESENQdjYgbWVjaGFu aXNtIGV4YWN0bHkuCiAgVGhlcmUgd2FzIFdHIGNvbnNlbnN1cyBmb3IgV0dMQyAod2hpY2ggd2ls bCBiZSBjb25maXJtZWQgb24gdGhlCiAgbWFpbGluZyBsaXN0KS4KCgpSYXBpZCBDb21taXQgT3B0 aW9uIGZvciBESENQdjQKICA8ZHJhZnQtaWV0Zi1kaGMtcmFwaWQtY29tbWl0LW9wdC0wMD4KICBU ZWNobmljYWwgZGlzY3Vzc2lvbjsgcmVhZHkgZm9yIFdHIGxhc3QgY2FsbD8KCiAgVGhlIGF1dGhv ciBnYXZlIGEgc2hvcnQgcHJlc2VudGF0aW9uIGFib3V0IHRoaXMgbWVjaGFuaXNtLCB3aGljaAog IGFsbG93cyB0d28gbWVzc2FnZSBleGNoYW5nZSBpbiBESENQdjQgKG1vZGVsZWQgb24gdHdvIG1l c3NhZ2UKICBleGNoYW5nZSBpbiBESENQdjYpLiAgTm8gY29tbWVudHMgZnJvbSBXRy4gIFdHIGNv bnNlbnN1cyBmb3IgV0dMQwogICh3aGljaCB3aWxsIGJlIGNvbmZpcm1lZCBvbiB0aGUgbWFpbGlu ZyBsaXN0KS4gIFRlZCBMZW1vbiB0byBwdWJsaXNoCiAgZWRpdG9yaWFsIGNvbW1lbnRzIGR1cmlu ZyBXR0xDLgoKCkRIQ1B2NiBTdXBwb3J0IGZvciBSZW1vdGUgQm9vdAogIDxkcmFmdC1pZXRmLWRo Yy1kaGNwdjYtb3B0LXJib290LTAwPgogIFRlY2huaWNhbCBkaXNjdXNzaW9uOyByZWFkeSBmb3Ig V0cgbGFzdCBjYWxsPwoKICBUaGUgYXV0aG9yIGdhdmUgYSBzaG9ydCBwcmVzZW50YXRpb24gYWJv dXQgdGhpcyBkcmFmdC4gIFRoaXMgb3B0aW9uCiAgbWF5IGJlIGltcGFjdGVkIGJ5IGR1YWwtc3Rh Y2sgcHJvYmxlbSByZXNvbHV0aW9uLiAgVGhpcyBvcHRpb24gd2lsbAogIG5vdCBiZSBhZmZlY3Rl ZCBieSB0aGUgbXVsdGlwbGUgY29waWVzIGlzc3VlIGluIHRoZSBESENQdjQgb3B0aW9uLgogIEF1 dGhvciB0byByZXZpc2UgZm9yIGVkaXRvcmlhbCBpc3N1ZXMgYW5kIGZvciBjb25zaXN0ZW5jeSAo d2hlcmUKICBwb3NzaWJsZSkgd2l0aCBzaW1pbGFyIERIQ1B2NCBvcHRpb24uICBObyBXR0xDIGF0 IHRoaXMgdGltZS4KCgpDb25maWd1cmVkIFR1bm5lbCBFbmQgUG9pbnQgT3B0aW9uIGZvciBESENQ djYKICA8ZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LWN0ZXAtb3B0LTAxPgogIFRlY2huaWNhbCBkaXNj dXNzaW9uOyByZWFkeSBmb3IgV0cgbGFzdCBjYWxsPwoKICBUaGUgYXV0aG9yIGdhdmUgYSBzaG9y dCBpbnRyb2R1Y3Rpb24gdG8gdGhpcyBvcHRpb24uICBUaGUgV0cKICBleHByZXNzZWQgY29uc2Vu c3VzIHRoYXQgdGhpcyBvcHRpb24gaXMgaW50ZW5kZWQgZm9yIGNvbmZpZ3VyaW5nCiAgcm91dGVy cywgd2hpY2ggaXMgb3V0LW9mLXNjb3BlLiAgVGhlIEludGVybmV0IERyYWZ0IHdpbGwgYmUgZHJv cHBlZAogIGFzIFdHIHdvcmsgaXRlbSAod2hpY2ggd2lsbCBiZSBjb25maXJtZWQgb24gdGhlIG1h aWxpbmcgbGlzdCkuCgoKUmVjbGFzc2lmeWluZyBESENQdjQgT3B0aW9ucwogIDxkcmFmdC1pZXRm LWRoYy1yZWNsYXNzaWZ5LW9wdGlvbnMtMDA+CiAgVGVjaG5pY2FsIGRpc2N1c3Npb247IHJlYWR5 IGZvciBXRyBsYXN0IGNhbGw/CgogIFRoZXJlIHdhcyBubyBjb21tZW50IGZyb20gV0cgYW5kIHRo ZSBXRyBleHByZXNzZWQgY29uc2Vuc3VzIGZvcgogIFdHTEMgKHdoaWNoIHdpbGwgYmUgY29uZmln cm1lZCBvbiB0aGUgbWFpbGluZyBsaXN0KS4KCgpESENQdjQgU3VwcG9ydCBmb3IgQ29uZi4gSVB2 Ni1pbi1JUHY0IFR1bm5lbHMKICA8ZHJhZnQtZGFuaWVsLWRoYy1pcHY2aW40LXR1bm5lbHMtMDA+ CiAgQWNjZXB0IGFzIFdHIHdvcmsgaXRlbT8KCiAgVGhlIGF1dGhvciBnYXZlIGEgc2hvcnQgcHJl c2VudGF0aW9uIGFib3V0IHRoZSBvcHRpb24uICB+OCBXRwogIG1lbWJlcnMgaGFkIHJlYWQgdGhp cyBkcmFmdC4gIFRoZXJlIHdhcyBzb21lIGRpc2N1c3Npb24gb2YgdGhlIGRyYWZ0CiAgb24gdGhl IG1haWxpbmcgbGlzdCBwcmlvciB0byB0aGUgV0cgbWVldGluZy4gIFRoZSBhdXRob3Igd2lsbAog IHB1Ymxpc2ggYSByZXZpc2VkIGRyYWZ0IGJhc2VkIG9uIHRob3NlIGNvbW1lbnRzLiBUaGUgZHJh ZnQgd2lsbCBiZQogIHJldmlld2VkIGJ5IHRoZSB2Nm9wcyBXRzsgdGhlIGNoYWlyIHdpbGwgY29u dGFjdCB0aGUgdjZvcHMgV0cgY2hhaXJzCiAgdG8gZGV0ZXJtaW5lIGhvdyB0byBwcm9jZWVkLiAg VGhlIFdHIGFsc28gbmVlZHMgdG8gY29uZmlybSBpdCBmaXRzCiAgaW4gZGhjIFdHIGNoYXJ0ZXIu ICBUaGUgZHJhZnQgd2FzIG5vdCBhY2NlcHRlZCBhcyBXRyB3b3JrIGl0ZW0gYXQKICB0aGlzIHRp bWUuCgoKTWljcm8tYmxvY2sgSVAgQWRkci4gQWxsb2MuIFdpdGggREhDUCBQcm94eSBTZXJ2ZXIK ICA8ZHJhZnQtc2hlbi1kaGMtYmxvY2stYWxsb2MtMDE+CiAgQWNjZXB0IGFzIFdHIHdvcmsgaXRl bT8KCiAgVGhlIGF1dGhvciBnYXZlIGEgc2hvcnQgcHJlc2VudGF0aW9uIGFib3V0IHRoZSBvcHRp b24uICBJdCBmaXRzIGluCiAgZGhjIFdHIGNoYXJ0ZXIgdW5kZXIgImFkZHJlc3MgYXNzaWdubWVu dCIuICBUaGUgY2hhaXIgd2lsbCBhcnJhbmdlCiAgZm9yIGEgZGlzY3Vzc2lvbiB0byByZWNvbmNp bGUgdGhpcyBvcHRpb24gd2l0aCBESENQdjYgcHJlZml4CiAgZGVsZWdhdGlvbiBhbmQgZWFybGll ciBPREFQIHdvcmsuICBUaGUgZHJhZnQgd2FzIG5vdCBhY2NlcHRlZCBhcyBXRwogIHdvcmsgaXRl bSBhdCB0aGlzIHRpbWUuCgoKVmVuZG9yLVNwZWNpZmljIFN1Ym9wdGlvbiBmb3IgdGhlIERIQ1Ag UkFJTwogIDxkcmFmdC1zdGFwcC1kaGMtdmVuZG9yLXN1Ym9wdGlvbi0wMD4KCiAgVGVkIExlbW9u IGV4cHJlc3NlZCBjb25jZXJuIHRoYXQgdGhpcyBvcHRpb24gd2lsbCBsZWFkIHRvCiAgdW5zdGFu ZGFyZGl6ZWQgUkFJTyBzdWItb3B0aW9ucy4gIFRoZSBXRyBleHByZXNzZWQgY29uc2Vuc3VzIHRv CiAgYWNjZXB0IGFzIFdHIHdvcmsgaXRlbSBhdCB0aGlzIHRpbWUgKHdoaWNoIHdpbGwgYmUgY29u ZmlybWVkIG9uIHRoZQogIG1haWxpbmcgbGlzdCkuCgoKUmVudW1iZXJpbmcgUmVxdWlyZW1lbnRz IGZvciBTdGF0ZWxlc3MgREhDUHY2CiAgPGRyYWZ0LWNob3duLWRoYy1zdGF0ZWxlc3MtZGhjcHY2 LXJlbnVtYmVyaW5nLTAwPgoKICBUaGlzIGRyYWZ0IGRlZmluZXMgcmVxdWlyZW1lbnRzIGZvciB1 cGRhdGluZyBjb25maWd1cmF0aW9uCiAgaW5mb3JtYXRpb24gb2J0YWluZWQgdGhyb3VnaCB0aGUg SW5mb3JtYXRpb24tUmVxdWVzdCBtZXNzYWdlCiAgKCJzdGF0ZWxlc3MgREhDUHY2IikuICBUaGVy ZSB3YXMgYSBjb21tZW50IHRoYXQgdGhlIHNlY3VyaXR5IHNlY3Rpbm8KICBjb3VsZCBiZSBjbGVh cmVyLiAgVGhlIFdHIGNoYXJ0ZXIgbmVlZHMgdG8gYmUgdXBkYXRlZCBiZWZvcmUgdGhlIFdHCiAg dGFrZXMgb24gdGhpcyB3b3JrLiAgVGhlIFdHIGV4cHJlc3NlZCBjb25zZW5zdXMgdG8gYWNjZXB0 IHRoaXMgZHJhZnQKICBhcyBhIFdHIHdvcmsgaXRlbSAocGVuZGluZyBjaGFydGVyIHVwZGF0ZTsg d2lsbCBiZSBjb25maXJtZWQgb24KICBtaWxpbmcgbGlzdCkuCgoKTGlmZXRpbWUgT3B0aW9uIGZv ciBESENQdjYKICA8ZHJhZnQtdmVuYWFzLWRoYy1saWZldGltZS0wMT4KCiAgVGhlIGF1dGhvciBn YXZlIGEgc2hvcnQgcHJlc2VudGF0aW9uIGFib3V0IHRoZSBkcmFmdC4gIFRoaXMgb3B0aW9uCiAg aXMgYSBzb2x1dGlvbiBmb3IgdGhlIHJlbnVtYmVyaW5nIHByb2JsZW0uIFRoZSBjaGFpciBhc2tl ZCBpZiBvdGhlcgogIGNvbmRpdGlvbnMgdW5kZXIgd2hpY2ggYSBob3N0IHBlcmZvcm1zIGFuIElu Zm9ybWF0aW9uLVJlcXVlc3QgdW5kZXIKICBvdGhlciBjb25kaXRpb25zIGxpa2UgZ2V0dGluZyBh IG5ldyBwcmVmaXggaW4gYW4gUkEuICBUaGUgV0cgY2hhcnRlcgogIG5lZWRzIHRvIGJlIHVwZGF0 ZWQgYmVmb3JlIHRoZSBXRyB0YWtlcyBvbiB0aGlzIHdvcmsuICBUaGUgV0cKICBleHByZXNzZWQg Y29uc2Vuc3VzIHRvIGFjY2VwdCB0aGlzIGRyYWZ0IGFzIGEgV0cgd29yayBpdGVtIChwZW5kaW5n CiAgY2hhcnRlciB1cGRhdGU7IHdpbGwgYmUgY29uZmlybWVkIG9uIG1pbGluZyBsaXN0KS4KCgpN dWx0aWNhc3QgUmVjb25mLiBQcm90b2NvbCBmb3IgU3RhdGVsZXNzIERIQ1B2NgogIDxkcmFmdC12 aWpheS1kaGMtZGhjcHY2LW1jYXN0LXJlY29uZi0wMD4KICBBY2NlcHQgYXMgV0cgd29yayBpdGVt PwoKICBUaGUgYXV0aG9yIGdhdmUgYSBzaG9ydCBwcmVzZW50YXRpb24gYWJvdXQgdGhlIGRyYWZ0 LiAgVGhpcyBvcHRpb24KICBpcyBhbm90aGVyIHNvbHV0aW9uIGZvciB0aGUgcmVudW1iZXJpbmcg cHJvYmxlbSwgd2hpY2ggaXMgZXNwZWNpYWxseQogIGFwcGxpY2FibGUgdG8gdW5wbGFubmVkIGNo YW5nZXMuICBUaGUgY2hhaXIgY29uZmlybWVkIHRoYXQgdGhlcmUgYXJlCiAgdHdvIGNvbXBvbmVu dHM6IG9uZSB0aGF0IGRlc2NyaWJlcyBob3cgaG9zdHMgcmVzcG9uZCB0byB0aGUKICByZWNlb25m aWd1cmUgbWVzc2FnZSBhbmQgb25lIHRoYXQgZGVzY3JpYmVzIGhvdyB0byB0cmlnZ2VyIHRoZQog IHJvdXRlciB0byBzZW5kIHRoZSByZWNvbmZpZ3VyZSBtZXNzYWdlcy4gIE1hcmdhcmV0IFdhc3Nz ZXJtYW4gd2lsbAogIHRha2Ugc29tZSBjb25jZXJucyB0byB0aGUgZGhjd2cgbWFpbGluZyBsaXN0 LiAgVGhlIFdHIGNvbXBhcmVkIHRoaXMKICBkcmFmdCB3aXRoIHRoZSBwcmV2aW91cyAobGlmZXRp bWUgb3B0aW9uKSBkcmFmdDsgdGhlIFdHIGNvbnNlbnN1cwogIHdhcyB0aGF0IHRoZSB0d28gb3B0 aW9ucyBhcmUgc3VmZmljaWVudGx5IGRpZmZlcmVudCB0aGF0IHRoZXkgYXR0YWNrCiAgZGlmZmVy ZW50IHByb2JsZW1zLiAgVGhlIFdHIGNoYXJ0ZXIgbmVlZHMgdG8gYmUgdXBkYXRlZCBiZWZvcmUg dGhlCiAgV0cgdGFrZXMgb24gdGhpcyB3b3JrLiAgVGhlIFdHIGlzIHZlcnkgaW50ZXJlc3RlZCBp biB0aGlzIHdvcmssIGJ1dAogIElEIHdhcyBub3QgYWNjZXB0ZWQgYXMgV0cgd29yayBpdGVtLgoK KHJlc3RhcnQgYXQgMjowNWhycyBpbikKCklQdjQgYW5kIElQdjYgRHVhbC1TdGFjayBJc3N1ZXMg Zm9yIERIQ1B2NgogIDxkcmFmdC1jaG93bi1kaGMtZHVhbC1zdGFjay0wMD4KCiAgU3RpZyBWZW5h YXMgZ2F2ZSBhbiBpbnRyb2R1Y3Rpb24gdG8gdGhlIHByb2JsZW0gYmFzZWQgb24KICBkcmFmdC1j aG93bi1kaGMtZHVhbC1zdGFjay0wMDsgdGhpcyBkb2N1bWVudCBhbHNvIHByb3Bvc2VzIHNvbWUK ICBzb2x1dGlvbnMuICBrcmUgcmVtYXJrZWQgdGhhdCB0aXRsZSBpcyBhbGwgd3Jvbmc7IHRoZSBk cmFmdCByZWFsbHkKICBkaXNjdXNzZXMgcHJvYmxlbSBvZiBhY2NlcHRpbmcgY29uZmlndXJhdGlv biBmcm9tIG11bHRpcGxlCiAgaW50ZXJmYWNlcy4gIEFuIGFsdGVybmF0aXZlIHZpZXdwb2ludCBp cyB0aGF0IGluZm9ybWF0aW9uIGZyb20gdHdvCiAgc2VwYXJhdGUgaW50ZXJmYWNlcyBpcyBkaWZm ZXJlbnQgZnJvbSBoYXZpbmcgdG8gbWFrZSB0d28gYW5zd2VycyB0bwogIGdldCBhbGwgdGhlIGlu Zm9ybWF0aW9uIHJlcXVpcmVkLiAgSXQgbWF5IGJlIHBvc3NpYmxlIHRvIHNvbHZlIHRoZQogIGR1 YWwtc3RhY2sgcHJvYmxlbSB3aXRob3V0IHNvbHZpbmcgdGhlIG1vcmUgZ2VuZXJhbCBwcm9ibGVt IG9mCiAgZ2V0dGluZyBpbmZvcm1hdGlvbiBmcm9tIG11bHRpcGxlIHNvdXJjZXMuICBUaGUgV0cg ZXhwcmVzc2VkCiAgY29uc2Vuc3VzIHRvIGFjY2VwdCB0aGlzIGRvY3VtZW50IGFzIGEgV0cgd29y ayBpdGVtIChwZW5kaW5nIGNoYXJ0ZXIKICB1cGRhdGU7IHdpbGwgY29uZmlybSBvbiBtYWlsaW5n IGxpc3QpLgoKClVwZGF0ZSBvZiBkaGMgV0cgY2hhcnRlcgoKICAiUGFyLiBuIiByZWZlcnMgdG8g dGhlIG50aCBwYXJhZ3JhcGggaW4gdGhlIGN1cnJlbnQgZGhjIFdHIGNoYXJ0ZXIuCgogIFBhci4g MSAtIE9LCiAgUGFyLiAyIC0gT0sKICBQYXIuIDMgLSB3b3JrIGluIHByb2dyZXNzIChzZWN1cml0 eSk7IERyb21zIHRvIGFzayBkZXNpZ24gdGVhbQogICAgICAgICAgIGFib3V0IHByb2dyZXNzCiAg UGFyLiA0IC0gd29yayBpbiBwcm9ncmVzczsgZGVzaWduIHRlYW0gKEhpYmJzLCBjaGFpcikgcmV2 aWV3aW5nIFJGQwogICAgICAgICAgIDIxMzEKCiAgVGhlIFdHIGFncmVlZCB0aGF0IHRoZSBsaXN0 IG9mIGRyYWZ0cyB3aWxsIGJlIGRyb3BwZWQgZnJvbSB0aGUKICAgIGNoYXJ0ZXI7IGluYWN0aXZl IElEcyB0byBiZSBleHBsaWNpdGx5IGRyb3BwZWQgZnJvbSBXRyB3b3JrIGl0ZW1zCgogIE5ldyBj aGFydGVyIGl0ZW1zOgogICogU3RhdGVsZXNzIERIQ3B2NiByZW51bWJlcmluZwogICAgKDxkcmFm dC1jaG93bi1kaGMtc3RhdGVsZXNzLWRoY3B2Ni1yZW51bWJlcmluZy0wMD4pCiAgKiBEdWFsIHN0 YWNrIGlzc3VlcyA8ZHJhZnQtY2hvd24tZGhjLWR1YWwtc3RhY2stMDA+CiAgKiBESENQIHByb3h5 IGFyY2hpdGVjdHVyZSAtIE5hcnRlbiB0byBkaXNjdXNzIHdpdGggV0cgY2hhaXIgYmVmb3JlCiAg ICBhZGRpbmcgdG8gY2hhcnRlciAKCiAgVGhlIFdHIGNoYWlyIHdpbGwgd3JpdGUgdXAgdGV4dCBm b3IgZWFjaCBvZiB0aGUgdGhyZWUgaXRlbXMgYW5kIHRoZQogIFdHIHdpbGwgZGlzY3VzcyB0aGUg dGV4dCBvbiB0aGUgbWFpbGluZyBsaXN0CgpVcGRhdGUgb24gSVBSIGlzc3VlIHdpdGggdHdvIGRy YWZ0cwoKICBUaGlzIGFnZW5kYSBpdGVtIHdhcyBvdmVydGFrZW4gZXZlbnRzOyBXRyB0byByZXZp ZXcgdGhyZWUgbmV3IFJGQ3M6CiAgUkZDIDM2NjcsIFJGQyAzNjY4LCBSRkMgMzY2OTogYW5kIGRp c2N1c3MgSVBSIGlzc3VlcyBvbiBkaGN3ZwogIG1haWxpbmcgbGlzdC4KCg== --=====================_61855553==_-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 24 11:58:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06168; Wed, 24 Mar 2004 11:58:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BhZ-0005yr-ED; Wed, 24 Mar 2004 11:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3eDi-0005B6-8j for dhcwg@optimus.ietf.org; Wed, 17 Mar 2004 11:48:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20030 for ; Wed, 17 Mar 2004 11:48:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3eDb-00028c-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 11:48:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3eCm-000223-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 11:47:46 -0500 Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1B3eC1-0001v4-00 for dhcwg@ietf.org; Wed, 17 Mar 2004 11:46:57 -0500 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id i2HGBMMp028307 for ; Wed, 17 Mar 2004 11:11:22 -0500 (EST) Received: from NHROCCNC1.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Wed, 17 Mar 2004 11:46:51 -0500 Received: from source ([134.141.77.90]) by host ([134.141.79.124]) with SMTP; Wed, 17 Mar 2004 11:46:51 -0500 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC1.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 17 Mar 2004 11:46:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Mar 2004 11:46:50 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA017E0CC3@NHROCMBX1.ets.enterasys.com> Thread-Topic: Ad additional reeqview of: DHCPv4 MIB, revision 10 Thread-Index: AcQMNruIdgBnV6VjRBeu/5Xk0E8wVAACFdOw From: "Harrington, David" To: "Wijnen, Bert (Bert)" , , , Cc: , , X-OriginalArrivalTime: 17 Mar 2004 16:46:51.0075 (UTC) FILETIME=[72258130:01C40C3F] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.5 X-pstn-levels: (C:98.9754 P:95.5390 R:95.9108 S:99.9000 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [dhcwg] RE: Ad additional reeqview of: DHCPv4 MIB, revision 10 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Step on them all you want, Bert ;-)=20 I welcome additional eyes reviewing this document. I haven't yet completed my review, and I think it received inadequate review by the WG before submission. dbh > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 > Sent: Wednesday, March 17, 2004 10:44 AM > To: Harrington, David; rbhibbs@pacbell.net; gww@nortel.com;=20 > dhcwg@ietf.org > Cc: Wijnen, Bert (Bert); margaret.wasserman@nokia.com;=20 > narten@us.ibm.com; rdroms@cisco.com > Subject: Ad additional reeqview of: DHCPv4 MIB, revision 10 >=20 > Let me add my comments after a (very) quick scan. > David, I am not intending to step on your toes here, just > trying to help and trying to point out a few more things that > I could quickly spot. May make it easier for authors to > include fixes in next revision. >=20 > 1.Sect 3.1.1. syasy: > The DHCP MIBs share a > Better: > The DHCP MIB modules share a > There is ONE MIB that is composed of many MIB modules! > This may be true for other places in the doc. > =20 > 2.Sect 3.1.2 talks about a Host System Mib with ref to RFC1123??? > RFC1123 does not have a MIB Did you mean RFC1213, which=20 > does not contain a Host System Mib, but contains a "systemGroup" > in the SNMP MIB II. But these days it would be betetr to point > to RFC3418 SNMPv20MIB that conatins systemGroup) >=20 > 3.Recently the RFC-Editor has requested notation for IMPORTs as > follows: > SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] > So that there are citattions for normative refrences. >=20 > 4.Things like: > ::=3D { mib-2 9999 } -- IANA will make official assignment > Are VERY BAD. > Please use: > ::=3D { mib-2 nnn } -- IANA please assign xxxx >=20 > 5.I doubt that the use of OBJECT-IDENTITY is proper here. > I will check with MIB DOctor team >=20 >=20 > Thanks, > Bert=20 >=20 > > -----Original Message----- > > From: Harrington, David [mailto:dbh@enterasys.com] > > Sent: woensdag 17 maart 2004 15:48 > > To: Harrington, David; rbhibbs@pacbell.net; gww@nortel.com; > > dhcwg@ietf.org > > Cc: Wijnen, Bert (Bert); margaret.wasserman@nokia.com; > > narten@us.ibm.com; rdroms@cisco.com > > Subject: RE: DHCPv4 MIB review - detailed part one > >=20 > >=20 > > Hi, > >=20 > > I'm doing a mib doctor review of the DHCPv4 server mib. This=20 > > document is > > not ready for advancement, and needs through review by the WG. > >=20 > > Part I: technical concerns > >=20 > > Section 3.3 says "there will be differences in the counts=20 > reported by > > different servers." The purpose of a standard is to get all > > implementations to report the data the same way, so data can=20 > > be compared > > reasonably across vendors. We don't want to standardize that > > implementors can count things in whatever non-interoperable=20 > > manner they > > choose. > >=20 > > Section 3.3.1 uses MUSTs in a manner that does not seem=20 > > consistent with > > RFC2119 - [MUST This word, or the terms "REQUIRED" or=20 > "SHALL", mean > > that the definition is an absolute requirement of the=20 > > specification.] We > > standardize the format and semantics of values that pass on-the-wire > > between an agent and a manager; we do not dictate what a=20 > > manager must do > > with the data it receives from the agent. > >=20 > > In the first case, it says "a manager MUST be capable of recognizing > > this case." I would suggest that you tell an implementor HOW to > > recognize this case, without chance of error. I'm not sure=20 > it's always > > possible. Even with a method to do so, we should only=20 > recommend that a > > manager recognize this case, since we don't know whether=20 > this case is > > important to the purpose of the management application. A mibwalk > > application is a type of manager that doesn't even attempt to=20 > > interpret > > counters; it may start and end without ever getting a counter=20 > > twice. Why > > MUST it be capable of recognizing a counter discontinuity? > >=20 > > Section 3.3.1, second case, says "a manager MUST discard=20 > > data"; I don't > > believe that should be a MUST; it should be a SHOULD. The=20 > > discontinuity > > between two GETs does not affect on-the-wire=20 > > interoperability, and thus > > is not an absolute requirement; it only affects subsequent > > interpretation of the values. We should RECOMMEND that they=20 > > discard the > > faulty data, but it is an application-implementor decision=20 > > whether to do > > so, depending on the application needs. Therefore this should=20 > > only be a > > SHOULD. > >=20 > > --- > > MODULE IDENTITY - it is good practice to use consistent=20 > > prefixes for the > > DEFINITIONS ::=3D BEGIN clause, the MODULE IDENTITY, and the=20 > objects in > > the mib. See appendix C in > > http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review- > > guidelines > > -02.txt=20 > >=20 > > In this MIB, they are inconsistent: > >=20 > > DHCP-SERVER-MIB DEFINITIONS ::=3D BEGIN > > dhcp MODULE-IDENTITY > > dhcpv4ServerXXX objects > >=20 > > These are just guidelines, but I suggest changing DHCP-SERVER-MIB to > > DHCPv4-SERVER-MIB, and I suggest using dhcpv4ServerMIB as the MODULE > > IDENTITY, to improve consistency. > >=20 > > --- > > bootpXXXX objects - It is good practice (see Naming=20 > conventions in the > > guidelines document) to prefix all objects in the mib with the same > > prefix used in the module identity. This helps others not=20 > > create objects > > with conflicting names. Have you considered having two mib=20 > modules in > > this document - one small one for bootp objects and the other for > > dhcpv4Server objects? Can bootp ever be used without=20 > dhcpv4Server? If > > so, they probably should be independent mib modules. If not,=20 > > they should > > probably be named dhcpv4ServerBootpXXX for consistency. > >=20 > > Could bootp packets be counted at the client or in transit as=20 > > well as at > > the server? Should these be bootpServerXXX objects? > >=20 > > bootpCountXXX - you don't need the "Count" in the name; > > bootpRequests/bootpInvalids/etc. would be consistent with=20 > established > > practice for naming counters. > >=20 > > bootpCountInvalids might be ambiguous regarding the meaning=20 > > of invalid. > > A standard should be written such that different=20 > implementors will not > > interpret the semantics differently. > >=20 > > bootpCountDroppedUnknownClients and=20 > bootpCountDroppedNotServingSubnet > > seem ambiguous and overlapping. If I have not configured my=20 > > server, and > > don't recognize the hardware address in a received packet, which > > counter(s) get incremented? If I do not provide service to=20 > > the hardware > > address found in the received packet, and the packet was=20 > > received from a > > subnet I am not configured to serve, which counter(s) do I=20 > increment? > >=20 > > --- > > dhcpv4Server objects (all objects below start with=20 > > dhcpv4Server prefix) > >=20 > > SystemDescr - why is this a SHOULD and not a MUST for compliant > > implementations? Is there a technical reason why it may be=20 > > impossible to > > provide this information in an implementation that complies with the > > standard? For comparison, sysDescr in RFC3418 calls for the hardware > > type, operating system, and networking software, but that=20 > > information is > > not always available to the snmp subsystem, so the=20 > > requirement can only > > be a SHOULD.=20 > >=20 > > dhcpv4ServerSystemObjectID - I suspect this is a cut and=20 > paste error; > > "identification of the network management subsystem" is also the > > description of sysObjectId from the snmpMIB in RFC3418. Did=20 > > you mean to > > duplicate that object here? If so, why? If not, what did you=20 > > want here? > >=20 > > dhcpv4CountXXX - don't need the "Count"; should use prefix of > > dhcpv4ServerXXX. > >=20 > > Could these counters also be implemented on clients or=20 > transit points? > > (For example, I might want to monitor how much DHCP traffic=20 > > is passing a > > given node in the network, which is neither client nor=20 > server). If so, > > it might be better to write one mib module with objects that=20 > > can be used > > by either server or client, and another mib module for objects only > > meaningful on a server. Multiple mib modules can exist in a=20 > > document. By > > separating the modules, an application doesn't need to import object > > definitions that are not important. A developer that uses a=20 > utility to > > generate stub code from a mib module won't need to generate=20 > stub code > > for a server when they are implementing a client, if you=20 > > divide the mib > > accordingly. > >=20 > > Counters that count multiple conditions can lead to different > > interpretations and overlap. In your mib, I get nervous when such OR > > conditions have no reference clause, while the unambiguous=20 > counters do > > have reference clauses; this makes me think the counter is=20 > > ill-defined. > > Can you write CountInvalids, UnknownClient, NotServingSubnet without > > using an OR in the description? Can you provide a reference=20 > to ensure > > that there is one unambiguous reference to the condition to=20 > > be counted? > > Wouldn't it be better to count
=20 > > separately from > >
? Wouldn't it be=20 > better to count > > separately from > addresses on that subnet>? Would it be better to count > understood> > > separately from ? > >=20 > > --- > > SharedNetXXX objects > >=20 > > SharedNetTable. The description says this table is present=20 > ONLY under > > certain conditions, but the Compliance statement shows this as > > unconditionally mandatory. See section 4.8 in the=20 > guidelines document > > for how to specify conditionally mandatory sections of the=20 > mib. (Note > > that if you make this unconditionally optional, I will=20 > > probably suggest > > removing it from the mib altogether, since many=20 > > implementations wouldn't > > bother implementing a fully optional section.) > >=20 > > SharedNetName is a SnmpAdminString, a T-C defined to allow > > administrators to define names that would be meaningful to them. The > > Security Considerations treats this as a read-only mib. Who=20 > decides on > > the value of the names? How is the name set? Is there a=20 > > reference to how > > one determines what a name should be? Or is it freeform, up to the > > operator? How is it set on a device with only an SNMP interface? > >=20 > > Why 100 for a length? Is there a reference? > >=20 > > LowThreshold/HighThreshold - what's an event? Is there a=20 > reference for > > the term event in DHCPv4? Is this an snmp notification?=20 > >=20 > > LowThreshold/HighThreshold - must the HighThreshold be=20 > > greater than the > > LowThreshold? Can they be equal? Can High be less than Low?=20 > Is there a > > reference someplace? > >=20 > > How are the thresholds set? They're read-only, but they appear to be > > user-configurable values, possibly set through some=20 > backdoor mechanism > > like the CLI. If they are meant to be user configured, why=20 > > not make the > > objects read-write so those who want to can use snmp SETs to modify > > them? You can always write two compliance clauses - one for a=20 > > read-write > > implementation and one for read-only implementation, and allow the > > implementor to choose whether to support SETs. For=20 > > implementations that > > support read-write, a disable-writes object can be used by=20 > > the operation > > to disable the set capability for the mib (or a global one=20 > can be used > > to disable all sets to the agent). SNMP SETs of SNMP objects=20 > > expected to > > be user-configured shouldn't be **prohibited** by the standard. > >=20 > > Consistency - SharedNetTable.sharedNetName vs. > > Subnettable.SharedNetworkName; they should both be NetName=20 > or both be > > NetworkName. > >=20 > > Cut-and-paste error? Subnet..LowThreshold ... generated for this > > **shared network**.=20 > >=20 > > It would be nice if all accesible-for-notify tables were=20 > located near > > the notifications. Currently there are readable objects, then > > accessible-for-notify objects, then readable objects, then=20 > > notifications > > in the mib. > >=20 > > --- > > ServerClientTable "an optional list" that "MUST contain=20 > addresses that > > have not expired". Is this list optional or "an absolute=20 > > requirement of > > the specification"? I can't tell what is expected here. > >=20 > > non-meaningful descriptions: > > ClientEntry - a logical row in the ClientTable (yeah, but=20 > what does it > > represent?) > > Client (IPv4 address type) - "the IPv4 address of this entry in the > > ClientTable". (does that mean I can send IPv4 messages to=20 > this row in > > the table using this address? Or do you mean this is the IPv4=20 > > address of > > the client represented in this row?) > >=20 > > dhcpv4ServerClientSubnetMask "... MUST ... Appear as a row in the > > dhcpSubnetTable." Where do I find the dhcpSubnetTable? > >=20 > > I did a general review of the document through page 24; I=20 > > didn't review > > the rest. I'll wait for the next revision, which should be=20 > thoroughly > > reviewed by the WG first. > >=20 > > --- > > There are some typos: > > Section 2: "[RFC3410], Managed" s/b "[RFC3410]. Managed" > >=20 > > --- > > This module should have been checked against > > http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review- > > guidelines > > -02.txt before being sent for IESG and mib doctor review. It=20 > > appears to > > me the document has not been checked against the guidelines: > >=20 > > 1) The boilerplate for snmp is just slightly incorrect=20 > (punctuation),=20 > > 2) the references for SNMP don't match the template,=20 > > 3) the security considerations don't quite follow the security > > boilerplate, > > 4) the MODULE-IDENTITY OID assignment doesn't follow the section 4.5 > > guidelines,=20 > > 5) the abstract says it is experimental, > > And so on. I stopped mib-doctor-checking at this point. > >=20 > > Can the WG please check the document against the guidelines before > > resubmitting? > >=20 > > Thanks, > > dbh > >=20 > > > -----Original Message----- > > > From: Harrington, David=20 > > > Sent: Thursday, February 19, 2004 3:03 PM > > > To: 'rbhibbs@pacbell.net'; Glenn Waters (gww@nortel.com) > > > Cc: 'Wijnen, Bert (Bert)'; margaret.wasserman@nokia.com;=20 > > > 'narten@us.ibm.com'; 'rdroms@cisco.com' > > > Subject: FW: DHCPv4 MIB review=20 > > >=20 > > > Hi, > > >=20 > > > I don't think I've responded since you published -11- (0r the=20 > > > second -10-), so here you go.=20 > > >=20 > > > This is my first pass only, which includes only the result of=20 > > > using a diff utility to find text you changed. Since you also=20 > > > significantly changed the design of the mib, that will=20 > > > require at least another pass to understand the ramifications=20 > > > of your changes. Have you run all these chnages past the WG=20 > > > for review? > > >=20 > > > 1) I was a bit surprised to see a whole section dropped,=20 > > > apparently without discussion with the WG. The dropped=20 > > > "optional" stuff can of course be done as a separate mib later. > > >=20 > > > 2) In section 3.2.1, it states the MAC address is the layer 1=20 > > > physical address. The media access control (MAC) address is=20 > > > part of layer 2. > > >=20 > > > 3) 3.3 "Not all servers validate received packets in the same=20 > > > way, so there will be differences in the counts reported by=20 > > > different servers." I find this antithetical to a standards=20 > > > document. The MIB object interface should standardize what=20 > > > gets reported. If different servers count things differently=20 > > > now, then they should change to provide a consistent=20 > > > reporting metric. A counter that records different things on=20 > > > different servers is close to useless for a manager, because=20 > > > the values cannot be compared across vendors. For example, if=20 > > > an application sends an alarm to an operator if a counter=20 > > > exceeds some threshold, you don't want to have to write a=20 > > > separate rule for each vendor about what the threshold should=20 > > > be. You want consistency in reporting. > > >=20 > > > This also means that the counters which go into the formulae=20 > > > need to be consistent, or you get the GIGO effect. > > >=20 > > > 4) You dropped leasequery objects, but leasequeries are still=20 > > > in your total packets formula. Can you check the document for=20 > > > the use of any objects you eliminated, such as=20 > > > Dhcpv4CountLeaseQueries, please? > > >=20 > > > 5) Discontinutities. In the first case, it is hard to=20 > > > understand when the "point of restart" is, so an application=20 > > > in the process of two GETs for comparison should assume the=20 > > > first GET is worthless, and start over, because there is no=20 > > > way to quantify what occurred during the discontinuous period. > > >=20 > > > 6) 3.4 "should be able to provide" should be "SHOULD provide" > > >=20 > > > 7) Many counters were changed to Counter64. Do you really=20 > > > need 64-bit counters? They are much more expensive for most=20 > > > vendors to implement, and **critically important** they=20 > > > cannot be passed using SNMPv1 or SNMPv2 messages. Counter64=20 > > > should only be used if rollover of a 32-bit counter is=20 > > > possible within an hour. A 32-bit counter can handle more=20 > > > than 1 million counted events per second; and "one of the=20 > > > busiest known to exist" only got to 100 transactions per=20 > > > second. Counter64 is for counting things like bytes=20 > > > transmitted on a Gig interface. > > >=20 > > > dbh > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > -----Original Message----- > > > From: Barr Hibbs [mailto:rbhibbs@pacbell.net] > > > Sent: Monday, February 02, 2004 7:58 PM > > > To: dbharrington@comcast.net; gww@NortelNetworks.com > > > Subject: RE: DHCPv4 MIB review > > >=20 > > >=20 > > >=20 > > > Dave-- > > >=20 > > > I've updated the DHCPv4 Server MIB per your suggestions and=20 > > > am attaching a > > > copy of it to this note, prior to submitting it to the I-D editor. > > >=20 > > > The MIB has been successfully compiled by the SMILINT=20 > > > compiler, save for the > > > warnings about use of IPv4-specific address components and=20 > > > the lack of a > > > display hint for an unsigned32 object. > > >=20 > > > I appreciate your efforts to date on our behalf. > > >=20 > > > --Barr > > >=20 > > >=20 > > > *** included message text *** > > >=20 > > > This is an automatically generated mail message in response=20 > > to a mail > > > message > > > you (or someone else who used your address) sent to > > > . > > > If you want to learn more about this mail service, send a=20 > > > mail message with > > > the "Subject: help" to . > > >=20 > > > This command (smilint 0.4.3-pre1, as of Mon Jan 12 15:21:55 2004) > > > has been processed to get the following results: > > > smilint -m -s -l 6 -i namelength-32 mailbody > > >=20 > > > mailbody:64: [5] {type-without-format} warning: type=20 > > > `DhcpTimeInterval' has > > > no format specification > > > mailbody:812: [5] {inetaddress-specific} warning:=20 > > > `InetAddress' should be > > > used instead of `InetAddressIPv4' > > > mailbody:915: [5] {inetaddress-specific} warning:=20 > > > `InetAddress' should be > > > used instead of `InetAddressIPv4' > > > mailbody:925: [5] {inetaddress-specific} warning:=20 > > > `InetAddress' should be > > > used instead of `InetAddressIPv4' > > > mailbody:1010: [5] {inetaddress-specific} warning:=20 > > > `InetAddress' should be > > > used instead of `InetAddressIPv4' > > > mailbody:1031: [5] {inetaddress-specific} warning:=20 > > > `InetAddress' should be > > > used instead of `InetAddressIPv4' > > > mailbody:1226: [5] {inetaddress-specific} warning:=20 > > > `InetAddress' should be > > > used instead of `InetAddressIPv4' > > > mailbody:1296: [5] {inetaddress-specific} warning:=20 > > > `InetAddress' should be > > > used instead of `InetAddressIPv4' > > >=20 > >=20 >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 24 12:57:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09562; Wed, 24 Mar 2004 12:57:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ccg-0004MD-IQ; Wed, 24 Mar 2004 12:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Ks9-0001v1-2I for dhcwg@optimus.ietf.org; Mon, 22 Mar 2004 03:33:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10085 for ; Mon, 22 Mar 2004 03:33:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Ks6-0007AO-00 for dhcwg@ietf.org; Mon, 22 Mar 2004 03:33:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5KrG-00074w-00 for dhcwg@ietf.org; Mon, 22 Mar 2004 03:32:31 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1B5Kqa-0006yN-00 for dhcwg@ietf.org; Mon, 22 Mar 2004 03:31:49 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id CF99315210; Mon, 22 Mar 2004 17:31:48 +0900 (JST) Date: Mon, 22 Mar 2004 17:31:46 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: Bernie Volz , "'Ted Lemon'" , dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv6 on link with no router? In-Reply-To: References: <000401c40c4d$2057da20$cb412ca1@amer.cisco.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Wed, 17 Mar 2004 13:58:34 -0800 (PST), >>>>> Erik Nordmark said: >> I too agree with you Ted - a router (or something serving that function >> in some limited capacity) should send out RAs if that is needed. Having >> DHCP send prefix information just opens a can of worms - which should a >> host believe if it receives ones from DHCP and a router's RAs. It is >> best if things come from only one place. So, if you need prefixes >> advertised, some entity on the network must send RAs. > I think that was what I suggested in the first post on the subject. > It would probably imply that the same node(s) on the link which runs DHCP > (be it a relay or a server) that would send these RAs, > because otherwise you need to assign a (pair of) additional nodes > to send the RAs. > ["A pair" to avoid a single point of failure.] > This removes the need for the host to try to resolve conflicting > information it would need from different sources (DHCP vs. RA), > but it still requires care in configuring these nodes to make sure > that the DHC addresses are consistent with the subnet prefix that > is advertised in the RA. I think the latter can be an implementation > issue on the DHCP agent boxes that sending the RAs. (This is probably not a dhcp issue, but an ND issue) assuming we have agreed that the "on-link by default" rule should be removed from rfc2461bis, it should also note that we need to be careful that the on-link prefixes may need to be advertised. Should we bring this to the ipv6 wg to help the 2461bis work? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 24 17:27:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25926; Wed, 24 Mar 2004 17:27:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Gpj-00061s-LE; Wed, 24 Mar 2004 17:26:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6GoU-0005yc-W1 for dhcwg@optimus.ietf.org; Wed, 24 Mar 2004 17:25:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25875 for ; Wed, 24 Mar 2004 17:25:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6GoS-0007SL-00 for dhcwg@ietf.org; Wed, 24 Mar 2004 17:25:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Gne-0007Pt-00 for dhcwg@ietf.org; Wed, 24 Mar 2004 17:24:39 -0500 Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx with esmtp (Exim 4.12) id 1B6Gms-0007GI-00; Wed, 24 Mar 2004 17:23:50 -0500 Received: from homerdmz ([206.172.52.116] helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.36 #1 (Debian)) id 1B6GmO-0006lx-00; Wed, 24 Mar 2004 14:23:20 -0800 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Mar 2004 14:23:13 -0800 Message-ID: From: "Kostur, Andre" To: "'Internet-Drafts@ietf.org'" Cc: dhcwg@ietf.org Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-leasequery-07.txt Date: Wed, 24 Mar 2004 14:23:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C411EE.97CFC080" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C411EE.97CFC080 Content-Type: text/plain; charset="iso-8859-1" Questions: Section 6.2: o The Parameter Request List option (option 55) SHOULD be set to the options of interest to the requester. The interesting options are likely to include the IP Address Lease Time option (option 51), the Relay Agent Information option (option 82) and possibly the Vendor class identifier option (option 60). In the absence of a Parameter Request List option, the server SHOULD return the same options it would return for a DHCPREQUEST message which didn't contain a DHCPLEASEQUERY message, which includes those mandated by [RFC 2131, Section 4.3.1] as well as any options which the server was configured to always return to a client. Curious why this particular clause got added. Under the previous drafts, the client asked for whatever options they were interested in, and that's that. With this, the Leasequery would be answering with possibly a whole bunch of extra stuff. I don't see why this shouldn't be a MUST (as in, the requestor MUST supply a Parameter Request List for the options that it is interested in. With no request list, the reqestor would get the Active/Unassigned/Unknown indication and CHADDR, but that's it). Section 6.4: o DHCPUNIMPLEMENTED The DHCPUNIMPLEMENTED response to the DHCPLEASEQUERY message indicates that DHCPLEASEQUERY is not implemented by this DHCP server. The DHCPUNIMPLEMENTED message can apply to any unimplemented messages, and MAY be used to respond to messages other than DHCPLEASEQUERY. Since according to this draft, all servers are required to implement all three query types, why is DHCPUNIMPLEMENTED listed in here? Shouldn't that be it's own draft, since it no longer has anything to do with leasequery (directly)? ------_=_NextPart_001_01C411EE.97CFC080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] I-D ACTION:draft-ietf-dhc-leasequery-07.txt

Questions:

Section 6.2:

      o The Parameter = Request List option (option 55) SHOULD be set to
        the = options of interest to the requester.  The interesting
        options = are likely to include the IP Address Lease Time option
        (option = 51), the Relay Agent Information option (option 82) and
        possibly = the Vendor class identifier option (option 60).  In the
        absence = of a Parameter Request List option, the server SHOULD
        return = the same options it would return for a DHCPREQUEST
        message = which didn't contain a DHCPLEASEQUERY message, which
        includes = those mandated by [RFC 2131, Section 4.3.1] as well as
        any = options which the server was configured to always return to
        a = client.

Curious why this particular clause got added.  = Under the previous drafts, the client asked for whatever options they = were interested in, and that's that.  With this, the Leasequery = would be answering with possibly a whole bunch of extra stuff.  I = don't see why this shouldn't be a MUST (as in, the requestor MUST = supply a Parameter Request List for the options that it is interested = in.  With no request list, the reqestor would get the = Active/Unassigned/Unknown indication and CHADDR, but that's = it).



Section 6.4:

      o = DHCPUNIMPLEMENTED

        The = DHCPUNIMPLEMENTED response to the DHCPLEASEQUERY message
        indicates = that DHCPLEASEQUERY is not implemented by this DHCP
        = server.

        The = DHCPUNIMPLEMENTED message can apply to any unimplemented
        messages, = and MAY be used to respond to messages other than
        = DHCPLEASEQUERY.


Since according to this draft, all servers are = required to implement all three query types, why is DHCPUNIMPLEMENTED = listed in here?  Shouldn't that be it's own draft, since it no = longer has anything to do with leasequery (directly)?


------_=_NextPart_001_01C411EE.97CFC080-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 24 19:18:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01927; Wed, 24 Mar 2004 19:18:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6IZN-0001pF-I0; Wed, 24 Mar 2004 19:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6IYb-0001oG-EL for dhcwg@optimus.ietf.org; Wed, 24 Mar 2004 19:17:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01829 for ; Wed, 24 Mar 2004 19:17:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6IYZ-0006fj-00 for dhcwg@ietf.org; Wed, 24 Mar 2004 19:17:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6IX8-0006ay-00 for dhcwg@ietf.org; Wed, 24 Mar 2004 19:15:43 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1B6IWj-0006Ww-00; Wed, 24 Mar 2004 19:15:17 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 24 Mar 2004 16:14:48 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i2P0Eiew018957; Wed, 24 Mar 2004 16:14:45 -0800 (PST) Received: from kkinnear-w2k03.cisco.com (rtp-vpn3-380.cisco.com [10.82.217.126]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHB81438; Wed, 24 Mar 2004 19:14:42 -0500 (EST) Message-Id: <4.3.2.7.2.20040324185704.03aacfe8@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 24 Mar 2004 19:14:42 -0500 To: "Kostur, Andre" , "'Internet-Drafts@ietf.org'" From: Kim Kinnear Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-leasequery-07.txt Cc: dhcwg@ietf.org, kkinnear@cisco.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Andre, Good questions. Thomas Narten developed quite a number of issues with this draft, and we have attempted to address them as best we could. You've reminded me that I should send out a list of all of the changes to the list, which I managed to forget to do. Anyway, to answer your questions, indented, below... At 05:23 PM 3/24/2004, Kostur, Andre wrote: >Questions: > >Section 6.2: > > o The Parameter Request List option (option 55) SHOULD be set to > the options of interest to the requester. The interesting > options are likely to include the IP Address Lease Time option > (option 51), the Relay Agent Information option (option 82) and > possibly the Vendor class identifier option (option 60). In the > absence of a Parameter Request List option, the server SHOULD > return the same options it would return for a DHCPREQUEST > message which didn't contain a DHCPLEASEQUERY message, which > includes those mandated by [RFC 2131, Section 4.3.1] as well as > any options which the server was configured to always return to > a client. > >Curious why this particular clause got added. Under the previous drafts, the client asked for whatever options they were interested in, and that's that. With this, the Leasequery would be answering with possibly a whole bunch of extra stuff. I don't see why this shouldn't be a MUST (as in, the requestor MUST supply a Parameter Request List for the options that it is interested in. With no request list, the reqestor would get the Active/Unassigned/Unknown indication and CHADDR, but that's it). Hmmm. We seem to have added that clause for the first time in the -04 draft. It isn't new this time, and I don't actually remember why we added it. Seemed to make sense at the time (as in the "why not?" kind of sense) so I at least didn't see any reason to argue about it. I still don't see anything wrong with it. If you care enough to send a leasequery, you probably care enough to send a parameter-request-list, so to a first approximation, anyone who has their head screwed on tightly will send a parameter request list. So, if the default behavior is at least adequate (which I think this is), it seems like it isn't worth a lot of time to try to optimize it -- not least because one person's optimization is not necessarily another's. >Section 6.4: > > o DHCPUNIMPLEMENTED > > The DHCPUNIMPLEMENTED response to the DHCPLEASEQUERY message > indicates that DHCPLEASEQUERY is not implemented by this DHCP > server. > > The DHCPUNIMPLEMENTED message can apply to any unimplemented > messages, and MAY be used to respond to messages other than > DHCPLEASEQUERY. > >Since according to this draft, all servers are required to implement all three query types, why is DHCPUNIMPLEMENTED listed in here? In case you don't implement leasequery at all. Or in case you implement it and don't want to answer about it right now. Cheers -- Kim > Shouldn't that be it's own draft, since it no longer has anything to do with leasequery (directly)? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 24 19:19:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02001; Wed, 24 Mar 2004 19:19:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6IaK-00020J-NJ; Wed, 24 Mar 2004 19:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6IZp-0001yD-Pl for dhcwg@optimus.ietf.org; Wed, 24 Mar 2004 19:18:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01922 for ; Wed, 24 Mar 2004 19:18:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6IZo-0006oB-00 for dhcwg@ietf.org; Wed, 24 Mar 2004 19:18:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6IYv-0006k7-00 for dhcwg@ietf.org; Wed, 24 Mar 2004 19:17:34 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1B6IYU-0006dE-00 for dhcwg@ietf.org; Wed, 24 Mar 2004 19:17:06 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 24 Mar 2004 16:16:37 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i2P0GXBB026184; Wed, 24 Mar 2004 16:16:34 -0800 (PST) Received: from kkinnear-w2k03.cisco.com (rtp-vpn3-380.cisco.com [10.82.217.126]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHB81546; Wed, 24 Mar 2004 19:16:32 -0500 (EST) Message-Id: <4.3.2.7.2.20040324191444.039c32d0@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 24 Mar 2004 19:16:31 -0500 To: dhcwg@ietf.org From: Kim Kinnear Cc: kkinnear@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [dhcwg] draft-ietf-dhc-leasequery-07.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Folks, In an extended email discussion with Thomas Narten about the leasequery draft, the following changes were made to the draft in an attempt to elicit his approval and support for the draft, resulting in: draft-ietf-dhc-leasequery-07.txt Significant changes: -------------------- 1. The MAC address and client-id option query approaches to DHCPLEASEQUERY were changed from optional to required parts of every DHCPLEASEQUERY implementation. 2. The DHCPLEASEKNOWN message name was changed to DHCPLEASEUNASSIGNED. Minor Changes: -------------- 1. The MUST/SHOULD language in the overview was removed, since it is only an overview. 2. Added a table of contents. 3. Modified the abstract to that it is not identical to the intro. 4. Removed primary and secondary DHCP server definitions. 5. Fixed the transition to paragraph starting "An alternative approach...". 6. Added language to the draft to suggest that we are asking for only slightly more information to be kept in a lease binding than RFC2131. 7. Added language to discuss lifetimes for cacheing DHCPLEASEQUERY information. 8. Changed SHOULD NOT to MUST NOT with respect to adding additional options to a DHCPLEASEKNOWN message. 9. Removed all references to failover draft. 10. Suggested using relay agent authentication in security section. 11. Discussed spoofed DHCPLEASEQUERY messages in security section. 12. Discussed use of giaddr as a return address, and how this is not different than RFC2131. 13. Discussed that the saved relay agent option should be used to decide which options would have been returned to the DHCP client. 14. Correctly minor spelling and grammar mistakes. --------------------------------- Cheers -- Kim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 24 19:57:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03386; Wed, 24 Mar 2004 19:57:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6JB6-0004CY-Qc; Wed, 24 Mar 2004 19:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6JAg-0004BA-2G for dhcwg@optimus.ietf.org; Wed, 24 Mar 2004 19:56:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03311 for ; Wed, 24 Mar 2004 19:56:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6JAe-0001IQ-00 for dhcwg@ietf.org; Wed, 24 Mar 2004 19:56:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6J9m-0001Da-00 for dhcwg@ietf.org; Wed, 24 Mar 2004 19:55:39 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1B6J8p-00017G-00 for dhcwg@ietf.org; Wed, 24 Mar 2004 19:54:39 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 24 Mar 2004 16:54:11 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i2P0s7ew014531; Wed, 24 Mar 2004 16:54:07 -0800 (PST) Received: from kkinnear-w2k03.cisco.com (rtp-vpn3-380.cisco.com [10.82.217.126]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHB83723; Wed, 24 Mar 2004 19:54:04 -0500 (EST) Message-Id: <4.3.2.7.2.20040324195024.026d0808@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 24 Mar 2004 19:54:04 -0500 To: Kim Kinnear , "Kostur, Andre" From: Kim Kinnear Cc: dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20040324185704.03aacfe8@goblet.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [dhcwg] WARNING -- do NOT reply-all to Andre's or my recent posts! Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Folks, Be very careful when replying to the message that Andre sent recently about the leasequery draft. In particular, do *not* reply-all to it, or to my message in response to his. His original message included internet-drafts@ietf.org in the address list, and I inadvertently propagated this mistake. Thanks -- Kim At 07:14 PM 3/24/2004, Kim Kinnear wrote: >Andre, > >Good questions. Thomas Narten developed quite a number of issues >with this draft, and we have attempted to address them as best >we could. You've reminded me that I should send out a list of all >of the changes to the list, which I managed to forget to do. > >Anyway, to answer your questions, indented, below... > >At 05:23 PM 3/24/2004, Kostur, Andre wrote: > >>Questions: >> >>Section 6.2: >> >> o The Parameter Request List option (option 55) SHOULD be set to >> the options of interest to the requester. The interesting >> options are likely to include the IP Address Lease Time option >> (option 51), the Relay Agent Information option (option 82) and >> possibly the Vendor class identifier option (option 60). In the >> absence of a Parameter Request List option, the server SHOULD >> return the same options it would return for a DHCPREQUEST >> message which didn't contain a DHCPLEASEQUERY message, which >> includes those mandated by [RFC 2131, Section 4.3.1] as well as >> any options which the server was configured to always return to >> a client. >> >>Curious why this particular clause got added. Under the previous drafts, the client asked for whatever options they were interested in, and that's that. With this, the Leasequery would be answering with possibly a whole bunch of extra stuff. I don't see why this shouldn't be a MUST (as in, the requestor MUST supply a Parameter Request List for the options that it is interested in. With no request list, the reqestor would get the Active/Unassigned/Unknown indication and CHADDR, but that's it). > > Hmmm. We seem to have added that clause for the first > time in the -04 draft. It isn't new this time, and I > don't actually remember why we added it. Seemed to make > sense at the time (as in the "why not?" kind of sense) so > I at least didn't see any reason to argue about it. > > I still don't see anything wrong with it. If you care > enough to send a leasequery, you probably care enough to > send a parameter-request-list, so to a first > approximation, anyone who has their head screwed on > tightly will send a parameter request list. So, if the > default behavior is at least adequate (which I think this > is), it seems like it isn't worth a lot of time to try to > optimize it -- not least because one person's > optimization is not necessarily another's. > > > > >>Section 6.4: >> >> o DHCPUNIMPLEMENTED >> >> The DHCPUNIMPLEMENTED response to the DHCPLEASEQUERY message >> indicates that DHCPLEASEQUERY is not implemented by this DHCP >> server. >> >> The DHCPUNIMPLEMENTED message can apply to any unimplemented >> messages, and MAY be used to respond to messages other than >> DHCPLEASEQUERY. >> >>Since according to this draft, all servers are required to implement all three query types, why is DHCPUNIMPLEMENTED listed in here? > > In case you don't implement leasequery at all. Or in > case you implement it and don't want to answer about it > right now. > > Cheers -- Kim > >> Shouldn't that be it's own draft, since it no longer has anything to do with leasequery (directly)? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Mar 26 10:41:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26454; Fri, 26 Mar 2004 10:41:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6tSA-0003qr-Hk; Fri, 26 Mar 2004 10:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6tRX-0003ng-8O for dhcwg@optimus.ietf.org; Fri, 26 Mar 2004 10:40:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26386 for ; Fri, 26 Mar 2004 10:40:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6tRU-0005aQ-00 for dhcwg@ietf.org; Fri, 26 Mar 2004 10:40:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6tQl-0005VQ-00 for dhcwg@ietf.org; Fri, 26 Mar 2004 10:39:36 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B6tPo-0005Ig-00 for dhcwg@ietf.org; Fri, 26 Mar 2004 10:38:36 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 26 Mar 2004 07:44:42 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2QFc3Ue001468 for ; Fri, 26 Mar 2004 07:38:03 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-120.cisco.com [10.86.242.120]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHD15331; Fri, 26 Mar 2004 10:38:00 -0500 (EST) Message-Id: <4.3.2.7.2.20040326103738.01fa1bd8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 26 Mar 2004 10:37:58 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_75882363==_" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] *DRAFT* minutes from WG meeting in Seoul (2nd try) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --=====================_75882363==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Please review and respond with additions, corrections and deletions by Friday, 3/26. - Ralph Minutes Review of agenda. No changes. DHCP Option for Proxy Server Configuration Technical discussion; ready for WG last call? Vijay gave a short review of his draft: this option sends a list of proxy servers and ports to a client. ~8 WG members had read the draft. The chair asked about the difference between this option and existing DHCP options for carrying lists of servers; for example, WWW and NNTP. Vijay justified proxy server option because it provides port number as well as proxy server address. The WG expressed consensus for WGLC (which will be confirmed on the WG mailing list). Ted Lemon will publish editorial comments during WGLC. The Extended Remote Boot Option for DHCPv4 Technical discussion; ready for WG last call? Vijay gave a short review of his draft: this option gives a list of TFTP servers along with a list of files for each server. ~7 WG members had read the draft. There was discussion that this draft specifies multiple copies of the same option, with different semantics from those specified in RFCxxxx. Also, the list of servers needs to differentiate between IP addresses or FQDNs. There was a suggestion that the servers just be specified as IP addresses, and a suggestion that the file name be specified as a length followed by name string. Another question: what are the semantics of the list of servers in case of an error? Does the client skip to the next server, retry the file, or what? Vijay will revise the draft to eliminate requirement for sub-options and address other comments. There will be no WGLC at this time. Vendor-Identifying Vendor Options for DHCPv4 Technical discussion; ready for WG last call? The author has revised the draft based on discussion at last WG meeting. ~8 WG members have read the draft. There was one question about the vendor identifier, which was eventually recalled to be the enterprise number. There was WG consensus for WGLC (which will be confirmed on the mailing list). Node-Specific Client Identifiers for DHCPv4 Technical discussion; ready for WG last call? The author has revised the draft to simplify the generation of the DHCPv4 client identifier to match the DHCPv6 mechanism exactly. There was WG consensus for WGLC (which will be confirmed on the mailing list). Rapid Commit Option for DHCPv4 Technical discussion; ready for WG last call? The author gave a short presentation about this mechanism, which allows two message exchange in DHCPv4 (modeled on two message exchange in DHCPv6). No comments from WG. WG consensus for WGLC (which will be confirmed on the mailing list). Ted Lemon to publish editorial comments during WGLC. DHCPv6 Support for Remote Boot Technical discussion; ready for WG last call? The author gave a short presentation about this draft. This option may be impacted by dual-stack problem resolution. This option will not be affected by the multiple copies issue in the DHCPv4 option. Author to revise for editorial issues and for consistency (where possible) with similar DHCPv4 option. No WGLC at this time. Configured Tunnel End Point Option for DHCPv6 Technical discussion; ready for WG last call? The author gave a short introduction to this option. The WG expressed consensus that this option is intended for configuring routers, which is out-of-scope. The Internet Draft will be dropped as WG work item (which will be confirmed on the mailing list). Reclassifying DHCPv4 Options Technical discussion; ready for WG last call? There was no comment from WG and the WG expressed consensus for WGLC (which will be configrmed on the mailing list). DHCPv4 Support for Conf. IPv6-in-IPv4 Tunnels Accept as WG work item? The author gave a short presentation about the option. ~8 WG members had read this draft. There was some discussion of the draft on the mailing list prior to the WG meeting. The author will publish a revised draft based on those comments. The draft will be reviewed by the v6ops WG; the chair will contact the v6ops WG chairs to determine how to proceed. The WG also needs to confirm it fits in dhc WG charter. The draft was not accepted as WG work item at this time. Micro-block IP Addr. Alloc. With DHCP Proxy Server Accept as WG work item? The author gave a short presentation about the option. It fits in dhc WG charter under "address assignment". The chair will arrange for a discussion to reconcile this option with DHCPv6 prefix delegation and earlier ODAP work. The draft was not accepted as WG work item at this time. Vendor-Specific Suboption for the DHCP RAIO Ted Lemon expressed concern that this option will lead to unstandardized RAIO sub-options. The WG expressed consensus to accept as WG work item at this time (which will be confirmed on the mailing list). Renumbering Requirements for Stateless DHCPv6 This draft defines requirements for updating configuration information obtained through the Information-Request message ("stateless DHCPv6"). There was a comment that the security sectino could be clearer. The WG charter needs to be updated before the WG takes on this work. The WG expressed consensus to accept this draft as a WG work item (pending charter update; will be confirmed on miling list). Lifetime Option for DHCPv6 The author gave a short presentation about the draft. This option is a solution for the renumbering problem. The chair asked if other conditions under which a host performs an Information-Request under other conditions like getting a new prefix in an RA. The WG charter needs to be updated before the WG takes on this work. The WG expressed consensus to accept this draft as a WG work item (pending charter update; will be confirmed on miling list). Multicast Reconf. Protocol for Stateless DHCPv6 Accept as WG work item? The author gave a short presentation about the draft. This option is another solution for the renumbering problem, which is especially applicable to unplanned changes. The chair confirmed that there are two components: one that describes how hosts respond to the receonfigure message and one that describes how to trigger the router to send the reconfigure messages. Margaret Wassserman will take some concerns to the dhcwg mailing list. The WG compared this draft with the previous (lifetime option) draft; the WG consensus was that the two options are sufficiently different that they attack different problems. The WG charter needs to be updated before the WG takes on this work. The WG is very interested in this work, but ID was not accepted as WG work item. (restart at 2:05hrs in) IPv4 and IPv6 Dual-Stack Issues for DHCPv6 Stig Venaas gave an introduction to the problem based on draft-chown-dhc-dual-stack-00; this document also proposes some solutions. kre remarked that title is all wrong; the draft really discusses problem of accepting configuration from multiple interfaces. An alternative viewpoint is that information from two separate interfaces is different from having to make two answers to get all the information required. It may be possible to solve the dual-stack problem without solving the more general problem of getting information from multiple sources. The WG expressed consensus to accept this document as a WG work item (pending charter update; will confirm on mailing list). Update of dhc WG charter "Par. n" refers to the nth paragraph in the current dhc WG charter. Par. 1 - OK Par. 2 - OK Par. 3 - work in progress (security); Droms to ask design team about progress Par. 4 - work in progress; design team (Hibbs, chair) reviewing RFC 2131 The WG agreed that the list of drafts will be dropped from the charter; inactive IDs to be explicitly dropped from WG work items New charter items: * Stateless DHCpv6 renumbering () * Dual stack issues * DHCP proxy architecture - Narten to discuss with WG chair before adding to charter The WG chair will write up text for each of the three items and the WG will discuss the text on the mailing list Update on IPR issue with two drafts This agenda item was overtaken events; WG to review three new RFCs: RFC 3667, RFC 3668, RFC 3669: and discuss IPR issues on dhcwg mailing list. --=====================_75882363==_ Content-Type: text/plain; name="dhcwg-mtg-minutes.txt"; x-mac-type="42494E41"; x-mac-creator="74747874" Content-Disposition: attachment; filename="dhcwg-mtg-minutes.txt" Content-Transfer-Encoding: base64 TWludXRlcwoKUmV2aWV3IG9mIGFnZW5kYS4gIE5vIGNoYW5nZXMuCgpESENQIE9wdGlvbiBmb3Ig UHJveHkgU2VydmVyIENvbmZpZ3VyYXRpb24gCiAgPGRyYWZ0LWlldGYtZGhjLXByb3h5c2VydmVy LW9wdC0wMD4KICBUZWNobmljYWwgZGlzY3Vzc2lvbjsgcmVhZHkgZm9yIFdHIGxhc3QgY2FsbD8K CiAgVmlqYXkgZ2F2ZSBhIHNob3J0IHJldmlldyBvZiBoaXMgZHJhZnQ6IHRoaXMgb3B0aW9uIHNl bmRzIGEgbGlzdCBvZgogIHByb3h5IHNlcnZlcnMgYW5kIHBvcnRzIHRvIGEgY2xpZW50LiAgfjgg V0cgbWVtYmVycyBoYWQgcmVhZCB0aGUKICBkcmFmdC4gIFRoZSBjaGFpciBhc2tlZCBhYm91dCB0 aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoaXMgb3B0aW9uIGFuZAogIGV4aXN0aW5nIERIQ1Agb3B0 aW9ucyBmb3IgY2FycnlpbmcgbGlzdHMgb2Ygc2VydmVyczsgZm9yIGV4YW1wbGUsCiAgV1dXIGFu ZCBOTlRQLiAgVmlqYXkganVzdGlmaWVkIHByb3h5IHNlcnZlciBvcHRpb24gYmVjYXVzZSBpdAog IHByb3ZpZGVzIHBvcnQgbnVtYmVyIGFzIHdlbGwgYXMgcHJveHkgc2VydmVyIGFkZHJlc3MuICBU aGUgV0cKICBleHByZXNzZWQgY29uc2Vuc3VzIGZvciBXR0xDICh3aGljaCB3aWxsIGJlIGNvbmZp cm1lZCBvbiB0aGUgV0cKICBtYWlsaW5nIGxpc3QpLiAgVGVkIExlbW9uIHdpbGwgcHVibGlzaCBl ZGl0b3JpYWwgY29tbWVudHMgZHVyaW5nCiAgV0dMQy4KCgpUaGUgRXh0ZW5kZWQgUmVtb3RlIEJv b3QgT3B0aW9uIGZvciBESENQdjQKICA8ZHJhZnQtaWV0Zi1kaGMtb3B0LWV4dHJib290LTAwPgog IFRlY2huaWNhbCBkaXNjdXNzaW9uOyByZWFkeSBmb3IgV0cgbGFzdCBjYWxsPwoKICBWaWpheSBn YXZlIGEgc2hvcnQgcmV2aWV3IG9mIGhpcyBkcmFmdDogdGhpcyBvcHRpb24gZ2l2ZXMgYSBsaXN0 IG9mCiAgVEZUUCBzZXJ2ZXJzIGFsb25nIHdpdGggYSBsaXN0IG9mIGZpbGVzIGZvciBlYWNoIHNl cnZlci4gIH43IFdHCiAgbWVtYmVycyBoYWQgcmVhZCB0aGUgZHJhZnQuICBUaGVyZSB3YXMgZGlz Y3Vzc2lvbiB0aGF0IHRoaXMgZHJhZnQKICBzcGVjaWZpZXMgbXVsdGlwbGUgY29waWVzIG9mIHRo ZSBzYW1lIG9wdGlvbiwgd2l0aCBkaWZmZXJlbnQKICBzZW1hbnRpY3MgZnJvbSB0aG9zZSBzcGVj aWZpZWQgaW4gUkZDeHh4eC4gIEFsc28sIHRoZSBsaXN0IG9mCiAgc2VydmVycyBuZWVkcyB0byBk aWZmZXJlbnRpYXRlIGJldHdlZW4gSVAgYWRkcmVzc2VzIG9yIEZRRE5zLiAgVGhlcmUKICB3YXMg YSBzdWdnZXN0aW9uIHRoYXQgdGhlIHNlcnZlcnMganVzdCBiZSBzcGVjaWZpZWQgYXMgSVAgYWRk cmVzc2VzLAogIGFuZCBhIHN1Z2dlc3Rpb24gdGhhdCB0aGUgZmlsZSBuYW1lIGJlIHNwZWNpZmll ZCBhcyBhIGxlbmd0aAogIGZvbGxvd2VkIGJ5IG5hbWUgc3RyaW5nLiAgQW5vdGhlciBxdWVzdGlv bjogd2hhdCBhcmUgdGhlIHNlbWFudGljcwogIG9mIHRoZSBsaXN0IG9mIHNlcnZlcnMgaW4gY2Fz ZSBvZiBhbiBlcnJvcj8gIERvZXMgdGhlIGNsaWVudCBza2lwIHRvCiAgdGhlIG5leHQgc2VydmVy LCByZXRyeSB0aGUgZmlsZSwgb3Igd2hhdD8gIFZpamF5IHdpbGwgcmV2aXNlIHRoZQogIGRyYWZ0 IHRvIGVsaW1pbmF0ZSByZXF1aXJlbWVudCBmb3Igc3ViLW9wdGlvbnMgYW5kIGFkZHJlc3Mgb3Ro ZXIKICBjb21tZW50cy4gIFRoZXJlIHdpbGwgYmUgbm8gV0dMQyBhdCB0aGlzIHRpbWUuCgoKVmVu ZG9yLUlkZW50aWZ5aW5nIFZlbmRvciBPcHRpb25zIGZvciBESENQdjQKICA8ZHJhZnQtaWV0Zi1k aGMtdmVuZG9yLTAxPgogIFRlY2huaWNhbCBkaXNjdXNzaW9uOyByZWFkeSBmb3IgV0cgbGFzdCBj YWxsPwoKICBUaGUgYXV0aG9yIGhhcyByZXZpc2VkIHRoZSBkcmFmdCBiYXNlZCBvbiBkaXNjdXNz aW9uIGF0IGxhc3QgV0cKICBtZWV0aW5nLiAgfjggV0cgbWVtYmVycyBoYXZlIHJlYWQgdGhlIGRy YWZ0LiAgVGhlcmUgd2FzIG9uZSBxdWVzdGlvbgogIGFib3V0IHRoZSB2ZW5kb3IgaWRlbnRpZmll ciwgd2hpY2ggd2FzIGV2ZW50dWFsbHkgcmVjYWxsZWQgdG8gYmUgdGhlCiAgZW50ZXJwcmlzZSBu dW1iZXIuICBUaGVyZSB3YXMgV0cgY29uc2Vuc3VzIGZvciBXR0xDICh3aGljaCB3aWxsIGJlCiAg Y29uZmlybWVkIG9uIHRoZSBtYWlsaW5nIGxpc3QpLgoKCk5vZGUtU3BlY2lmaWMgQ2xpZW50IElk ZW50aWZpZXJzIGZvciBESENQdjQKICA8ZHJhZnQtaWV0Zi1kaGMtMzMxNWlkLWZvci12NC0wMT4K ICBUZWNobmljYWwgZGlzY3Vzc2lvbjsgcmVhZHkgZm9yIFdHIGxhc3QgY2FsbD8KCiAgVGhlIGF1 dGhvciBoYXMgcmV2aXNlZCB0aGUgZHJhZnQgdG8gc2ltcGxpZnkgdGhlIGdlbmVyYXRpb24gb2Yg dGhlCiAgREhDUHY0IGNsaWVudCBpZGVudGlmaWVyIHRvIG1hdGNoIHRoZSBESENQdjYgbWVjaGFu aXNtIGV4YWN0bHkuCiAgVGhlcmUgd2FzIFdHIGNvbnNlbnN1cyBmb3IgV0dMQyAod2hpY2ggd2ls bCBiZSBjb25maXJtZWQgb24gdGhlCiAgbWFpbGluZyBsaXN0KS4KCgpSYXBpZCBDb21taXQgT3B0 aW9uIGZvciBESENQdjQKICA8ZHJhZnQtaWV0Zi1kaGMtcmFwaWQtY29tbWl0LW9wdC0wMD4KICBU ZWNobmljYWwgZGlzY3Vzc2lvbjsgcmVhZHkgZm9yIFdHIGxhc3QgY2FsbD8KCiAgVGhlIGF1dGhv ciBnYXZlIGEgc2hvcnQgcHJlc2VudGF0aW9uIGFib3V0IHRoaXMgbWVjaGFuaXNtLCB3aGljaAog IGFsbG93cyB0d28gbWVzc2FnZSBleGNoYW5nZSBpbiBESENQdjQgKG1vZGVsZWQgb24gdHdvIG1l c3NhZ2UKICBleGNoYW5nZSBpbiBESENQdjYpLiAgTm8gY29tbWVudHMgZnJvbSBXRy4gIFdHIGNv bnNlbnN1cyBmb3IgV0dMQwogICh3aGljaCB3aWxsIGJlIGNvbmZpcm1lZCBvbiB0aGUgbWFpbGlu ZyBsaXN0KS4gIFRlZCBMZW1vbiB0byBwdWJsaXNoCiAgZWRpdG9yaWFsIGNvbW1lbnRzIGR1cmlu ZyBXR0xDLgoKCkRIQ1B2NiBTdXBwb3J0IGZvciBSZW1vdGUgQm9vdAogIDxkcmFmdC1pZXRmLWRo Yy1kaGNwdjYtb3B0LXJib290LTAwPgogIFRlY2huaWNhbCBkaXNjdXNzaW9uOyByZWFkeSBmb3Ig V0cgbGFzdCBjYWxsPwoKICBUaGUgYXV0aG9yIGdhdmUgYSBzaG9ydCBwcmVzZW50YXRpb24gYWJv dXQgdGhpcyBkcmFmdC4gIFRoaXMgb3B0aW9uCiAgbWF5IGJlIGltcGFjdGVkIGJ5IGR1YWwtc3Rh Y2sgcHJvYmxlbSByZXNvbHV0aW9uLiAgVGhpcyBvcHRpb24gd2lsbAogIG5vdCBiZSBhZmZlY3Rl ZCBieSB0aGUgbXVsdGlwbGUgY29waWVzIGlzc3VlIGluIHRoZSBESENQdjQgb3B0aW9uLgogIEF1 dGhvciB0byByZXZpc2UgZm9yIGVkaXRvcmlhbCBpc3N1ZXMgYW5kIGZvciBjb25zaXN0ZW5jeSAo d2hlcmUKICBwb3NzaWJsZSkgd2l0aCBzaW1pbGFyIERIQ1B2NCBvcHRpb24uICBObyBXR0xDIGF0 IHRoaXMgdGltZS4KCgpDb25maWd1cmVkIFR1bm5lbCBFbmQgUG9pbnQgT3B0aW9uIGZvciBESENQ djYKICA8ZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LWN0ZXAtb3B0LTAxPgogIFRlY2huaWNhbCBkaXNj dXNzaW9uOyByZWFkeSBmb3IgV0cgbGFzdCBjYWxsPwoKICBUaGUgYXV0aG9yIGdhdmUgYSBzaG9y dCBpbnRyb2R1Y3Rpb24gdG8gdGhpcyBvcHRpb24uICBUaGUgV0cKICBleHByZXNzZWQgY29uc2Vu c3VzIHRoYXQgdGhpcyBvcHRpb24gaXMgaW50ZW5kZWQgZm9yIGNvbmZpZ3VyaW5nCiAgcm91dGVy cywgd2hpY2ggaXMgb3V0LW9mLXNjb3BlLiAgVGhlIEludGVybmV0IERyYWZ0IHdpbGwgYmUgZHJv cHBlZAogIGFzIFdHIHdvcmsgaXRlbSAod2hpY2ggd2lsbCBiZSBjb25maXJtZWQgb24gdGhlIG1h aWxpbmcgbGlzdCkuCgoKUmVjbGFzc2lmeWluZyBESENQdjQgT3B0aW9ucwogIDxkcmFmdC1pZXRm LWRoYy1yZWNsYXNzaWZ5LW9wdGlvbnMtMDA+CiAgVGVjaG5pY2FsIGRpc2N1c3Npb247IHJlYWR5 IGZvciBXRyBsYXN0IGNhbGw/CgogIFRoZXJlIHdhcyBubyBjb21tZW50IGZyb20gV0cgYW5kIHRo ZSBXRyBleHByZXNzZWQgY29uc2Vuc3VzIGZvcgogIFdHTEMgKHdoaWNoIHdpbGwgYmUgY29uZmln cm1lZCBvbiB0aGUgbWFpbGluZyBsaXN0KS4KCgpESENQdjQgU3VwcG9ydCBmb3IgQ29uZi4gSVB2 Ni1pbi1JUHY0IFR1bm5lbHMKICA8ZHJhZnQtZGFuaWVsLWRoYy1pcHY2aW40LXR1bm5lbHMtMDA+ CiAgQWNjZXB0IGFzIFdHIHdvcmsgaXRlbT8KCiAgVGhlIGF1dGhvciBnYXZlIGEgc2hvcnQgcHJl c2VudGF0aW9uIGFib3V0IHRoZSBvcHRpb24uICB+OCBXRwogIG1lbWJlcnMgaGFkIHJlYWQgdGhp cyBkcmFmdC4gIFRoZXJlIHdhcyBzb21lIGRpc2N1c3Npb24gb2YgdGhlIGRyYWZ0CiAgb24gdGhl IG1haWxpbmcgbGlzdCBwcmlvciB0byB0aGUgV0cgbWVldGluZy4gIFRoZSBhdXRob3Igd2lsbAog IHB1Ymxpc2ggYSByZXZpc2VkIGRyYWZ0IGJhc2VkIG9uIHRob3NlIGNvbW1lbnRzLiBUaGUgZHJh ZnQgd2lsbCBiZQogIHJldmlld2VkIGJ5IHRoZSB2Nm9wcyBXRzsgdGhlIGNoYWlyIHdpbGwgY29u dGFjdCB0aGUgdjZvcHMgV0cgY2hhaXJzCiAgdG8gZGV0ZXJtaW5lIGhvdyB0byBwcm9jZWVkLiAg VGhlIFdHIGFsc28gbmVlZHMgdG8gY29uZmlybSBpdCBmaXRzCiAgaW4gZGhjIFdHIGNoYXJ0ZXIu ICBUaGUgZHJhZnQgd2FzIG5vdCBhY2NlcHRlZCBhcyBXRyB3b3JrIGl0ZW0gYXQKICB0aGlzIHRp bWUuCgoKTWljcm8tYmxvY2sgSVAgQWRkci4gQWxsb2MuIFdpdGggREhDUCBQcm94eSBTZXJ2ZXIK ICA8ZHJhZnQtc2hlbi1kaGMtYmxvY2stYWxsb2MtMDE+CiAgQWNjZXB0IGFzIFdHIHdvcmsgaXRl bT8KCiAgVGhlIGF1dGhvciBnYXZlIGEgc2hvcnQgcHJlc2VudGF0aW9uIGFib3V0IHRoZSBvcHRp b24uICBJdCBmaXRzIGluCiAgZGhjIFdHIGNoYXJ0ZXIgdW5kZXIgImFkZHJlc3MgYXNzaWdubWVu dCIuICBUaGUgY2hhaXIgd2lsbCBhcnJhbmdlCiAgZm9yIGEgZGlzY3Vzc2lvbiB0byByZWNvbmNp bGUgdGhpcyBvcHRpb24gd2l0aCBESENQdjYgcHJlZml4CiAgZGVsZWdhdGlvbiBhbmQgZWFybGll ciBPREFQIHdvcmsuICBUaGUgZHJhZnQgd2FzIG5vdCBhY2NlcHRlZCBhcyBXRwogIHdvcmsgaXRl bSBhdCB0aGlzIHRpbWUuCgoKVmVuZG9yLVNwZWNpZmljIFN1Ym9wdGlvbiBmb3IgdGhlIERIQ1Ag UkFJTwogIDxkcmFmdC1zdGFwcC1kaGMtdmVuZG9yLXN1Ym9wdGlvbi0wMD4KCiAgVGVkIExlbW9u IGV4cHJlc3NlZCBjb25jZXJuIHRoYXQgdGhpcyBvcHRpb24gd2lsbCBsZWFkIHRvCiAgdW5zdGFu ZGFyZGl6ZWQgUkFJTyBzdWItb3B0aW9ucy4gIFRoZSBXRyBleHByZXNzZWQgY29uc2Vuc3VzIHRv CiAgYWNjZXB0IGFzIFdHIHdvcmsgaXRlbSBhdCB0aGlzIHRpbWUgKHdoaWNoIHdpbGwgYmUgY29u ZmlybWVkIG9uIHRoZQogIG1haWxpbmcgbGlzdCkuCgoKUmVudW1iZXJpbmcgUmVxdWlyZW1lbnRz IGZvciBTdGF0ZWxlc3MgREhDUHY2CiAgPGRyYWZ0LWNob3duLWRoYy1zdGF0ZWxlc3MtZGhjcHY2 LXJlbnVtYmVyaW5nLTAwPgoKICBUaGlzIGRyYWZ0IGRlZmluZXMgcmVxdWlyZW1lbnRzIGZvciB1 cGRhdGluZyBjb25maWd1cmF0aW9uCiAgaW5mb3JtYXRpb24gb2J0YWluZWQgdGhyb3VnaCB0aGUg SW5mb3JtYXRpb24tUmVxdWVzdCBtZXNzYWdlCiAgKCJzdGF0ZWxlc3MgREhDUHY2IikuICBUaGVy ZSB3YXMgYSBjb21tZW50IHRoYXQgdGhlIHNlY3VyaXR5IHNlY3Rpbm8KICBjb3VsZCBiZSBjbGVh cmVyLiAgVGhlIFdHIGNoYXJ0ZXIgbmVlZHMgdG8gYmUgdXBkYXRlZCBiZWZvcmUgdGhlIFdHCiAg dGFrZXMgb24gdGhpcyB3b3JrLiAgVGhlIFdHIGV4cHJlc3NlZCBjb25zZW5zdXMgdG8gYWNjZXB0 IHRoaXMgZHJhZnQKICBhcyBhIFdHIHdvcmsgaXRlbSAocGVuZGluZyBjaGFydGVyIHVwZGF0ZTsg d2lsbCBiZSBjb25maXJtZWQgb24KICBtaWxpbmcgbGlzdCkuCgoKTGlmZXRpbWUgT3B0aW9uIGZv ciBESENQdjYKICA8ZHJhZnQtdmVuYWFzLWRoYy1saWZldGltZS0wMT4KCiAgVGhlIGF1dGhvciBn YXZlIGEgc2hvcnQgcHJlc2VudGF0aW9uIGFib3V0IHRoZSBkcmFmdC4gIFRoaXMgb3B0aW9uCiAg aXMgYSBzb2x1dGlvbiBmb3IgdGhlIHJlbnVtYmVyaW5nIHByb2JsZW0uIFRoZSBjaGFpciBhc2tl ZCBpZiBvdGhlcgogIGNvbmRpdGlvbnMgdW5kZXIgd2hpY2ggYSBob3N0IHBlcmZvcm1zIGFuIElu Zm9ybWF0aW9uLVJlcXVlc3QgdW5kZXIKICBvdGhlciBjb25kaXRpb25zIGxpa2UgZ2V0dGluZyBh IG5ldyBwcmVmaXggaW4gYW4gUkEuICBUaGUgV0cgY2hhcnRlcgogIG5lZWRzIHRvIGJlIHVwZGF0 ZWQgYmVmb3JlIHRoZSBXRyB0YWtlcyBvbiB0aGlzIHdvcmsuICBUaGUgV0cKICBleHByZXNzZWQg Y29uc2Vuc3VzIHRvIGFjY2VwdCB0aGlzIGRyYWZ0IGFzIGEgV0cgd29yayBpdGVtIChwZW5kaW5n CiAgY2hhcnRlciB1cGRhdGU7IHdpbGwgYmUgY29uZmlybWVkIG9uIG1pbGluZyBsaXN0KS4KCgpN dWx0aWNhc3QgUmVjb25mLiBQcm90b2NvbCBmb3IgU3RhdGVsZXNzIERIQ1B2NgogIDxkcmFmdC12 aWpheS1kaGMtZGhjcHY2LW1jYXN0LXJlY29uZi0wMD4KICBBY2NlcHQgYXMgV0cgd29yayBpdGVt PwoKICBUaGUgYXV0aG9yIGdhdmUgYSBzaG9ydCBwcmVzZW50YXRpb24gYWJvdXQgdGhlIGRyYWZ0 LiAgVGhpcyBvcHRpb24KICBpcyBhbm90aGVyIHNvbHV0aW9uIGZvciB0aGUgcmVudW1iZXJpbmcg cHJvYmxlbSwgd2hpY2ggaXMgZXNwZWNpYWxseQogIGFwcGxpY2FibGUgdG8gdW5wbGFubmVkIGNo YW5nZXMuICBUaGUgY2hhaXIgY29uZmlybWVkIHRoYXQgdGhlcmUgYXJlCiAgdHdvIGNvbXBvbmVu dHM6IG9uZSB0aGF0IGRlc2NyaWJlcyBob3cgaG9zdHMgcmVzcG9uZCB0byB0aGUKICByZWNlb25m aWd1cmUgbWVzc2FnZSBhbmQgb25lIHRoYXQgZGVzY3JpYmVzIGhvdyB0byB0cmlnZ2VyIHRoZQog IHJvdXRlciB0byBzZW5kIHRoZSByZWNvbmZpZ3VyZSBtZXNzYWdlcy4gIE1hcmdhcmV0IFdhc3Nz ZXJtYW4gd2lsbAogIHRha2Ugc29tZSBjb25jZXJucyB0byB0aGUgZGhjd2cgbWFpbGluZyBsaXN0 LiAgVGhlIFdHIGNvbXBhcmVkIHRoaXMKICBkcmFmdCB3aXRoIHRoZSBwcmV2aW91cyAobGlmZXRp bWUgb3B0aW9uKSBkcmFmdDsgdGhlIFdHIGNvbnNlbnN1cwogIHdhcyB0aGF0IHRoZSB0d28gb3B0 aW9ucyBhcmUgc3VmZmljaWVudGx5IGRpZmZlcmVudCB0aGF0IHRoZXkgYXR0YWNrCiAgZGlmZmVy ZW50IHByb2JsZW1zLiAgVGhlIFdHIGNoYXJ0ZXIgbmVlZHMgdG8gYmUgdXBkYXRlZCBiZWZvcmUg dGhlCiAgV0cgdGFrZXMgb24gdGhpcyB3b3JrLiAgVGhlIFdHIGlzIHZlcnkgaW50ZXJlc3RlZCBp biB0aGlzIHdvcmssIGJ1dAogIElEIHdhcyBub3QgYWNjZXB0ZWQgYXMgV0cgd29yayBpdGVtLgoK KHJlc3RhcnQgYXQgMjowNWhycyBpbikKCklQdjQgYW5kIElQdjYgRHVhbC1TdGFjayBJc3N1ZXMg Zm9yIERIQ1B2NgogIDxkcmFmdC1jaG93bi1kaGMtZHVhbC1zdGFjay0wMD4KCiAgU3RpZyBWZW5h YXMgZ2F2ZSBhbiBpbnRyb2R1Y3Rpb24gdG8gdGhlIHByb2JsZW0gYmFzZWQgb24KICBkcmFmdC1j aG93bi1kaGMtZHVhbC1zdGFjay0wMDsgdGhpcyBkb2N1bWVudCBhbHNvIHByb3Bvc2VzIHNvbWUK ICBzb2x1dGlvbnMuICBrcmUgcmVtYXJrZWQgdGhhdCB0aXRsZSBpcyBhbGwgd3Jvbmc7IHRoZSBk cmFmdCByZWFsbHkKICBkaXNjdXNzZXMgcHJvYmxlbSBvZiBhY2NlcHRpbmcgY29uZmlndXJhdGlv biBmcm9tIG11bHRpcGxlCiAgaW50ZXJmYWNlcy4gIEFuIGFsdGVybmF0aXZlIHZpZXdwb2ludCBp cyB0aGF0IGluZm9ybWF0aW9uIGZyb20gdHdvCiAgc2VwYXJhdGUgaW50ZXJmYWNlcyBpcyBkaWZm ZXJlbnQgZnJvbSBoYXZpbmcgdG8gbWFrZSB0d28gYW5zd2VycyB0bwogIGdldCBhbGwgdGhlIGlu Zm9ybWF0aW9uIHJlcXVpcmVkLiAgSXQgbWF5IGJlIHBvc3NpYmxlIHRvIHNvbHZlIHRoZQogIGR1 YWwtc3RhY2sgcHJvYmxlbSB3aXRob3V0IHNvbHZpbmcgdGhlIG1vcmUgZ2VuZXJhbCBwcm9ibGVt IG9mCiAgZ2V0dGluZyBpbmZvcm1hdGlvbiBmcm9tIG11bHRpcGxlIHNvdXJjZXMuICBUaGUgV0cg ZXhwcmVzc2VkCiAgY29uc2Vuc3VzIHRvIGFjY2VwdCB0aGlzIGRvY3VtZW50IGFzIGEgV0cgd29y ayBpdGVtIChwZW5kaW5nIGNoYXJ0ZXIKICB1cGRhdGU7IHdpbGwgY29uZmlybSBvbiBtYWlsaW5n IGxpc3QpLgoKClVwZGF0ZSBvZiBkaGMgV0cgY2hhcnRlcgoKICAiUGFyLiBuIiByZWZlcnMgdG8g dGhlIG50aCBwYXJhZ3JhcGggaW4gdGhlIGN1cnJlbnQgZGhjIFdHIGNoYXJ0ZXIuCgogIFBhci4g MSAtIE9LCiAgUGFyLiAyIC0gT0sKICBQYXIuIDMgLSB3b3JrIGluIHByb2dyZXNzIChzZWN1cml0 eSk7IERyb21zIHRvIGFzayBkZXNpZ24gdGVhbQogICAgICAgICAgIGFib3V0IHByb2dyZXNzCiAg UGFyLiA0IC0gd29yayBpbiBwcm9ncmVzczsgZGVzaWduIHRlYW0gKEhpYmJzLCBjaGFpcikgcmV2 aWV3aW5nIFJGQwogICAgICAgICAgIDIxMzEKCiAgVGhlIFdHIGFncmVlZCB0aGF0IHRoZSBsaXN0 IG9mIGRyYWZ0cyB3aWxsIGJlIGRyb3BwZWQgZnJvbSB0aGUKICAgIGNoYXJ0ZXI7IGluYWN0aXZl IElEcyB0byBiZSBleHBsaWNpdGx5IGRyb3BwZWQgZnJvbSBXRyB3b3JrIGl0ZW1zCgogIE5ldyBj aGFydGVyIGl0ZW1zOgogICogU3RhdGVsZXNzIERIQ3B2NiByZW51bWJlcmluZwogICAgKDxkcmFm dC1jaG93bi1kaGMtc3RhdGVsZXNzLWRoY3B2Ni1yZW51bWJlcmluZy0wMD4pCiAgKiBEdWFsIHN0 YWNrIGlzc3VlcyA8ZHJhZnQtY2hvd24tZGhjLWR1YWwtc3RhY2stMDA+CiAgKiBESENQIHByb3h5 IGFyY2hpdGVjdHVyZSAtIE5hcnRlbiB0byBkaXNjdXNzIHdpdGggV0cgY2hhaXIgYmVmb3JlCiAg ICBhZGRpbmcgdG8gY2hhcnRlciAKCiAgVGhlIFdHIGNoYWlyIHdpbGwgd3JpdGUgdXAgdGV4dCBm b3IgZWFjaCBvZiB0aGUgdGhyZWUgaXRlbXMgYW5kIHRoZQogIFdHIHdpbGwgZGlzY3VzcyB0aGUg dGV4dCBvbiB0aGUgbWFpbGluZyBsaXN0CgpVcGRhdGUgb24gSVBSIGlzc3VlIHdpdGggdHdvIGRy YWZ0cwoKICBUaGlzIGFnZW5kYSBpdGVtIHdhcyBvdmVydGFrZW4gZXZlbnRzOyBXRyB0byByZXZp ZXcgdGhyZWUgbmV3IFJGQ3M6CiAgUkZDIDM2NjcsIFJGQyAzNjY4LCBSRkMgMzY2OTogYW5kIGRp c2N1c3MgSVBSIGlzc3VlcyBvbiBkaGN3ZwogIG1haWxpbmcgbGlzdC4KCg== --=====================_75882363==_-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Mar 26 18:13:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24412; Fri, 26 Mar 2004 18:13:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B70VY-0000En-SW; Fri, 26 Mar 2004 18:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B70VH-0000A8-3z for dhcwg@optimus.ietf.org; Fri, 26 Mar 2004 18:12:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24251 for ; Fri, 26 Mar 2004 18:12:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B70VE-0003jR-00 for dhcwg@ietf.org; Fri, 26 Mar 2004 18:12:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B70UC-0003dW-00 for dhcwg@ietf.org; Fri, 26 Mar 2004 18:11:36 -0500 Received: from smtp811.mail.sc5.yahoo.com ([66.163.170.81]) by ietf-mx with smtp (Exim 4.12) id 1B70Ti-0003Y6-00 for dhcwg@ietf.org; Fri, 26 Mar 2004 18:11:06 -0500 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@67.115.135.169 with login) by smtp811.mail.sc5.yahoo.com with SMTP; 26 Mar 2004 23:11:06 -0000 Reply-To: From: "Richard Barr Hibbs" To: "Dhcwg" Date: Fri, 26 Mar 2004 15:18:02 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <4.3.2.7.2.20040324080610.02d99cd0@flask.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [dhcwg] RE: Minutes from 2/23 RFC2131 review conf call (2nd try) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit sorry to have taken so long to reply, but two rounds of eye surgery affected my ability to read.... --Barr > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Wednesday, 24 March 2004 05:06 > > 2. Accept or reject typographic corrections > > The state machine in RFC2131 will be retained. > (1) there was some discussion about whether some messages were sent BEFORE or AFTER transitioning from one state to the other, with no clear consensus; (2) an earlier mailing list discussion about a STOPPED state was not discussed during the conference call; (3) I offered to supply an updated version of the client state transition diagram for discussion that goes to point (1) > 5. Clarification of the Client Identifier > (eliminate suggested format) > > RFC2131bis (as well as RFC2132bis) will specify > that the 'client > identifier' is an opaque string, with one > suggestion that the client > can construct the 'client identifier' as an > htype/address pair. The > server MUST NOT try to interpret the contents of > the 'client > identifier'; in particular, the server will not > try to determine if > the length of the address matches the hardware type. > (1) the conference call did not address Ted's proposal for a 3315-like DUID to be used in place of the suggested format for client identifier: this requires a bit more discussion and should be taken to the mailing list; (2) my memory of our consensus regarding htype and hlen was that a server (and, presumably, a client as well) should not be REQUIRED to verify agreement between htype, hlen, and the contents of client identifier because client identifier is supposed to be opaque: at the same time, the text should strongly suggest that htype, hlen, and chaddr be in agreement so that any intermediate equipment will not wrongly discard packets due to mismatches; (3) we didn't quite agree that the client identifier should be globally unique, despite the advantages of that assertion, but we did nearly agree that RFC2132bis should offer multiple suggestions on how to construct client identifiers as long as the text clearly states that the suggestions are not required behavior. > 8. Can we eliminate the 'sname' and 'file' fields > of the BOOTP packet? > > Because this topic touches on significant changes > to the DHCP specification, it will be the subject > of a separate document. > > Currently, 'siaddr' carries the address of one > boot server, while 'sname' and the TFTP server > name option (66) carry a DNS name. Is there a > requirement for an option that carries a list of > addresses of boot servers? > draft-vijay-dhc-opt-extrboot-00.txt defines a > new option with a list of servers and associated > file names. > (1) generally (but NOT universally) DHCP options use IP addresses rather than DNS names for locating network resources, so which to use is an item for discussion; (2) it's not clear to me from my reading of DOCSIS and other documents that specify the use of the sname and file fields that they would even successfully interoperate with an arbitrary DHCP server because they don't seem to accept option 66 or overlaying the sname and file fields for long lists of options -- definitely a mailing list discussion is needed. > 9. Accept, reject, or further study SHOULD v. MUST changes > > draft-hibbs-dhc-changes-00.txt will be discussed > in detail in the next > conf call. > ...the intent of that draft was to specify minimum documentation requirements for any new I-D that modifies the DHCP protocol or options, so it should be pretty non-controversial (I hope!) _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Mar 26 18:56:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26618; Fri, 26 Mar 2004 18:56:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B71BC-0003pI-3O; Fri, 26 Mar 2004 18:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B71AZ-0003lw-Cr for dhcwg@optimus.ietf.org; Fri, 26 Mar 2004 18:55:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26574 for ; Fri, 26 Mar 2004 18:55:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B71AW-0006nL-00 for dhcwg@ietf.org; Fri, 26 Mar 2004 18:55:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B719c-0006jo-00 for dhcwg@ietf.org; Fri, 26 Mar 2004 18:54:25 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1B718m-0006cL-00 for dhcwg@ietf.org; Fri, 26 Mar 2004 18:53:32 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HV700I04JO30D@mailout3.samsung.com> for dhcwg@ietf.org; Sat, 27 Mar 2004 08:52:51 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HV700GIBJO24B@mailout3.samsung.com> for dhcwg@ietf.org; Sat, 27 Mar 2004 08:52:50 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HV700INAJO1I8@mmp2.samsung.com> for dhcwg@ietf.org; Sat, 27 Mar 2004 08:52:50 +0900 (KST) Date: Sat, 27 Mar 2004 08:53:05 +0900 From: "S. Daniel Park" In-reply-to: <4.3.2.7.2.20040326103738.01fa1bd8@flask.cisco.com> To: "'Ralph Droms'" , dhcwg@ietf.org Cc: "'S. Daniel Park'" Message-id: <00bf01c4138d$7b476710$67cadba8@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/alternative; boundary="Boundary_(ID_q70RYzDpPcccS+hfd71zSw)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_FONT_FACE_BAD,HTML_MESSAGE autolearn=no version=2.60 Subject: [dhcwg] RE: [DHCP Option for Configuring IPv6-over-IPv4 Tunnels]*DRAFT* minutes from WG meeting in Seoul (2nd try) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_q70RYzDpPcccS+hfd71zSw) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT > DHCPv4 Support for Conf. IPv6-in-IPv4 Tunnels > > Accept as WG work item? > >The author gave a short presentation about the option. ~8 WG >members had read this draft. There was some discussion of >the draft on the mailing list prior to the WG meeting. The author will >publish a revised draft based on those comments. The draft will be >reviewed by the v6ops WG; the chair will contact the v6ops >WG chairs to determine how to proceed. The WG also needs to >confirm it fits in dhc WG charter. The draft was not accepted as >WG work item at this time. Regarding this mention, the revised draft is now available and all comments on this draft were from the v6ops WG. http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-02.txt Change log: 1) replaced IPv6-in-IPv4 term. with IPv6-over-IPv4. (by Pekka Savola) [for easy tracking, I didn't change the filename as IPv6over4 so far] 2) reconstructed multiple CTEP option format by single CTEP option format. (by Alain Durand) 3) some text improvement (by Eric Normark) Hope this helps - Daniel (Soohong Daniel Park) - Mobile Platform Laboratory, SAMSUNG Electronics. --Boundary_(ID_q70RYzDpPcccS+hfd71zSw) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT RE: [DHCP Option for Configuring IPv6-over-IPv4 Tunnels]*DRAFT* minutes from WG meeting in Seoul (2nd try)

> DHCPv4 Support for Conf. IPv6-in-IPv4 Tunnels
>    <draft-daniel-dhc-ipv6in4-tunnels-00>
>    Accept as WG work item?
>
>The author gave a short presentation about the option.  ~8 WG
>members had read this draft.  There was some discussion of
>the draft on the mailing list prior to the WG meeting.  The author will
>publish a revised draft based on those comments. The draft will be
>reviewed by the v6ops WG; the chair will contact the v6ops
>WG chairs to determine how to proceed.  The WG also needs to
>confirm it fits in dhc WG charter.  The draft was not accepted as
>WG work item at this time.

Regarding this mention, the revised draft is now available and all
comments on this draft were from the v6ops WG.
http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-02.txt

Change log:
1) replaced IPv6-in-IPv4 term. with IPv6-over-IPv4. (by Pekka Savola)
[for easy tracking, I didn't change the filename as IPv6over4 so far]
2) reconstructed multiple CTEP option format by single CTEP option format. (by Alain Durand)
3) some text improvement (by Eric Normark)


Hope this helps


- Daniel (Soohong Daniel Park)
- Mobile Platform Laboratory, SAMSUNG Electronics.

--Boundary_(ID_q70RYzDpPcccS+hfd71zSw)-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From esqnews@mail.com Sun Mar 28 20:20:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15891 for ; Sun, 28 Mar 2004 20:20:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7lSD-0000Lq-00 for dhc-archive@ietf.org; Sun, 28 Mar 2004 20:20:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7lQp-00009l-00 for dhc-archive@ietf.org; Sun, 28 Mar 2004 20:19:16 -0500 Received: from 200-204-122-237.dsl.telesp.net.br ([200.204.122.237] helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1B7lQ9-00000S-00; Sun, 28 Mar 2004 20:18:35 -0500 From: "Atualidade Brasileira . dpb" To: ccamp-archive@ietf.org Subject: "Trabalho escravo": novo instrumento da demagogia? . bnk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Sun, 28 Mar 2004 20:18:35 -0500 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=10.7 required=5.0 tests=AWL,FORGED_MUA_EUDORA, HTML_40_50,HTML_FONT_BIG,HTML_MESSAGE,MAILTO_SUBJ_REMOVE, MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT,REMOVE_REMOVAL_2WORD, SUBJ_HAS_SPACES,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 0.2 SUBJ_HAS_UNIQ_ID Subject contains a unique ID * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.9 FORGED_MUA_EUDORA Forged mail pretending to be from Eudora * 0.0 AWL AWL: Auto-whitelist adjustment

(ref.: luv) (utilize os links instantâneos para contacto, recebimento de informações, remoção ou subscrição)

 "Trabalho escravo": instrumento da demagogia contra a propriedade?

A Proposta de Emenda Constitucional (PEC) 438/01 prevê a expropriação sumária de fazendas; amanhã, com a brecha constitucional aberta, chegará a hora da expropriação sumária de indústrias e até mesmo de lares, a partir de qualquer denúncia sobre "trabalho escravo"

Caro amigo

* Um novo golpe contra a propriedade privada paira sobre nossas cabeças e poderá ocorrer através de uma reforma à Constituição, com a introdução da ambígua expressão "trabalho escravo".

* A Comissão de Constituição e Justiça da Câmara aprovou a admissibilidade da Proposta de Emenda Constitucional (PEC) 438/01, do Senado, que prevê a desapropriação sumária (sem indenização) da terra onde for constatada a prática do chamado "trabalho escravo" (clique aqui para maiores informações: MaisInformaçãoEmendaConstitucional).

* Para acelerar os debates sobre o "trabalho escravo", o presidente da Câmara instalou Comissão Especial, que terá prazo de 40 sessões para votar a matéria antes de seguir para o Plenário. Os trabalhos da Comissão já começaram em março.

* A simpática bandeira do combate ao "trabalho escravo" será utilizada demagogicamente para expropriações sumárias de fazendas para fins de Reforma Agrária.

* A emenda constitucional poderá criar tal ambigüidade em torno do direito de propriedade, que ficará aberta mais uma fonte de conflitos no meio rural. O MST não espera outra coisa!

* Hoje, a proposta é a expropriação sumária de fazendas. Amanhã, já com a brecha constitucional aberta, chegará a hora da expropriação sumária de indústrias e até mesmo de lares, a partir de uma denúncia sobre "trabalho escravo".

* Levantar este tema "politicamente incorreto" não é agradável. Mas é o próprio futuro do Brasil que está em jogo.

* Caro amigo, coloco-me à sua disposição,sem nenhum ônus de sua parte,um "pacote" de informações para que V.forme uma opinião objetiva a respeito do tema. E, eventualmente, se dirija de maneira respeitosa, mas firme, aos ilustres deputados membros da Comissão que trata do assunto, através de um link que lhe proporciono a seguir (para acessá-lo, basta clicar em: LinkParaEnviarMensagemADeputados).

* Na verdade, o que o Brasil precisa é de uma reforma de suas leis trabalhistas, reforma que venha atender as múltiplas atividades econômicas, sobretudo às do campo, com suas peculiaridades; leis que facilitem a geração de empregos e a legalização de milhões de trabalhadores informais.

* Gostaria, se possível, ouvir sugestões, receber ponderações e mesmo críticas de sua parte a respeito deste momentoso assunto. Temo ter interpretado mal informações da imprensa e do âmbito legislativo, áreas nas quais trabalho como jornalista há anos. Estaria sendo exagerado ou pessimista?

* Finalmente, declaro que não possuo um palmo de terra e que faço esta divulgação exercendo meu direito e minha obrigação de informar, sem qualquer vantagem pessoal.

Mais uma vez, ao seu inteiro dispor para qualquer esclarecimento.

Atenciosamente,

Nelson Barretto / Jornalista

P.S.

* No ano passado, após percorrer 20 mil quilômetros pelo Brasil e visitar 60 "assentamentos" de Reforma Agrária, inclusive aqueles tidos pelo governo como "modelos", constatei o desastre e o fracasso da Reforma Agrária que vem sendo feita. Com o material colhido, publiquei o livro "Reforma Agrária: o mito e a realidade", já com 4 edições. Os fatos ali narrados não foram desmentidos pelo INCRA, nem pelo MST nem ainda pelo ministério da Reforma Agrária.

* Como gostaria, desta vez, de ver minhas apreensões dissipadas sobre a reforma constitucional que se prepara! O combate ao "trabalho escravo" é bandeira mais que simpática. Mas, ao meu ver, não nas mãos da demagogia agro-reformista.

LINKS DISPONÍVEIS:

Atualidade:Concordo-VisãoObjetiva

Atualidade:EmTermos-VisãoExagerada

Atualidade:Discordo-VisãoTendenciosa

Atualidade:DesejoReceberGratuitamenteMaisInformações

Atualidade:DesejoContatoTelefonico

LinkParaEnviarMensagemADeputados

Atualidade:DesejoReceberLivroBarrettoSobreReformaAgrária

Atualidade:SubscreverAmigos

Atualidade:RemoverImediatamente

A retransmissão desta mensagem é de exclusiva responsabilidade de Ferreira-Passos, Atualidade Brasileira (RJ)

 From dhcwg-admin@ietf.org Tue Mar 30 20:20:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14914; Tue, 30 Mar 2004 20:20:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8UOf-0001lm-FY; Tue, 30 Mar 2004 20:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8UOc-0001kv-6K for dhcwg@optimus.ietf.org; Tue, 30 Mar 2004 20:19:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14898 for ; Tue, 30 Mar 2004 20:19:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8UOa-000522-00 for dhcwg@ietf.org; Tue, 30 Mar 2004 20:19:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8UNh-0004xL-00 for dhcwg@ietf.org; Tue, 30 Mar 2004 20:19:01 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B8UN3-0004q7-00 for dhcwg@ietf.org; Tue, 30 Mar 2004 20:18:21 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 30 Mar 2004 17:25:20 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2V1HmUe014213; Tue, 30 Mar 2004 17:17:49 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-39.cisco.com [10.86.240.39]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHF89653; Tue, 30 Mar 2004 20:17:47 -0500 (EST) Message-Id: <4.3.2.7.2.20040330121427.0257b1e8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Mar 2004 12:23:49 -0500 To: raj@cisco.com, athenmoz@cisco.com, mjs@cisco.com From: Ralph Droms Cc: dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20040122113702.0290c2e0@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Re: IPR claims for Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Seems like there's some background work to do to move draft-ietf-dhc-subscriber-id-05.txt along... RFC3667, RFC3668 and RFC3669 are the latest specifications for document requirements and the IETF IPR process. There is some new boilerplate required by RFC3667. So, a first step would be to publish a revision of draft-ietf-dhc-subscriber-id-05.txt that includes the new boilerplate. There is a new revision of xml2rfc that will produce the required boilerplate. The second step will be for all of us to review the new RFCs to make sure we're all up to speed on the new specifications. I don't know that there is any specific impact of these documents - I've skimmed them all but haven't reviewed them in detail. Once the revision of draft-ietf-dhc-subscriber-id-05.txt has been published, I will go back to the dhc WG to get consensus that we can progress draft-ietf-dhc-subscriber-id-XX with the new boilerplate and the current IPR statement from PacketFront. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 31 13:27:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05908; Wed, 31 Mar 2004 13:27:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8kQW-0000xC-LL; Wed, 31 Mar 2004 13:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8kPp-0000td-MY for dhcwg@optimus.ietf.org; Wed, 31 Mar 2004 13:26:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05883 for ; Wed, 31 Mar 2004 13:26:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8kPn-0001Z5-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 13:26:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8kP1-0001UL-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 13:25:27 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B8kOK-0001MN-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 13:24:44 -0500 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2VIO9n2022444; Wed, 31 Mar 2004 10:24:10 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-39.cisco.com [10.86.240.39]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHG37694; Wed, 31 Mar 2004 13:24:08 -0500 (EST) Message-Id: <4.3.2.7.2.20040331131912.02663cc0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 31 Mar 2004 13:24:05 -0500 To: dhcwg@ietf.org From: Ralph Droms Cc: margaret@thingmagic.com, narten@us.ibm.com, Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Internet Drafts to be reviewed by the dhc WG Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , There are a couple of Internet Drafts under review by the midcom WG that specify new DHCP options: draft-tran-midcom-dhcp-option-00.txt draft-tran-midcom-dhcpv6-option-00.txt Based on our current charter, the dhc WG should consider collaborating with the midcom WG on the review of these specifications; specifically, the dhc WG should review the syntax of the options for adherence to DHCP requirements and consistency with other DHCP options, while the midcom WG will review the semantics associated with the options. Is there any objection to taking on this review as a dhc WG work item, pending acceptance of the documents by the midcom WG? Note that the drafts themselves will appear as midcom WG documents (if taken on by the midcom WG). - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 31 15:25:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11356; Wed, 31 Mar 2004 15:25:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8mGj-0001xh-4S; Wed, 31 Mar 2004 15:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8mG0-0001ur-Nr for dhcwg@optimus.ietf.org; Wed, 31 Mar 2004 15:24:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11229 for ; Wed, 31 Mar 2004 15:24:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8mFw-0000DA-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 15:24:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8mEy-0000AT-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 15:23:12 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1B8mE2-00007h-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 15:22:14 -0500 Received: from [10.0.1.3] (24-148-56-150.c3-0.snb-ubr1.chi-snb.il.cable.rcn.com [24.148.56.150]) by toccata.fugue.com (Postfix) with ESMTP id B59401B205C; Wed, 31 Mar 2004 14:16:47 -0600 (CST) In-Reply-To: <4.3.2.7.2.20040331131912.02663cc0@flask.cisco.com> References: <4.3.2.7.2.20040331131912.02663cc0@flask.cisco.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0E98DD7F-8351-11D8-BF4A-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, margaret@thingmagic.com, narten@us.ibm.com, Melinda Shore From: Ted Lemon Subject: Re: [dhcwg] Internet Drafts to be reviewed by the dhc WG Date: Wed, 31 Mar 2004 14:21:56 -0600 To: Ralph Droms X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mar 31, 2004, at 12:24 PM, Ralph Droms wrote: > Is there any objection to taking on this review as a dhc WG work item, > pending acceptance of the documents by the midcom WG? Note that the > drafts > themselves will appear as midcom WG documents (if taken on by the > midcom WG). I think it's a very good idea to take this review as a dhcwg work item. :') _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 31 15:53:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12616; Wed, 31 Mar 2004 15:53:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8mhp-0003i3-7e; Wed, 31 Mar 2004 15:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8mhF-0003gK-B9 for dhcwg@optimus.ietf.org; Wed, 31 Mar 2004 15:52:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12596 for ; Wed, 31 Mar 2004 15:52:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8mhD-0001XK-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 15:52:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8mg6-0001VL-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 15:51:15 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8mfq-0001UJ-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 15:50:58 -0500 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i2VKooOr007674; Wed, 31 Mar 2004 21:50:50 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id VAA00766; Wed, 31 Mar 2004 21:50:44 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i2VKoix25975; Wed, 31 Mar 2004 21:50:44 +0100 Date: Wed, 31 Mar 2004 21:50:44 +0100 From: Tim Chown To: Ralph Droms Cc: dhcwg@ietf.org, margaret@thingmagic.com, narten@us.ibm.com, Melinda Shore Subject: Re: [dhcwg] Internet Drafts to be reviewed by the dhc WG Message-ID: <20040331205044.GL20993@login.ecs.soton.ac.uk> Mail-Followup-To: Ralph Droms , dhcwg@ietf.org, margaret@thingmagic.com, narten@us.ibm.com, Melinda Shore References: <4.3.2.7.2.20040331131912.02663cc0@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20040331131912.02663cc0@flask.cisco.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Wed, Mar 31, 2004 at 01:24:05PM -0500, Ralph Droms wrote: > There are a couple of Internet Drafts under review by the midcom WG that > specify new DHCP options: > > draft-tran-midcom-dhcpv6-option-00.txt So this one assumes that IPv6 NATs exist and midcom will handle IPv6 NAT traversal? Or s midcom for IPv6 a means to configure the middlebox for other ALG or firewall purposes? Luckily I don't think Keith Moore is on the dhc WG list :) Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 31 17:50:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18342; Wed, 31 Mar 2004 17:50:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8oX3-0006dJ-Or; Wed, 31 Mar 2004 17:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8oWk-0006bh-T8 for dhcwg@optimus.ietf.org; Wed, 31 Mar 2004 17:49:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18333 for ; Wed, 31 Mar 2004 17:49:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8oWi-0000bN-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 17:49:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8oVo-0000ZN-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 17:48:44 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1B8oV0-0000VA-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 17:47:54 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 31 Mar 2004 14:56:20 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2VMlLA6015908; Wed, 31 Mar 2004 17:47:22 -0500 (EST) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHG66003; Wed, 31 Mar 2004 17:47:20 -0500 (EST) From: "Bernie Volz" To: "'S. Daniel Park'" Cc: Subject: RE: [dhcwg] RE: [DHCP Option for Configuring IPv6-over-IPv4 Tunnels]*DRAFT* minutes from WG meeting in Seoul (2nd try) Date: Wed, 31 Mar 2004 17:47:19 -0500 Organization: Cisco Message-ID: <003f01c41772$1ffa3b60$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <00bf01c4138d$7b476710$67cadba8@LocalHost> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi: I don't understand: In the above diagram, CTEP Addr is 32-bit integers corresponding to DHCP options which specify the IP address of different configured tunnel end-point. What DHCP options? DHCP option numbers are 8-bit for DHCPv4, not 32-bit. Perhaps you meant: In the above diagram, CTEP Addr is the 32-bit IPv4 address for the configured tunnel end-point. It might also be good to use the following diagram to make it clear that there is only one address possible: Code Length CTEP Address 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_CTEP | Len=4 | CTEP Address... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...CTEP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of S. Daniel Park Sent: Friday, March 26, 2004 6:53 PM To: 'Ralph Droms'; dhcwg@ietf.org Cc: 'S. Daniel Park' Subject: [dhcwg] RE: [DHCP Option for Configuring IPv6-over-IPv4 Tunnels]*DRAFT* minutes from WG meeting in Seoul (2nd try) > DHCPv4 Support for Conf. IPv6-in-IPv4 Tunnels > > Accept as WG work item? > >The author gave a short presentation about the option. ~8 WG >members had read this draft. There was some discussion of >the draft on the mailing list prior to the WG meeting. The author will >publish a revised draft based on those comments. The draft will be >reviewed by the v6ops WG; the chair will contact the v6ops >WG chairs to determine how to proceed. The WG also needs to >confirm it fits in dhc WG charter. The draft was not accepted as >WG work item at this time. Regarding this mention, the revised draft is now available and all comments on this draft were from the v6ops WG. http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-02.txt Change log: 1) replaced IPv6-in-IPv4 term. with IPv6-over-IPv4. (by Pekka Savola) [for easy tracking, I didn't change the filename as IPv6over4 so far] 2) reconstructed multiple CTEP option format by single CTEP option format. (by Alain Durand) 3) some text improvement (by Eric Normark) Hope this helps - Daniel (Soohong Daniel Park) - Mobile Platform Laboratory, SAMSUNG Electronics. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 31 18:09:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19499; Wed, 31 Mar 2004 18:09:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8opQ-00030f-6h; Wed, 31 Mar 2004 18:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8opC-0002wW-3x for dhcwg@optimus.ietf.org; Wed, 31 Mar 2004 18:08:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19425 for ; Wed, 31 Mar 2004 18:08:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8op9-0001dM-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 18:08:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8ooB-0001aJ-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 18:07:44 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1B8onY-0001W3-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 18:07:04 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 31 Mar 2004 15:15:31 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2VN6Scp016248; Wed, 31 Mar 2004 18:06:32 -0500 (EST) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHG67358; Wed, 31 Mar 2004 18:06:27 -0500 (EST) From: "Bernie Volz" To: "'Ralph Droms'" , , , Cc: , , "'Melinda Shore'" Subject: RE: [dhcwg] Internet Drafts to be reviewed by the dhc WG Date: Wed, 31 Mar 2004 18:06:27 -0500 Organization: Cisco Message-ID: <004001c41774$cc0e4930$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <4.3.2.7.2.20040331131912.02663cc0@flask.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi: Both of these drafts are IDENTICAL except that for the name of the draft. I presume one should have been a DHCPv4 option (draft-tran-midcom-dhcp-option-00.txt) and the other a DHCPv6 option? - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ralph Droms Sent: Wednesday, March 31, 2004 1:24 PM To: dhcwg@ietf.org Cc: margaret@thingmagic.com; narten@us.ibm.com; Melinda Shore Subject: [dhcwg] Internet Drafts to be reviewed by the dhc WG There are a couple of Internet Drafts under review by the midcom WG that specify new DHCP options: draft-tran-midcom-dhcp-option-00.txt draft-tran-midcom-dhcpv6-option-00.txt Based on our current charter, the dhc WG should consider collaborating with the midcom WG on the review of these specifications; specifically, the dhc WG should review the syntax of the options for adherence to DHCP requirements and consistency with other DHCP options, while the midcom WG will review the semantics associated with the options. Is there any objection to taking on this review as a dhc WG work item, pending acceptance of the documents by the midcom WG? Note that the drafts themselves will appear as midcom WG documents (if taken on by the midcom WG). - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 31 18:24:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20661; Wed, 31 Mar 2004 18:24:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8p3w-0006sK-Mn; Wed, 31 Mar 2004 18:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8p3a-0006rV-Qt for dhcwg@optimus.ietf.org; Wed, 31 Mar 2004 18:23:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20631 for ; Wed, 31 Mar 2004 18:23:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8p3X-0002SX-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 18:23:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8p2f-0002R4-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 18:22:41 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1B8p23-0002Ms-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 18:22:03 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 31 Mar 2004 15:21:33 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2VNLUA6022118; Wed, 31 Mar 2004 18:21:30 -0500 (EST) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHG68370; Wed, 31 Mar 2004 18:21:29 -0500 (EST) From: "Bernie Volz" To: "'Tim Chown'" , "'Ralph Droms'" Cc: , , , "'Melinda Shore'" Subject: RE: [dhcwg] Internet Drafts to be reviewed by the dhc WG Date: Wed, 31 Mar 2004 18:21:28 -0500 Organization: Cisco Message-ID: <000201c41776$e52df2b0$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 In-Reply-To: <20040331205044.GL20993@login.ecs.soton.ac.uk> Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit It says "Entities using the Midcom Protocol need to know the presence of Midcom middleboxes, such as firewalls and network address translators, in order to enable communication across theses devices." in the abstract of the draft. So, it looks like we're in for NAT with IPv6 ... I think the WG should take up the issue of how best to handle options that want to specify either or both domain names and IPv6 addresses. It seems to me silly to have TWO options for every time this needs to occur (as is the case in this midcom draft). And, this mechanism provides no way to specify the preference between the two - order can be used within each option to specify which to try first, but it can't be used across the options. So, it is then left up to the draft (or implementor) to pick which to use first. The obvious answer would be to use a sub-option technique or a flag byte before either an address or domain name. Something like: DHCP option (either 8-bits or 16-bits) Option length (either 8-bits or 16-bits) Encoding type (8-bits? - 0 for domain name, 1 for IP addresses) Encoding length (8 bits?) Data (either domain name or address) Encoding type (8-bits? - 0 for domain name, 1 for IP addresses) Encoding length (8 bits?) Data (either domain name or address) ... In the cases where only one type of encoding is used, this would cost 2 extra bytes. In the cases where multiple encodings are used, this would either be the same length as the two-option method or potentially save two bytes (depending on the encoding type/length field sizes). Note: It would also be possible to specify IPv4 AND IPv6 addresses (1 for IPv4 address, 2 for IPv6 addresses for the encoding type, for example). - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Tim Chown Sent: Wednesday, March 31, 2004 3:51 PM To: Ralph Droms Cc: dhcwg@ietf.org; margaret@thingmagic.com; narten@us.ibm.com; Melinda Shore Subject: Re: [dhcwg] Internet Drafts to be reviewed by the dhc WG On Wed, Mar 31, 2004 at 01:24:05PM -0500, Ralph Droms wrote: > There are a couple of Internet Drafts under review by the midcom WG > that specify new DHCP options: > > draft-tran-midcom-dhcpv6-option-00.txt So this one assumes that IPv6 NATs exist and midcom will handle IPv6 NAT traversal? Or s midcom for IPv6 a means to configure the middlebox for other ALG or firewall purposes? Luckily I don't think Keith Moore is on the dhc WG list :) Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 31 19:08:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21769; Wed, 31 Mar 2004 19:08:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8pkY-0004It-CH; Wed, 31 Mar 2004 19:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8pkD-000496-J6 for dhcwg@optimus.ietf.org; Wed, 31 Mar 2004 19:07:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21740 for ; Wed, 31 Mar 2004 19:07:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8pkA-0004DD-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 19:07:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8pjG-0004Ba-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 19:06:43 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1B8pic-0004A3-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 19:06:02 -0500 Received: from [10.0.1.2] (24-148-56-150.c3-0.snb-ubr1.chi-snb.il.cable.rcn.com [24.148.56.150]) by toccata.fugue.com (Postfix) with ESMTP id 612B61B95E8 for ; Wed, 31 Mar 2004 18:00:48 -0600 (CST) Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <000201c41776$e52df2b0$d0412ca1@amer.cisco.com> References: <000201c41776$e52df2b0$d0412ca1@amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5B2E935C-8370-11D8-BF4A-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Internet Drafts to be reviewed by the dhc WG Date: Wed, 31 Mar 2004 18:05:59 -0600 To: " " X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mar 31, 2004, at 5:21 PM, Bernie Volz wrote: > I think the WG should take up the issue of how best to handle options > that want to specify either or both domain names and IPv6 addresses. I would rephrase this. The working group in the past has taken up the issue of *whether* to send IP addresses or domain names, and we've historically decided to send IP addresses, so that the client isn't required to contain a resolver. Supporting (and requiring all clients to support) both options is expensive. So if the wg needs to discuss this again, I think the question should be whether to make it possible to send domain names instead of IP addresses, before we answer the question of how to do it. If we don't reopen that question, I would suggest that we advise the midcom folks to always send an IP address, and never a domain name, and to not have two different options. Otherwise, as you say, they have to specify how to choose, and whether it's okay to only send the domain name, and that whole can of worms. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 31 21:15:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27067; Wed, 31 Mar 2004 21:15:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8rjS-0000aY-8q; Wed, 31 Mar 2004 21:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8rjB-0000ZQ-QI for dhcwg@optimus.ietf.org; Wed, 31 Mar 2004 21:14:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27051 for ; Wed, 31 Mar 2004 21:14:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8rj9-0004uK-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 21:14:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8riE-0004rt-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 21:13:47 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B8rhQ-0004nS-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 21:12:56 -0500 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i312CNn2012272 for ; Wed, 31 Mar 2004 18:12:23 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-39.cisco.com [10.86.240.39]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHG76934; Wed, 31 Mar 2004 21:12:22 -0500 (EST) Message-Id: <4.3.2.7.2.20040331210913.0262ad68@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 31 Mar 2004 21:12:20 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] Internet Drafts to be reviewed by the dhc WG In-Reply-To: <5B2E935C-8370-11D8-BF4A-000A95D9C74C@fugue.com> References: <000201c41776$e52df2b0$d0412ca1@amer.cisco.com> <000201c41776$e52df2b0$d0412ca1@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , OK - the *original* question was "Is there any objection to taking on this review as a dhc WG work item, pending acceptance of the documents by the midcom WG?" Let me extend that question to ask for positive responses, as well - please respond "yes" or "no" to the question "Should the dhc WG take on review of draft-tran-midcom-dhcp-option-00.txt and draft-tran-midcom-dhcpv6-option-00.txt, pending acceptance of the documents by the midcom WG?" - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 31 21:50:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28074; Wed, 31 Mar 2004 21:50:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8sHJ-0002xI-AN; Wed, 31 Mar 2004 21:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8sH9-0002wv-9d for dhcwg@optimus.ietf.org; Wed, 31 Mar 2004 21:49:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28060 for ; Wed, 31 Mar 2004 21:49:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8sH6-0006zs-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 21:49:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8sGA-0006x1-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 21:48:50 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1B8sFN-0006rE-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 21:48:01 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HVH00901131QJ@mailout1.samsung.com> for dhcwg@ietf.org; Thu, 01 Apr 2004 11:47:25 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HVH005R5130OW@mailout1.samsung.com> for dhcwg@ietf.org; Thu, 01 Apr 2004 11:47:24 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HVH00DX1130Q0@mmp2.samsung.com> for dhcwg@ietf.org; Thu, 01 Apr 2004 11:47:24 +0900 (KST) Date: Thu, 01 Apr 2004 11:47:42 +0900 From: "S. Daniel Park" Subject: RE: [dhcwg] Internet Drafts to be reviewed by the dhc WG In-reply-to: <4.3.2.7.2.20040331210913.0262ad68@flask.cisco.com> To: "'Ralph Droms'" , dhcwg@ietf.org Message-id: <005701c41793$b42dd370$67cadba8@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT I second " YES" I believe that kind of drafts (all DHCP Options) should be considered in the DHC WG, regarding technical aspect related WGs have to carefully review them of course. Regards - Daniel (Soohong Daniel Park) - Mobile Platform Laboratory, SAMSUNG Electronics. > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On > Behalf Of Ralph Droms > Sent: Thursday, April 01, 2004 11:12 AM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] Internet Drafts to be reviewed by the dhc WG > > > OK - the *original* question was "Is there any objection to > taking on this > review as a dhc WG work item, pending acceptance of the > documents by the > midcom WG?" > > Let me extend that question to ask for positive responses, as > well - please > respond "yes" or "no" to the question "Should the dhc WG take > on review of > draft-tran-midcom-dhcp-option-00.txt and > draft-tran-midcom-dhcpv6-option-00.txt, pending acceptance of > the documents > by the midcom WG?" > > - Ralph > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 31 22:25:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29431; Wed, 31 Mar 2004 22:25:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8spA-0006QS-Tn; Wed, 31 Mar 2004 22:25:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8soy-0006Q1-6G for dhcwg@optimus.ietf.org; Wed, 31 Mar 2004 22:24:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29376 for ; Wed, 31 Mar 2004 22:24:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8sou-0001f2-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 22:24:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8snx-0001c1-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 22:23:45 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B8sn7-0001Uw-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 22:22:53 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 31 Mar 2004 19:28:55 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i313MKn2020425; Wed, 31 Mar 2004 19:22:20 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-39.cisco.com [10.86.240.39]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHG79140; Wed, 31 Mar 2004 22:22:19 -0500 (EST) Message-Id: <4.3.2.7.2.20040331222011.01f8a658@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 31 Mar 2004 22:22:16 -0500 To: Tim Chown From: Ralph Droms Subject: Re: [dhcwg] Internet Drafts to be reviewed by the dhc WG Cc: dhcwg@ietf.org, margaret@thingmagic.com, narten@us.ibm.com, Melinda Shore In-Reply-To: <20040331205044.GL20993@login.ecs.soton.ac.uk> References: <4.3.2.7.2.20040331131912.02663cc0@flask.cisco.com> <4.3.2.7.2.20040331131912.02663cc0@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , We'll leave the interesting decision about "IPv6 NAT: threat or menace?" to the midcom, ipv6 and other WGs. The dhc WG will focus on the syntax of the options and the mechanics of how the configuration data is passed through DHCP messages. - Ralph At 09:50 PM 3/31/2004 +0100, Tim Chown wrote: >On Wed, Mar 31, 2004 at 01:24:05PM -0500, Ralph Droms wrote: > > There are a couple of Internet Drafts under review by the midcom WG that > > specify new DHCP options: > > > > draft-tran-midcom-dhcpv6-option-00.txt > >So this one assumes that IPv6 NATs exist and midcom will handle IPv6 NAT >traversal? Or s midcom for IPv6 a means to configure the middlebox for >other ALG or firewall purposes? > >Luckily I don't think Keith Moore is on the dhc WG list :) > >Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 31 23:08:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00869; Wed, 31 Mar 2004 23:08:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8tUn-00015r-68; Wed, 31 Mar 2004 23:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8tUf-00011K-Ix for dhcwg@optimus.ietf.org; Wed, 31 Mar 2004 23:07:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00845 for ; Wed, 31 Mar 2004 23:07:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8tUb-0004L8-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 23:07:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8tTh-0004He-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 23:06:53 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1B8tSq-00049H-00 for dhcwg@ietf.org; Wed, 31 Mar 2004 23:06:01 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HVH00A014P6JD@mailout3.samsung.com> for dhcwg@ietf.org; Thu, 01 Apr 2004 13:05:30 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HVH003L44P5SE@mailout3.samsung.com> for dhcwg@ietf.org; Thu, 01 Apr 2004 13:05:29 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HVH005AJ4P5BB@mmp2.samsung.com> for dhcwg@ietf.org; Thu, 01 Apr 2004 13:05:29 +0900 (KST) Date: Thu, 01 Apr 2004 13:05:47 +0900 From: "S. Daniel Park" Subject: RE: [dhcwg] RE: [DHCP Option for Configuring IPv6-over-IPv4 Tunnels]*DRAFT* minutes from WG meeting in Seoul (2nd try) In-reply-to: <003f01c41772$1ffa3b60$d0412ca1@amer.cisco.com> To: "'Bernie Volz'" Cc: dhcwg@ietf.org Message-id: <005c01c4179e$9caf1cd0$67cadba8@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi Bernie Your comments look good for me. I will reflect them to the next version soon. Regarding the scope of DHC WG, I am also wondering this draft can be accepted as work item. As I indicated, this draft was already reviewed by V6OPS WG... Regards. - Daniel (Soohong Daniel Park) - Mobile Platform Laboratory, SAMSUNG Electronics. > -----Original Message----- > From: Bernie Volz [mailto:volz@cisco.com] > Sent: Thursday, April 01, 2004 7:47 AM > To: 'S. Daniel Park' > Cc: dhcwg@ietf.org > Subject: RE: [dhcwg] RE: [DHCP Option for Configuring > IPv6-over-IPv4 Tunnels]*DRAFT* minutes from WG meeting in > Seoul (2nd try) > > > Hi: > > I don't understand: > In the above diagram, CTEP Addr is 32-bit integers > corresponding to > > DHCP options which specify the IP address of different > configured > tunnel end-point. > > What DHCP options? DHCP option numbers are 8-bit for DHCPv4, > not 32-bit. > > Perhaps you meant: > In the above diagram, CTEP Addr is the 32-bit IPv4 > address for the > configured tunnel end-point. > > It might also be good to use the following diagram to make it > clear that > there is only one address possible: > > Code Length CTEP Address > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OPTION_CTEP | Len=4 | CTEP Address... > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ...CTEP Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > - Bernie > > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On > Behalf Of S. > Daniel Park > Sent: Friday, March 26, 2004 6:53 PM > To: 'Ralph Droms'; dhcwg@ietf.org > Cc: 'S. Daniel Park' > Subject: [dhcwg] RE: [DHCP Option for Configuring IPv6-over-IPv4 > Tunnels]*DRAFT* minutes from WG meeting in Seoul (2nd try) > > > > > > DHCPv4 Support for Conf. IPv6-in-IPv4 Tunnels > > > > Accept as WG work item? > > > >The author gave a short presentation about the option. ~8 WG > >members had read this draft. There was some discussion of > >the draft on the mailing list prior to the WG meeting. The > author will > > >publish a revised draft based on those comments. The draft will be > >reviewed by the v6ops WG; the chair will contact the v6ops > >WG chairs to determine how to proceed. The WG also needs to > >confirm it fits in dhc WG charter. The draft was not accepted as > >WG work item at this time. > Regarding this mention, the revised draft is now available and all > comments on this draft were from the v6ops WG. > http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-o pt-02.txt Change log: 1) replaced IPv6-in-IPv4 term. with IPv6-over-IPv4. (by Pekka Savola) [for easy tracking, I didn't change the filename as IPv6over4 so far] 2) reconstructed multiple CTEP option format by single CTEP option format. (by Alain Durand) 3) some text improvement (by Eric Normark) Hope this helps - Daniel (Soohong Daniel Park) - Mobile Platform Laboratory, SAMSUNG Electronics. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg