From dhcwg-admin@ietf.org Thu Apr 1 04:05: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 EAA02649; Thu, 1 Apr 2004 04:05: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 1B8y8E-0007fF-2d; Thu, 01 Apr 2004 04:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8y7G-0007RO-MQ for dhcwg@optimus.ietf.org; Thu, 01 Apr 2004 04:04: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 EAA02625 for ; Thu, 1 Apr 2004 04:03:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8y7E-0002mE-00 for dhcwg@ietf.org; Thu, 01 Apr 2004 04:04:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8y6I-0002iY-00 for dhcwg@ietf.org; Thu, 01 Apr 2004 04:03:03 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8y5w-0002et-00 for dhcwg@ietf.org; Thu, 01 Apr 2004 04:02:40 -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 i3192fOr021579 for ; Thu, 1 Apr 2004 10:02:41 +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 KAA10771 for ; Thu, 1 Apr 2004 10:02:40 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i3192eC29937 for dhcwg@ietf.org; Thu, 1 Apr 2004 10:02:40 +0100 Date: Thu, 1 Apr 2004 10:02:40 +0100 From: Tim Chown To: dhcwg@ietf.org Subject: Re: [dhcwg] Internet Drafts to be reviewed by the dhc WG Message-ID: <20040401090240.GB29560@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org References: <000201c41776$e52df2b0$d0412ca1@amer.cisco.com> <000201c41776$e52df2b0$d0412ca1@amer.cisco.com> <4.3.2.7.2.20040331210913.0262ad68@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.20040331210913.0262ad68@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: , Sorry :) Yes, if it is going to happen, it should have dhc WG eyes over it. On Wed, Mar 31, 2004 at 09:12:20PM -0500, Ralph Droms wrote: > 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 Thu Apr 1 15:34:07 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 PAA00568; Thu, 1 Apr 2004 15:34:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98qM-00065V-Co; Thu, 01 Apr 2004 15:31:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B935P-0004CR-1G for dhcwg@optimus.ietf.org; Thu, 01 Apr 2004 09:22: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 JAA14391 for ; Thu, 1 Apr 2004 09:21:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9345-00009t-00 for dhcwg@ietf.org; Thu, 01 Apr 2004 09:21:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9336-000024-00 for dhcwg@ietf.org; Thu, 01 Apr 2004 09:20:05 -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 1B9328-0007ij-00 for dhcwg@ietf.org; Thu, 01 Apr 2004 09:19:05 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 01 Apr 2004 06:25:11 +0000 X-BrightmailFiltered: true 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 i31EITKl017926; Thu, 1 Apr 2004 06:18:31 -0800 (PST) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHG97421; Thu, 1 Apr 2004 09:18:29 -0500 (EST) From: "Bernie Volz" To: "'Ralph Droms'" , Subject: RE: [dhcwg] Internet Drafts to be reviewed by the dhc WG Date: Thu, 1 Apr 2004 09:18:29 -0500 Organization: Cisco Message-ID: <001401c417f4$344f7c60$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.20040331210913.0262ad68@flask.cisco.com> 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=1.0 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS 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 - we should review the options for consistency with DHCP. I'm also not sure why there is a need to ask as this is clearly in the WG's current charter: The DHC WG is responsible for reviewing (and sometimes developing) DHCP options or other extensions (for both IPv4 and IPv6). The DHC WG is expected to review all proposed extensions to DHCP to ensure that they are consistent with the DHCP specification and other option formats, that they do not duplicate existing mechanisms, etc. The DHC WG will not (generally) be responsible for evaluating the semantic content of proposed options. The DHC WG will not adopt new proposals for extensions to DHCP as working group documents without first coordinating with other relevant working groups and determining who has the responsibility for reviewing the semantic content of an option. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ralph Droms Sent: Wednesday, March 31, 2004 9:12 PM 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 mailman-admin@ietf.org Thu Apr 1 18:42: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 SAA09871 for ; Thu, 1 Apr 2004 18:42: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 1B99d8-0001OP-6p for DHC-ARCHIVE@lists.ietf.org; Thu, 01 Apr 2004 16:21:42 -0500 Date: Thu, 01 Apr 2004 11:23:04 -0500 Message-ID: <20040401162304.11029.3077.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 Fri Apr 2 21:32: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 VAA19318; Fri, 2 Apr 2004 21:32: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 1B9ax1-00079Y-Kt; Fri, 02 Apr 2004 21:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9awR-0006zz-Jg for dhcwg@optimus.ietf.org; Fri, 02 Apr 2004 21:31: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 VAA19210 for ; Fri, 2 Apr 2004 21:31:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9awO-0002gT-00 for dhcwg@ietf.org; Fri, 02 Apr 2004 21:31:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9avR-0002Xf-00 for dhcwg@ietf.org; Fri, 02 Apr 2004 21:30:26 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1B9aud-0002Hw-00 for dhcwg@ietf.org; Fri, 02 Apr 2004 21:29:36 -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 <0HVK00801PKHP2@mailout1.samsung.com> for dhcwg@ietf.org; Sat, 03 Apr 2004 11:29:05 +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 <0HVK00D4BPKG74@mailout1.samsung.com> for dhcwg@ietf.org; Sat, 03 Apr 2004 11:29:04 +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 <0HVK00KW8PKFZU@mmp2.samsung.com> for dhcwg@ietf.org; Sat, 03 Apr 2004 11:29:04 +0900 (KST) Date: Sat, 03 Apr 2004 11:29:21 +0900 From: "S. Daniel Park" Subject: RE: [dhcwg] Drafts ready for WG last call In-reply-to: <4.3.2.7.2.20040315104633.01f70fc0@flask.cisco.com> To: "'Ralph Droms'" , dhcwg@ietf.org Message-id: <008601c41923$79831500$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 Is there any expressed opposition for progressing these draft ? - 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: Tuesday, March 16, 2004 12:52 AM > To: dhcwg@ietf.org > Subject: [dhcwg] Drafts ready for WG last call > > > 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 > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Apr 2 21:44: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 VAA19734; Fri, 2 Apr 2004 21:44: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 1B9b8b-0003Oi-79; Fri, 02 Apr 2004 21: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 1B9b83-00031S-Oa for dhcwg@optimus.ietf.org; Fri, 02 Apr 2004 21:43: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 VAA19674 for ; Fri, 2 Apr 2004 21:43:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9b80-0004I6-00 for dhcwg@ietf.org; Fri, 02 Apr 2004 21:43:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9b74-0004Aj-00 for dhcwg@ietf.org; Fri, 02 Apr 2004 21:42:27 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1B9b6Z-00043K-00 for dhcwg@ietf.org; Fri, 02 Apr 2004 21:41:55 -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 8C4D91B39F6; Fri, 2 Apr 2004 20:36:20 -0600 (CST) In-Reply-To: <008601c41923$79831500$67cadba8@LocalHost> References: <008601c41923$79831500$67cadba8@LocalHost> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <75629625-8518-11D8-869D-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: "'Ralph Droms'" , dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] Drafts ready for WG last call Date: Fri, 2 Apr 2004 20:41:50 -0600 To: "S. Daniel Park" 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 Apr 2, 2004, at 8:29 PM, S. Daniel Park wrote: > Is there any expressed opposition for progressing these draft ? We were expecting some of them to get minor edits in last call, I think. You can refer to the DHCwg meeting minutes for details. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Apr 3 06:48: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 GAA16465; Sat, 3 Apr 2004 06:48: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 1B9jd3-0000pf-6D; Sat, 03 Apr 2004 06:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9jcq-0000pL-8S for dhcwg@optimus.ietf.org; Sat, 03 Apr 2004 06:47: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 GAA16444 for ; Sat, 3 Apr 2004 06:47:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9jcm-00000u-00 for dhcwg@ietf.org; Sat, 03 Apr 2004 06:47:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9jbu-0007i1-00 for dhcwg@ietf.org; Sat, 03 Apr 2004 06:46:51 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1B9jbC-0007V9-00 for dhcwg@ietf.org; Sat, 03 Apr 2004 06:46:06 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 03 Apr 2004 03:55:00 -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 i33BjYcp011419; Sat, 3 Apr 2004 06:45:35 -0500 (EST) Received: from rdroms-w2k01.cisco.com (rtp-vpn3-123.cisco.com [10.82.216.123]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHI47549; Sat, 3 Apr 2004 06:45:32 -0500 (EST) Message-Id: <4.3.2.7.2.20040403064205.029b19b0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 03 Apr 2004 06:44:57 -0500 To: "S. Daniel Park" From: Ralph Droms Subject: RE: [dhcwg] Drafts ready for WG last call Cc: dhcwg@ietf.org In-Reply-To: <008601c41923$79831500$67cadba8@LocalHost> References: <4.3.2.7.2.20040315104633.01f70fc0@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: , Are you asking about opposition to initiating a WG last call on these drafts? Assuming there are no objections to WG last calls on these drafts (I haven't seen any to date), I'll start the last calls early next week. - Ralph At 11:29 AM 4/3/2004 +0900, S. Daniel Park wrote: >Is there any expressed opposition for progressing these draft ? > > >- 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: Tuesday, March 16, 2004 12:52 AM > > To: dhcwg@ietf.org > > Subject: [dhcwg] Drafts ready for WG last call > > > > > > 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 > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Apr 4 19: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 TAA15932; Sun, 4 Apr 2004 19:39:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAHCf-0002IV-3e; Sun, 04 Apr 2004 19:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9P0W-0000IB-Ts for dhcwg@optimus.ietf.org; Fri, 02 Apr 2004 08:46: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 IAA08988 for ; Fri, 2 Apr 2004 08:46:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9P0V-0001Gk-00 for dhcwg@ietf.org; Fri, 02 Apr 2004 08:46:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9OzX-00019z-00 for dhcwg@ietf.org; Fri, 02 Apr 2004 08:45:51 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Oyg-0000xC-00 for dhcwg@ietf.org; Fri, 02 Apr 2004 08:44:58 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i32DiRw31507 for ; Fri, 2 Apr 2004 16:44:27 +0300 Date: Fri, 2 Apr 2004 16:44:27 +0300 (EEST) From: Pekka Savola To: dhcwg@ietf.org 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] applicability of draft-ietf-dhc-dhcpv6-ctep-opt-01 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, I glanced through draft-ietf-dhc-dhcpv6-ctep-opt-01.txt. I also discussed this problem space with Vijay in IETF59. I think the applicability and usefulness of this option is *very* questionable. As it is a DHCPv6 option, it can be only used inside v6 sites with basically their own DHCPv6 server in each. That is, imagine that you wanted to connect 10 sites together from their border router using full-mesh configured tunneling. You'll have to set up 9 tunnels in each site, 9*10 tunnels in total. What's the gain of using DHCPv6 here, I ask? You'll have to set up these 9 tunnels in each of the 10 DHCPv6 servers in any case, 90 DHCPv6 configuration entries in total. You're trading off having to configure 90 tunnels in 10 border routers to having to configure 90 tunnels in 10 DHCPv6 servers. IMHO, in this kind of set-up, Using DHCPv6 just doesn't seem to make sense. Is there something I've missed? -- 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 Sun Apr 4 21: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 VAA18387; Sun, 4 Apr 2004 21:17:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAIjU-0003Hi-RG; Sun, 04 Apr 2004 21:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAIiW-0003Dw-N6 for dhcwg@optimus.ietf.org; Sun, 04 Apr 2004 21:16:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18361 for ; Sun, 4 Apr 2004 21:15:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAIiU-0005Hu-00 for dhcwg@ietf.org; Sun, 04 Apr 2004 21:15:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAIha-0005Ct-00 for dhcwg@ietf.org; Sun, 04 Apr 2004 21:15:02 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BAIgf-00052b-00 for dhcwg@ietf.org; Sun, 04 Apr 2004 21:14:05 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 04 Apr 2004 18:12:19 -0700 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 i351DWCC029482; Sun, 4 Apr 2004 21:13:33 -0400 (EDT) Received: from volzw2k (sjc-vpn2-836.cisco.com [10.21.115.68]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHI80891; Sun, 4 Apr 2004 21:13:29 -0400 (EDT) From: "Bernie Volz" To: , Cc: Subject: RE: [dhcwg] Internet Drafts to be reviewed by the dhc WG - midcom options Date: Sun, 4 Apr 2004 21:13:28 -0400 Organization: Cisco Message-ID: <000001c41aab$356f8f90$6401a8c0@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 Importance: Normal In-Reply-To: <4.3.2.7.2.20040331131912.02663cc0@flask.cisco.com> 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.1 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 Here's some nits regarding draft-tran-midcom-dhcpv6-option-00.txt (and also -01 which is now posted but identical): - Abstract: "Dynamic Host Configuration Protocol for IPv6" would be better than "Dynamic Host Configuration Protocol version 6". - 1 Terminology: MIDCOM should be Midcom to be consistent with usage throughout doc? Functionnality should be functionality. There's also a bunch of non 7-bit ASCII characters in the "Midcom Agent" definition? - 2 Introduction: "the domain name[s] of the Midcom". And, also "or the domain name[s] of Midcom middleboxes". (Make plural!) - 4 Midcom Middlebox DHCPv6 Option - "list of [] 128-bit [] IPv6 addresses or, preferably, [a] DNS [RFC1035] domain name[s]." - 4.2 Midcom Middlebox IPv4 Address List - should be "IPv6", not IPv4. - Table 1 (in Section 5.2): There is a MUST, but this is only if there is an address configured. - 5.2 Midcom Middlebox DHCPv6 Server Option Operation: "This server MAY send one" ... Is use of "MAY" correct here? I think it should be "This server should send ..."? The table provides the rules. I haven't looked at draft-tran-midcom-dhcp-option-01.txt (DHCPv4 option) - but some of the above nits likely apply there as well. I don't see anything particularily wrong with these DHCPv6 options, though as I posted the other day, I think the DHC WG should take on the issue as to whether this is the best way to handle the ability to configure addresses and domain names (two options), or whether, as Ted suggested in a response to my post, to send only addresses. I guess a good question to Joel and Soumaya is whether just sending addresses would cause any significant issues? - Bernie Volz -----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 Sun Apr 4 21: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 VAA18386; Sun, 4 Apr 2004 21:17:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAIjV-0003Hq-6H; Sun, 04 Apr 2004 21:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAIiX-0003EC-BG for dhcwg@optimus.ietf.org; Sun, 04 Apr 2004 21:16:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18364 for ; Sun, 4 Apr 2004 21:15:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAIiU-0005Hz-00 for dhcwg@ietf.org; Sun, 04 Apr 2004 21:15:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAIha-0005D1-00 for dhcwg@ietf.org; Sun, 04 Apr 2004 21:15:03 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1BAIhB-000583-00 for dhcwg@ietf.org; Sun, 04 Apr 2004 21:14:37 -0400 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 67FDE1C1292; Sun, 4 Apr 2004 20:08:42 -0500 (CDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <99C4FAC6-869E-11D8-869D-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] applicability of draft-ietf-dhc-dhcpv6-ctep-opt-01 Date: Sun, 4 Apr 2004 20:14:35 -0500 To: Pekka Savola 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 Apr 2, 2004, at 7:44 AM, Pekka Savola wrote: > You're trading off having to > configure 90 tunnels in 10 border routers to having to configure 90 > tunnels in 10 DHCPv6 servers. > > IMHO, in this kind of set-up, Using DHCPv6 just doesn't seem to make > sense. Possibly it's easier to configure a DHCP server on a central server somewhere with all this information rather than configuring the router, because if the router dies then you have to remember to reconfigure it. But basically, I don't know. :') _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 5 06:29: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 GAA20891; Mon, 5 Apr 2004 06:29:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BARLv-0002u4-1A; Mon, 05 Apr 2004 06:29:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BANIG-00044D-Sf for dhcwg@optimus.ietf.org; Mon, 05 Apr 2004 02:09:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07670 for ; Mon, 5 Apr 2004 02:09:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BANID-0005n2-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 02:09:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BANHJ-0005hm-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 02:08:14 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BANGa-0005WV-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 02:07:28 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3566mq18992; Mon, 5 Apr 2004 09:06:49 +0300 Date: Mon, 5 Apr 2004 09:06:48 +0300 (EEST) From: Pekka Savola To: Ted Lemon cc: dhcwg@ietf.org Subject: Re: [dhcwg] applicability of draft-ietf-dhc-dhcpv6-ctep-opt-01 In-Reply-To: <99C4FAC6-869E-11D8-869D-000A95D9C74C@fugue.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 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 Sun, 4 Apr 2004, Ted Lemon wrote: > On Apr 2, 2004, at 7:44 AM, Pekka Savola wrote: > > You're trading off having to > > configure 90 tunnels in 10 border routers to having to configure 90 > > tunnels in 10 DHCPv6 servers. > > > > IMHO, in this kind of set-up, Using DHCPv6 just doesn't seem to make > > sense. > > Possibly it's easier to configure a DHCP server on a central server > somewhere with all this information rather than configuring the router, > because if the router dies then you have to remember to reconfigure it. > > But basically, I don't know. :') You'll have to reconfigure the router in any case to get the other connectivity working ;-). Here, you don't get aggregation benefits as you have to configure exactly the same information in 10 DHCPv6 servers as you'd have to do in 10 routers. If you would only need to configure 1 DHCPv6 server to get the config to all the routers, some folks might think this gives additional benefits. -- 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 Mon Apr 5 07:29: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 HAA23869; Mon, 5 Apr 2004 07:29:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASHk-0001KB-HO; Mon, 05 Apr 2004 07:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASHA-0001DM-AU for dhcwg@optimus.ietf.org; Mon, 05 Apr 2004 07:28:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23812 for ; Mon, 5 Apr 2004 07:28:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BASH9-0004Nx-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 07:28:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BASGJ-0004I4-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 07:27:32 -0400 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 1BASFO-00044p-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 07:26:34 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 05 Apr 2004 03:34:37 +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 i35BQ2Kj015342 for ; Mon, 5 Apr 2004 04:26:02 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-69.cisco.com [10.86.242.69]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHI90767; Mon, 5 Apr 2004 07:26:00 -0400 (EDT) Message-Id: <4.3.2.7.2.20040403072041.029964c8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Apr 2004 07:26:00 -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] dhc WG last call on draft-ietf-dhc-proxyserver-opt-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: , This message announces a WG last call on "DHCP Option for Proxy Server Configuration" . The last call will conclude at 5PM EST on Friday, 4/16/04. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. draft-ietf-dhc-proxyserver-opt-00 defines a new DHCP option, which can be used to configure the TCP/IP host's Proxy Server configuration for standard protocols like HTTP, FTP, NNTP, SOCKS, Gopher, SLL and etc.. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-opt-00.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 5 07:34: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 HAA24086; Mon, 5 Apr 2004 07:34:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASMa-0002Nf-U1; Mon, 05 Apr 2004 07:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASM8-0002Ms-JW for dhcwg@optimus.ietf.org; Mon, 05 Apr 2004 07:33:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24033 for ; Mon, 5 Apr 2004 07:33:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BASM7-00052S-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 07:33:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BASLD-0004uC-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 07:32:36 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BASKF-0004dK-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 07:31:35 -0400 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 i35BV1Ue000257 for ; Mon, 5 Apr 2004 04:31:01 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-69.cisco.com [10.86.242.69]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHI90886; Mon, 5 Apr 2004 07:31:00 -0400 (EDT) Message-Id: <4.3.2.7.2.20040403072717.029b01f8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Apr 2004 07:31:00 -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] dhc WG last call on draft-ietf-dhc-vendor-01 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 announces a WG last call on "Vendor-Identifying Vendor Options for DHCPv4" . The last call will conclude at 5PM on 4/16/04. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Summary: The DHCP options for Vendor Class and Vendor-Specific Information can be ambiguous when a DHCP client represents multiple vendors. draft-ietf-dhc-vendor-01 defines two new options, modeled on the IPv6 options for vendor class and vendor-specific information, which contain Enterprise Numbers to remove ambiguity.. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-vendor-01.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 5 07:39: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 HAA24424; Mon, 5 Apr 2004 07:39:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASRQ-0003Id-MB; Mon, 05 Apr 2004 07:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASQr-00039D-S6 for dhcwg@optimus.ietf.org; Mon, 05 Apr 2004 07:38:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24303 for ; Mon, 5 Apr 2004 07:38:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BASQr-0005b9-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 07:38:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BASPz-0005Up-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 07:37:32 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BASP3-0005Hk-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 07:36:33 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 05 Apr 2004 04:45:46 -0700 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 i35Ba1CC008192 for ; Mon, 5 Apr 2004 07:36:01 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-69.cisco.com [10.86.242.69]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHI90990; Mon, 5 Apr 2004 07:36:00 -0400 (EDT) Message-Id: <4.3.2.7.2.20040403073217.029964c8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Apr 2004 07:36:00 -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] dhc WG last call on draft-ietf-dhc-3315id-for-v4-01 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 announces a WG last call on "Node-Specific Client Identifiers for DHCPv4" . The last call will conclude at 5PM on 4/16/04. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. draft-ietf-dhc-3315id-for-v4-01 specifies the format that is to be used for encoding DHCPv4 [RFC2131 and RFC2132] client identifiers, so that those identifiers will be interchangeable with identifiers used in the DHCPv6 protocol [RFC3315]. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-3315id-for-v4-01.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 5 07:45: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 HAA24799; Mon, 5 Apr 2004 07:45:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASXF-000448-60; Mon, 05 Apr 2004 07:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASWk-00043b-Ah for dhcwg@optimus.ietf.org; Mon, 05 Apr 2004 07:44:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24776 for ; Mon, 5 Apr 2004 07:44:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BASWj-0006PJ-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 07:44:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BASVs-0006J1-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 07:43:37 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BASVM-0006Bs-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 07:43:04 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 05 Apr 2004 04:52:17 -0700 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 i35BgVCC009138 for ; Mon, 5 Apr 2004 07:42:32 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-69.cisco.com [10.86.242.69]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHI91128; Mon, 5 Apr 2004 07:41:14 -0400 (EDT) Message-Id: <4.3.2.7.2.20040403073841.029964c8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Apr 2004 07:41:00 -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] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-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: , This message announces a WG last call on "Rapid Commit Option for DHCPv4" . The last call will conclude at 5PM EST on 4/15/04. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. draft-ietf-dhc-rapid-commit-opt-00 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. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-rapid-commit-opt-00.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 5 07:49: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 HAA25042; Mon, 5 Apr 2004 07:49:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASb7-0004cM-9v; Mon, 05 Apr 2004 07:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASao-0004aI-3A for dhcwg@optimus.ietf.org; Mon, 05 Apr 2004 07:48:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24943 for ; Mon, 5 Apr 2004 07:48:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BASan-00072R-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 07:48:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BASZl-0006rm-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 07:47:37 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BASYj-0006ZK-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 07:46:33 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 05 Apr 2004 04:55:46 -0700 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 i35Bk1cp021105 for ; Mon, 5 Apr 2004 07:46:01 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-69.cisco.com [10.86.242.69]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHI91257; Mon, 5 Apr 2004 07:46:00 -0400 (EDT) Message-Id: <4.3.2.7.2.20040403074305.029b19b0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Apr 2004 07:46:00 -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.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-reclassify-options-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: , This message announces a WG last call on "Reclassifying DHCPv4 Options" . The last call will conclude at 5PM EST on 4/16/04. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. draft-ietf-dhc-reclassify-options-00 revises RFC 2132 to reclassify DHCPv4 option codes 128 to 223 (decimal) as publicly defined options to be managed by IANA in accordance with RFC 2939. This document directs IANA to make these option codes available for assignment as publicly defined DHCP options for future options.. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-reclassify-options-00.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 5 08: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 IAA27354; Mon, 5 Apr 2004 08:39:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BATNU-0006Jo-Gn; Mon, 05 Apr 2004 08:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BATMu-00068c-4p for dhcwg@optimus.ietf.org; Mon, 05 Apr 2004 08:38:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27255 for ; Mon, 5 Apr 2004 08:38:21 -0400 (EDT) From: rdroms@cisco.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BATMs-0005Yk-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 08:38:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BATLt-0005Nb-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 08:37:22 -0400 Received: from [203.122.48.74] (helo=ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1BATJB-0004rx-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 08:34:34 -0400 To: dhcwg@ietf.org Date: Mon, 5 Apr 2004 18:06:00 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: 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=5.7 required=5.0 tests=MIME_BOUND_NEXTPART, MISSING_MIMEOLE,MSGID_FROM_MTA_SHORT,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 0.2 MIME_BOUND_NEXTPART Spam tool pattern in MIME boundary * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer Subject: [dhcwg] Re: Test 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. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_NETSKY.P in file document.txt .exe (in readme.zip) The uncleanable file is deleted. --------------------------------------------------------- ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Encrypted message is available. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) readme.zip is removed from here because it contains a virus. --------------------------------------------------------- ------=_NextPart_000_0016----=_NextPart_000_0016-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 5 10:01: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 KAA01534; Mon, 5 Apr 2004 10:01:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUer-0005l4-Pn; Mon, 05 Apr 2004 10:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUeS-0005Wb-8t for dhcwg@optimus.ietf.org; Mon, 05 Apr 2004 10:00:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01486 for ; Mon, 5 Apr 2004 10:00:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAUeQ-00013J-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 10:00:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAUdW-0000w0-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 09:59:38 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BAUcb-0000jN-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 09:58:42 -0400 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 i35Dw99l049190 for ; Mon, 5 Apr 2004 15:58:11 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i35Dt5aU048843 for ; Mon, 5 Apr 2004 15:55:05 +0200 (CEST) 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 i35Dt19h048832; Mon, 05 Apr 2004 15:55:05 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 9B1B111E251; Mon, 5 Apr 2004 15:54:59 +0200 (CEST) Date: Mon, 05 Apr 2004 15:54:57 +0200 From: Martin Stiemerling To: Tim Chown , 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: <2147483647.1081180497@[10.1.1.109]> In-Reply-To: <20040331205044.GL20993@login.ecs.soton.ac.uk> References: <4.3.2.7.2.20040331131912.02663cc0@flask.cisco.com> <20040331205044.GL20993@login.ecs.soton.ac.uk> X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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.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 --On Mittwoch, 31. M=E4rz 2004 21:50 Uhr +0100 Tim Chown=20 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? Hmm, I don't see any assumption saying that there will be IPv6 NATs. The=20 document ist just saying that the MIDCOM server can be reached via IPv6,=20 whether there is a NAT at the box or not is a different story. Martin | | 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 Mon Apr 5 12:39:27 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 MAA14067; Mon, 5 Apr 2004 12:39:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAX1f-0006le-3N; Mon, 05 Apr 2004 12:32:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAWWA-0002BR-1J for dhcwg@optimus.ietf.org; Mon, 05 Apr 2004 12:00:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06946 for ; Mon, 5 Apr 2004 11:12:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAVm3-0003sg-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 11:12:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAVl8-0003il-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 11:11:35 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAVkD-0003Wp-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 11:10:37 -0400 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 i35FATOr018694; Mon, 5 Apr 2004 16:10:29 +0100 (BST) 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 QAA13815; Mon, 5 Apr 2004 16:10:25 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i35FAPB12540; Mon, 5 Apr 2004 16:10:25 +0100 Date: Mon, 5 Apr 2004 16:10:25 +0100 From: Tim Chown To: Martin Stiemerling Cc: Ralph Droms , 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: <20040405151025.GA12352@login.ecs.soton.ac.uk> Mail-Followup-To: Martin Stiemerling , 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> <20040331205044.GL20993@login.ecs.soton.ac.uk> <2147483647.1081180497@[10.1.1.109]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2147483647.1081180497@[10.1.1.109]> 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 Mon, Apr 05, 2004 at 03:54:57PM +0200, Martin Stiemerling wrote: > > Hmm, I don't see any assumption saying that there will be IPv6 NATs. The > document ist just saying that the MIDCOM server can be reached via IPv6, > whether there is a NAT at the box or not is a different story. Taken from the intro draft-tran-midcom-dhcpv6-option-01: "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. A DHCPv6 option provides a means for these entities to determine the Midcom middleboxes IPv6 address or the domain name." But that text is cut and paste from the IPv4 version of the draft. Perhaps the v6 version can omit mention of translators? (If people use it for that, so be it, but we're not then "suggesting" it...) Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 5 15:39: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 PAA29547; Mon, 5 Apr 2004 15:39:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAZvx-0002av-6t; Mon, 05 Apr 2004 15:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAZvB-0002QR-Fh for dhcwg@optimus.ietf.org; Mon, 05 Apr 2004 15:38:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29441 for ; Mon, 5 Apr 2004 15:38:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAZv9-0000oz-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 15:38:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAZVr-00069H-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 15:12:04 -0400 Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com) by ietf-mx with esmtp (Exim 4.12) id 1BAZJr-0003oU-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 14:59:39 -0400 Received: from conversion-daemon.endeavor.poss.com by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <0HVP00H01OD269@endeavor.poss.com> for dhcwg@ietf.org; Mon, 05 Apr 2004 14:59:09 -0400 (EDT) Received: from kan1 (user184.net858.oh.sprint-hsd.net [69.34.23.184]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HVP002C1OQJL6@endeavor.poss.com> for dhcwg@ietf.org; Mon, 05 Apr 2004 14:59:08 -0400 (EDT) Date: Mon, 05 Apr 2004 15:00:38 -0400 From: "Kevin A. Noll" In-reply-to: <20040405151025.GA12352@login.ecs.soton.ac.uk> To: dhcwg@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [dhcwg] Computation of T1, T2, and lease expiration time 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 Paragraph 2 of Section 4.4.1 of RFC2131 implies that T1, T2, and the lease expiration time are all computed relative to the time that the client sends the DHCPDISCOVER. Is this correct, or should these values be computed relative to the time that the client acquires the lease (i.e. when it receives the DHCPACK)? In a perfect world, the former would make sense because the time to get from DISCOVER to ACK should be just a couple of seconds at most. In a not so perfect world, the latter would make sense. For example, if the network or DHCP server is not performing very well, it may take many seconds and several retries to actually get from DISCOVER to ACK. If this happens and the DISCOVER time is the reference, then there could be a considerable discrepency between the client's and server's notion of when the lease should expire. Am I correct, or did I miss another section of the document that clarifies this? --kan-- -- Kevin A. Noll, KD4WOZ CCIE 10948, CCDP Perfect Order, Inc. Kevin.Noll@perfectorder.com 717-796-1936 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 5 16:06: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 QAA04049; Mon, 5 Apr 2004 16:06:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaM6-00042J-Pu; Mon, 05 Apr 2004 16:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaLg-0003wB-GV for dhcwg@optimus.ietf.org; Mon, 05 Apr 2004 16:05:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03872 for ; Mon, 5 Apr 2004 16:05:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAaLe-0004qg-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 16:05:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAaFd-0003mA-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 15:59:22 -0400 Received: from smtp2.usherbrooke.ca ([132.210.244.18]) by ietf-mx with esmtp (Exim 4.12) id 1BAa1S-0001NT-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 15:44:43 -0400 Received: from kamel (traj1901.gel.usherb.ca [132.210.72.178]) by smtp2.usherbrooke.ca (8.12.8/8.12.8) with ESMTP id i35JiMvj023712; Mon, 5 Apr 2004 15:44:22 -0400 From: "Joel Tran" To: "'Bernie Volz'" , Cc: Subject: RE : [dhcwg] Internet Drafts to be reviewed by the dhc WG - midcom options Date: Mon, 5 Apr 2004 15:43:20 -0400 Message-ID: <000b01c41b46$3fdaefb0$b248d284@kamel> 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: <000001c41aab$356f8f90$6401a8c0@amer.cisco.com> X-UdeS-MailScanner-Information: Veuillez consulter le http://www.usherbrooke.ca/vers/virus-courriel X-UdeS-MailScanner: Aucun code suspect =?ISO-8859-1?Q?d=E9tect=E9?= X-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-4.9, requis 5, autolearn=not spam, BAYES_00 -4.90) X-MailScanner-From: joel.tran@usherbrooke.ca 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: , Hi Bernie, Thanks for your input, The two versions -00 and -01 are identical due to some posting mistakes made with the DHCPv4 document. I reposted the two documents (DHCPv4/DHCPv6) to avoid all confusions. I will fix the topo mistake in the next version. We use of two options (IP addresses/DNS addresses) for a reason. IP have less overhead (implementation of a DNS client). However, in some large corporate networks, DNS SRV could be used in order to provide a distributed Midcom service. ...J > -----Message d'origine----- > De : Bernie Volz [mailto:volz@cisco.com] > Envoyé : 4 avril, 2004 21:13 > À : joel.tran@usherbrooke.ca; soumaya.cherkaoui@usherbrooke.ca > Cc : dhcwg@ietf.org > Objet : RE: [dhcwg] Internet Drafts to be reviewed by the dhc > WG - midcom options > > > Here's some nits regarding > draft-tran-midcom-dhcpv6-option-00.txt (and also -01 which is > now posted but identical): > > - Abstract: "Dynamic Host Configuration Protocol for IPv6" > would be better than "Dynamic Host Configuration Protocol version 6". > > - 1 Terminology: MIDCOM should be Midcom to be consistent > with usage throughout doc? Functionnality should be > functionality. There's also a bunch of non 7-bit ASCII > characters in the "Midcom Agent" definition? > > - 2 Introduction: "the domain name[s] of the Midcom". And, > also "or the domain name[s] of Midcom middleboxes". (Make plural!) > > - 4 Midcom Middlebox DHCPv6 Option - "list of [] 128-bit [] > IPv6 addresses or, preferably, [a] DNS [RFC1035] domain name[s]." > > - 4.2 Midcom Middlebox IPv4 Address List - should be "IPv6", not IPv4. > > - Table 1 (in Section 5.2): There is a MUST, but this is only > if there is an address configured. > > - 5.2 Midcom Middlebox DHCPv6 Server Option Operation: "This > server MAY send one" ... Is use of "MAY" correct here? I > think it should be "This server should send ..."? The table > provides the rules. > > I haven't looked at draft-tran-midcom-dhcp-option-01.txt > (DHCPv4 option) > - but some of the above nits likely apply there as well. > > > I don't see anything particularily wrong with these DHCPv6 > options, though as I posted the other day, I think the DHC WG > should take on the issue as to whether this is the best way > to handle the ability to configure addresses and domain names > (two options), or whether, as Ted suggested in a response to > my post, to send only addresses. > > I guess a good question to Joel and Soumaya is whether just > sending addresses would cause any significant issues? > > - Bernie Volz > > > -----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 Mon Apr 5 16:08: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 QAA04298; Mon, 5 Apr 2004 16:08:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaO4-00051F-Dp; Mon, 05 Apr 2004 16:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaNM-0004cs-Ky for dhcwg@optimus.ietf.org; Mon, 05 Apr 2004 16:07:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04188 for ; Mon, 5 Apr 2004 16:07:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAaNL-00059K-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 16:07:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAaJJ-0004Ms-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 16:03:11 -0400 Received: from smtp2.usherbrooke.ca ([132.210.244.18]) by ietf-mx with esmtp (Exim 4.12) id 1BAa7W-0002Io-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 15:50:58 -0400 Received: from kamel (traj1901.gel.usherb.ca [132.210.72.178]) by smtp2.usherbrooke.ca (8.12.8/8.12.8) with ESMTP id i35JoSvj027193; Mon, 5 Apr 2004 15:50:28 -0400 From: "Joel Tran" To: "'Tim Chown'" , "'Martin Stiemerling'" Cc: "'Ralph Droms'" , , , , "'Melinda Shore'" Subject: RE : [dhcwg] Internet Drafts to be reviewed by the dhc WG Date: Mon, 5 Apr 2004 15:49:27 -0400 Message-ID: <000c01c41b47$1a4f7760$b248d284@kamel> 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: <20040405151025.GA12352@login.ecs.soton.ac.uk> X-UdeS-MailScanner-Information: Veuillez consulter le http://www.usherbrooke.ca/vers/virus-courriel X-UdeS-MailScanner: Aucun code suspect =?ISO-8859-1?Q?d=E9tect=E9?= X-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-4.9, requis 5, autolearn=not spam, BAYES_00 -4.90) X-MailScanner-From: joel.tran@usherbrooke.ca 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: , When I wrote the document, my intention was not to make a debate nor promote whatever there will be IPv6 NAT. As Tim suggested, I will change on the next version the text concerning the NAT in order to avoid all "suggestions" possible. ...J > -----Message d'origine----- > De : dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] De la > part de Tim Chown > Envoyé : 5 avril, 2004 11:10 > À : Martin Stiemerling > Cc : Ralph Droms; dhcwg@ietf.org; margaret@thingmagic.com; > narten@us.ibm.com; Melinda Shore > Objet : Re: [dhcwg] Internet Drafts to be reviewed by the dhc WG > > > On Mon, Apr 05, 2004 at 03:54:57PM +0200, Martin Stiemerling wrote: > > > > Hmm, I don't see any assumption saying that there will be > IPv6 NATs. > > The > > document ist just saying that the MIDCOM server can be > reached via IPv6, > > whether there is a NAT at the box or not is a different story. > > Taken from the intro draft-tran-midcom-dhcpv6-option-01: > > "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. > A DHCPv6 option provides a means for these entities to > determine the > Midcom middleboxes IPv6 address or the domain name." > > But that text is cut and paste from the IPv4 version of the > draft. Perhaps the v6 version can omit mention of > translators? (If people use it for that, so be it, but we're > not then "suggesting" it...) > > 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 Mon Apr 5 16:54: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 QAA07638; Mon, 5 Apr 2004 16:54:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAb6b-0008Ob-D0; Mon, 05 Apr 2004 16:54:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAb66-0008Bx-G2 for dhcwg@optimus.ietf.org; Mon, 05 Apr 2004 16:53:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07383 for ; Mon, 5 Apr 2004 16:53:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAb64-0002Ec-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 16:53:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAaix-00077E-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 16:29:40 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1BAaN2-000561-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 16:07:00 -0400 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 E615F1B233F; Mon, 5 Apr 2004 15:00:51 -0500 (CDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) 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] Computation of T1, T2, and lease expiration time Date: Mon, 5 Apr 2004 15:06:53 -0500 To: "Kevin A. Noll" 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 Apr 5, 2004, at 2:00 PM, Kevin A. Noll wrote: > In a not so perfect world, the latter would make sense. For > example, if the network or DHCP server is not performing very > well, it may take many seconds and several retries to actually > get from DISCOVER to ACK. If this happens and the DISCOVER time > is the reference, then there could be a considerable discrepency > between the client's and server's notion of when the lease > should expire. Speaking in terms of what the RFC says, it says that the client should assume that the lease is computed from the time it sent the first DHCPDISCOVER. So if the T1 or T2 time, plus the time that the first DHCPDISCOVER was sent, is less than the current time, then you do indeed have a problem. However, if you are running such short leases that this becomes a real issue, you will probably have lots of problems, and this will be the least of them. Practically speaking, I am not aware of any DHCP servers that do not compute the T1 and T2 times and the actual lease expiry time relative to the time when they generate the last DHCPACK they send to the client. But I wouldn't write a client that makes this assumption. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 5 17:21: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 RAA10176; Mon, 5 Apr 2004 17:21:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAbWf-0000Li-BA; Mon, 05 Apr 2004 17:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAbWB-0000A8-Ih for dhcwg@optimus.ietf.org; Mon, 05 Apr 2004 17:20:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10152 for ; Mon, 5 Apr 2004 17:20:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAbW9-0005mj-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 17:20:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAbEI-0003lX-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 17:02:03 -0400 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 1BAb26-0001Ln-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 16:49:26 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 05 Apr 2004 12:57:34 +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 i35KmrUe029445; Mon, 5 Apr 2004 13:48:54 -0700 (PDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHJ39835; Mon, 5 Apr 2004 16:48:52 -0400 (EDT) From: "Bernie Volz" To: "'Kevin A. Noll'" , Subject: RE: [dhcwg] Computation of T1, T2, and lease expiration time Date: Mon, 5 Apr 2004 16:48:51 -0400 Organization: Cisco Message-ID: <004501c41b4f$67260dd0$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: 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.1 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 think the text you refer to is: The client records the lease expiration time as the sum of the time at which the original request was sent and the duration of the lease from the DHCPACK message. And, the question is what does "original request" refer to - the DISCOVER or REQUEST? To be completely safe, using the DISCOVER would be best (since that will result in the shortest lease / T1 / T2 times for the client). But, I think practially speaking that REQUEST is OK. But, any client and server need to be prepared for some grace period for leases as there is no requirement that the client and server have synchronized clocks and their individual clocks may run fast or slow. Perhaps this would be item to include in a future revision of draft-ietf-dhc-implementation-01.txt? - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Kevin A. Noll Sent: Monday, April 05, 2004 3:01 PM To: dhcwg@ietf.org Subject: [dhcwg] Computation of T1, T2, and lease expiration time Paragraph 2 of Section 4.4.1 of RFC2131 implies that T1, T2, and the lease expiration time are all computed relative to the time that the client sends the DHCPDISCOVER. Is this correct, or should these values be computed relative to the time that the client acquires the lease (i.e. when it receives the DHCPACK)? In a perfect world, the former would make sense because the time to get from DISCOVER to ACK should be just a couple of seconds at most. In a not so perfect world, the latter would make sense. For example, if the network or DHCP server is not performing very well, it may take many seconds and several retries to actually get from DISCOVER to ACK. If this happens and the DISCOVER time is the reference, then there could be a considerable discrepency between the client's and server's notion of when the lease should expire. Am I correct, or did I miss another section of the document that clarifies this? --kan-- -- Kevin A. Noll, KD4WOZ CCIE 10948, CCDP Perfect Order, Inc. Kevin.Noll@perfectorder.com 717-796-1936 _______________________________________________ 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 Apr 5 17:46: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 RAA10732; Mon, 5 Apr 2004 17:46:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAbur-0005Ho-O0; Mon, 05 Apr 2004 17:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAbtx-00057G-OS for dhcwg@optimus.ietf.org; Mon, 05 Apr 2004 17:45:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10651 for ; Mon, 5 Apr 2004 17:45:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAbtv-0007jR-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 17:45:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAbHi-0004Mp-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 17:05:35 -0400 Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com) by ietf-mx with esmtp (Exim 4.12) id 1BAbAe-000341-00 for dhcwg@ietf.org; Mon, 05 Apr 2004 16:58:16 -0400 Received: from conversion-daemon.endeavor.poss.com by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <0HVP00601TX6K7@endeavor.poss.com> for dhcwg@ietf.org; Mon, 05 Apr 2004 16:57:47 -0400 (EDT) Received: from kan1 (user184.net858.oh.sprint-hsd.net [69.34.23.184]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HVP0026KU89L6@endeavor.poss.com>; Mon, 05 Apr 2004 16:57:46 -0400 (EDT) Date: Mon, 05 Apr 2004 16:59:15 -0400 From: "Kevin A. Noll" Subject: RE: [dhcwg] Computation of T1, T2, and lease expiration time In-reply-to: <004501c41b4f$67260dd0$d0412ca1@amer.cisco.com> To: Bernie Volz , dhcwg@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) 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.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 As usual, I missed that section of text. Actually, I was referring to this sentence in paragraph two: The client records its own local time for later use in computing the lease expiration. The client then broadcasts the DHCPDISCOVER... If you consider both of these paragraphs, it appears that the timers should be calculated from the DHCPDISCOVER. I would be in favor of including this for clarification in a future version of draft-ietf-dhc-implementation-01.txt. --kan-- > -----Original Message----- > From: Bernie Volz [mailto:volz@cisco.com] > Sent: Monday, 05 April, 2004 4:49 PM > To: 'Kevin A. Noll'; dhcwg@ietf.org > Subject: RE: [dhcwg] Computation of T1, T2, and lease expiration time > > > I think the text you refer to is: > > The client records the lease expiration time as the sum of > the time at which the original request was sent and the duration of > the lease from the DHCPACK message. > > And, the question is what does "original request" refer to - the > DISCOVER or REQUEST? > > To be completely safe, using the DISCOVER would be best (since that will > result in the shortest lease / T1 / T2 times for the client). But, I > think practially speaking that REQUEST is OK. > > But, any client and server need to be prepared for some grace period for > leases as there is no requirement that the client and server have > synchronized clocks and their individual clocks may run fast or slow. > > Perhaps this would be item to include in a future revision of > draft-ietf-dhc-implementation-01.txt? > > - Bernie > > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of > Kevin A. Noll > Sent: Monday, April 05, 2004 3:01 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Computation of T1, T2, and lease expiration time > > > > Paragraph 2 of Section 4.4.1 of RFC2131 implies that T1, > T2, and the lease expiration time are all computed relative > to the time that the client sends the DHCPDISCOVER. > > Is this correct, or should these values be computed relative > to the time that the client acquires the lease (i.e. when it receives > the DHCPACK)? > > In a perfect world, the former would make sense because the time to get > from DISCOVER to ACK should be just a couple of > seconds at most. > > In a not so perfect world, the latter would make sense. For example, if > the network or DHCP server is not performing very well, it may take many > seconds and several retries to actually get from DISCOVER to ACK. If > this happens and the DISCOVER time > is the reference, then there could be a considerable discrepency > between the client's and server's notion of when the lease > should expire. > > Am I correct, or did I miss another section of the document that > clarifies this? > > --kan-- > -- > Kevin A. Noll, KD4WOZ > CCIE 10948, CCDP > Perfect Order, Inc. > Kevin.Noll@perfectorder.com > 717-796-1936 > > > _______________________________________________ > 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 Apr 6 05:26: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 FAA26495; Tue, 6 Apr 2004 05:26:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAmpL-0005vb-Jd; Tue, 06 Apr 2004 05:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAmoJ-0005IS-FV for dhcwg@optimus.ietf.org; Tue, 06 Apr 2004 05:23:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26016 for ; Tue, 6 Apr 2004 05:23:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAmoF-0004YC-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 05:23:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAmho-0003Dv-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 05:17:18 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BAmQg-0000JV-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 04:59:34 -0400 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 i368x39l090001 for ; Tue, 6 Apr 2004 10:59:05 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i368t0id089518 for ; Tue, 6 Apr 2004 10:55:00 +0200 (CEST) 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 i368sw9h089507; Tue, 06 Apr 2004 10:55:00 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 4063211DBC6; Tue, 6 Apr 2004 10:54:57 +0200 (CEST) Date: Tue, 06 Apr 2004 10:54:54 +0200 From: Martin Stiemerling To: Tim Chown Cc: Ralph Droms , 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: <2147483647.1081248894@[10.1.1.109]> In-Reply-To: <20040405151025.GA12352@login.ecs.soton.ac.uk> References: <4.3.2.7.2.20040331131912.02663cc0@flask.cisco.com> <20040331205044.GL20993@login.ecs.soton.ac.uk> <2147483647.1081180497@[10.1.1.109]> <20040405151025.GA12352@login.ecs.soton.ac.uk> X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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.1 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 Tim, --On Montag, 5. April 2004 16:10 Uhr +0100 Tim Chown wrote: | On Mon, Apr 05, 2004 at 03:54:57PM +0200, Martin Stiemerling wrote: |> |> Hmm, I don't see any assumption saying that there will be IPv6 NATs. The |> document ist just saying that the MIDCOM server can be reached via IPv6, |> whether there is a NAT at the box or not is a different story. | | Taken from the intro draft-tran-midcom-dhcpv6-option-01: | | "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. | A DHCPv6 option provides a means for these entities to determine the | Midcom middleboxes IPv6 address or the domain name." | | But that text is cut and paste from the IPv4 version of the draft. | Perhaps the v6 version can omit mention of translators? (If people use | it for that, so be it, but we're not then "suggesting" it...) The text gives the freedom to read it different ways. As a MIDCOM guy I do read it as "the configuration protocol's endpoint address might be IPv6 capable, but not the middlebox engine (=firewall and/or NAT)". But indeed I see the point of given a more elaborated text. Martin _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 6 10:09: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 KAA20654; Tue, 6 Apr 2004 10:09:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BArG9-0006fj-3W; Tue, 06 Apr 2004 10:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BArFE-0006H0-I3 for dhcwg@optimus.ietf.org; Tue, 06 Apr 2004 10:08:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20089 for ; Tue, 6 Apr 2004 10:08:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BArFC-0007Ai-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 10:08:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAr2Z-0004mf-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 09:55:00 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAqXT-0001bv-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 09:22:51 -0400 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 i36DMgOr019841; Tue, 6 Apr 2004 14:22:42 +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 OAA06336; Tue, 6 Apr 2004 14:22:41 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i36DMf627040; Tue, 6 Apr 2004 14:22:41 +0100 Date: Tue, 6 Apr 2004 14:22:41 +0100 From: Tim Chown To: Martin Stiemerling Cc: Ralph Droms , 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: <20040406132241.GB26625@login.ecs.soton.ac.uk> Mail-Followup-To: Martin Stiemerling , 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> <20040331205044.GL20993@login.ecs.soton.ac.uk> <2147483647.1081180497@[10.1.1.109]> <20040405151025.GA12352@login.ecs.soton.ac.uk> <2147483647.1081248894@[10.1.1.109]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2147483647.1081248894@[10.1.1.109]> 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, Apr 06, 2004 at 10:54:54AM +0200, Martin Stiemerling wrote: > | > | "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. > | A DHCPv6 option provides a means for these entities to determine the > | Midcom middleboxes IPv6 address or the domain name." > | > | But that text is cut and paste from the IPv4 version of the draft. > | Perhaps the v6 version can omit mention of translators? (If people use > | it for that, so be it, but we're not then "suggesting" it...) > > The text gives the freedom to read it different ways. As a MIDCOM guy I do > read it as "the configuration protocol's endpoint address might be IPv6 > capable, but not the middlebox engine (=firewall and/or NAT)". > But indeed I see the point of given a more elaborated text. I guess you're too close to the protocol to read it without assumptions :) "Midcom middleboxes, such as firewalls and network address translators" then "Midcom middleboxes IPv6 address" implies IPv6 NAT... Just take the NAT reference out for the IPv6 option? Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 6 10:11: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 KAA21083; Tue, 6 Apr 2004 10:11:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BArI5-0007wj-J8; Tue, 06 Apr 2004 10:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BArHB-00078F-J0 for dhcwg@optimus.ietf.org; Tue, 06 Apr 2004 10:10:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20808 for ; Tue, 6 Apr 2004 10:10:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BArH9-0007aZ-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 10:10:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAr9z-00063C-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 10:02:41 -0400 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 1BAqpR-0002w0-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 09:41:25 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 06 Apr 2004 05:49:41 +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 i36DemUi014326; Tue, 6 Apr 2004 06:40:52 -0700 (PDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHJ78280; Tue, 6 Apr 2004 09:39:45 -0400 (EDT) From: "Bernie Volz" To: , "'Dhcwg'" Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-3315id-for-v4-02.txt + LAST CALL Comments Date: Tue, 6 Apr 2004 09:39:44 -0400 Organization: Cisco Message-ID: <001901c41bdc$9ebd07c0$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 Importance: Normal 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.1 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 Barr: I don't think a new option is such a good idea. If a new option is used, how does a client know when to send it or the 'old' client identifier option? This forces 'new' clients to send both - at least in the DISCOVER (older servers would not echo back the new option in the OFFER and new servers would could send back just the new option). This goes against your proposed text for 4.1, "but MUST NOT send both." Barr, Ted & Bill: I'm also not completely happy with encoding the IAID and DUID in a single option. The main reason I don't like this is that it forces the server to do something that we don't really want it to do - pull apart the data in the client identifier option - the option data is no longer 'opaque'. Note that it will be important for the DHCP server to do this for: 1. Dynamic DNS updates since the client identifier is only the DUID portion (see section 3.3 of draft-ietf-dnsext-dhcid-rr-07.txt). 2. Client based policies (ie, reservations) or limits, since these will want to look just at the DUID portion. But, there is an advantage to encoding the IAID and DUID in the option as it supports current DHCP server implementations. Without this, a client that has multiple interfaces (either connected to the same link or not) that are serviced by a single DHCP server might not get multiple addresses. I guess given the lessor of the two evils, I'm inclined to go along with the option as you've proposed it in the draft. So, I support this document moving forward. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Richard Barr Hibbs Sent: Monday, March 15, 2004 6:10 PM To: Dhcwg Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-3315id-for-v4-02.txt 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 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 6 21:59: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 VAA24599; Tue, 6 Apr 2004 21:59:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB2LF-0003IX-56; Tue, 06 Apr 2004 21:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB2KL-00035Y-AV for dhcwg@optimus.ietf.org; Tue, 06 Apr 2004 21:58:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24365 for ; Tue, 6 Apr 2004 21:58:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB2KI-0004cJ-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 21:58:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB1Vl-0005sP-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 21:05:50 -0400 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 1BB0Mn-0006Ji-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 19:52:29 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 06 Apr 2004 16:00:50 +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 i36NpvKj019912 for ; Tue, 6 Apr 2004 16:51:57 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-83.cisco.com [10.86.240.83]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHK35113; Tue, 6 Apr 2004 19:51:56 -0400 (EDT) Message-Id: <4.3.2.7.2.20040406194739.02bc8208@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Apr 2004 19:51:53 -0400 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] 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: , The IESG is reviewing draft-ietf-dhc-leasequery-07.txt and there are several "discuss" issues that have been raised by IESG members. The full text of these issues is available at https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1185&filename=draft-ietf-dhc-leasequery It is appropriate for the discussion about these issues to appear on the WG mailing list and I encourage WG members to participate in the discussion. I will post initial messages about each of these issues (as there is some overlap, I will group a couple of issues together into a single thread) to the dhcwg mailing list. Please review the issues and contribute to the discussion... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 6 22:02: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 WAA25207; Tue, 6 Apr 2004 22:02:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB2OG-0004UR-0A; Tue, 06 Apr 2004 22:02:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB2Nj-0004Kv-Ly for dhcwg@optimus.ietf.org; Tue, 06 Apr 2004 22:01:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25058 for ; Tue, 6 Apr 2004 22:01:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB2Ng-0005AZ-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 22:01:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB1cy-0006bn-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 21:13:17 -0400 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 1BB0Qx-000754-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 19:56:47 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 06 Apr 2004 16:03:58 +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 i36NuGGF006643 for ; Tue, 6 Apr 2004 16:56:16 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-83.cisco.com [10.86.240.83]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHK35294; Tue, 6 Apr 2004 19:56:14 -0400 (EDT) Message-Id: <4.3.2.7.2.20040406195254.02bc7b90@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Apr 2004 19:56:12 -0400 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] Security for leasequery messages 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 following issues relate to security for leasequery messages: Steve Bellovin: Discuss: (26 March 2004) The Security Considerations section says this: DHCP servers SHOULD prevent exposure of location information (particularly the mapping of hardware address to IP address lease, which can be an invasion of broadband subscriber privacy) by employing some form of relay agent authentication between the DHCPLEASEQUERY client and the DHCP server. Clients of the DHCPLEASEQUERY message SHOULD ensure that their data path to the DHCP server is secure. Clients SHOULD use Relay Agent Information security as a way to achieve this goal. What is "some form of ... authentication"? What is "Relay Agent Information security"? Put another way, what is mandatory to implement? Russ Housley: Discuss: Section 7 says: > > DHCP servers SHOULD prevent exposure of location information > (particularly the mapping of hardware address to IP address lease, > which can be an invasion of broadband subscriber privacy) by > employing some form of relay agent authentication between the > DHCPLEASEQUERY client and the DHCP server. > There needs to be more discussion of the authentication requirements. I would prefer the specification to name a mandatory-to-implement mechanism, but that may be asking too much. Section 7 also says: > > Clients of the DHCPLEASEQUERY message SHOULD ensure that their data > path to the DHCP server is secure. > What security services are needed? Integrity, authentication, access control, replay protection confidentiality? The hint about Relay Agent Information security, with no reference, is not sufficient. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 6 22:21:13 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 WAA28325; Tue, 6 Apr 2004 22:21:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB2ff-0001wN-Co; Tue, 06 Apr 2004 22:20:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB2fJ-0001qW-4N for dhcwg@optimus.ietf.org; Tue, 06 Apr 2004 22:19:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27974 for ; Tue, 6 Apr 2004 22:19:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB2fF-00006p-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 22:19:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB2Bt-0003J7-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 21:49:22 -0400 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 1BB1GE-0004Gl-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 20:49:46 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 06 Apr 2004 16:58:08 +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 i370nDKl014185 for ; Tue, 6 Apr 2004 17:49:15 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-83.cisco.com [10.86.240.83]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHK37488; Tue, 6 Apr 2004 20:49:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20040406204605.02c44d40@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Apr 2004 20:47:23 -0400 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] Leasequery protocol 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: , Thomas Narten: Discuss: I wonder if the following is a possible protocol issue: Assume a client is connected to access concentrator A, and obtains a lease. Client moves to concentrator B, and obtains a second lease. B looses state, and issues lease query. Server will return two addresses. How does B know which addresses (and location info) applies to it (i.e, B) rather than A? Is there info in the protocol messages that allows B to determine which address is its? E.g., does the relay-agent info include such an identification in it? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 6 22:21:13 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 WAA28324; Tue, 6 Apr 2004 22:21:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB2ff-0001wV-P9; Tue, 06 Apr 2004 22:20:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB2fJ-0001qb-OV for dhcwg@optimus.ietf.org; Tue, 06 Apr 2004 22:19:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27977 for ; Tue, 6 Apr 2004 22:19:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB2fG-00006v-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 22:19:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB2Bt-0003JH-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 21:49:23 -0400 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 1BB1GE-0004Gl-01 for dhcwg@ietf.org; Tue, 06 Apr 2004 20:49:46 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 06 Apr 2004 16:58:09 +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 i370nDKj014185 for ; Tue, 6 Apr 2004 17:49:13 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-83.cisco.com [10.86.240.83]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHK37486; Tue, 6 Apr 2004 20:49:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20040406204419.02cbedd0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Apr 2004 20:44:59 -0400 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] Specific applications for leasequery 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: , Harald Alvestrand: Comment: Reviewed by Lucy Lynch, Gen-ART Summary of review: This draft is very clearly written, and well organized. My only question has to do with "other processes and devices" (not a show stooper). The abstract states that "Other processes and devices, many that already send and receive DHCP format packets, sometimes need to access this information". Much of the draft is focused on "access concentrator"s (see for example section 5), a list of those other potenial uses might be helpful. I also notice a number of lower case shoulds & musts in this section which may actually be 2119 keywords and should be reviewed in that light. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 6 22:21:13 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 WAA28326; Tue, 6 Apr 2004 22:21:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB2fg-0001we-3V; Tue, 06 Apr 2004 22:20:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB2fK-0001qg-Pq for dhcwg@optimus.ietf.org; Tue, 06 Apr 2004 22:19:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27980 for ; Tue, 6 Apr 2004 22:19:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB2fH-000071-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 22:19:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB2Bu-0003JO-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 21:49:22 -0400 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 1BB1GF-0004Gl-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 20:49:47 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 06 Apr 2004 16:58:10 +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 i370nDKn014185 for ; Tue, 6 Apr 2004 17:49:17 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-83.cisco.com [10.86.240.83]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHK37489; Tue, 6 Apr 2004 20:49:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20040406204724.02cc3b08@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Apr 2004 20:49:08 -0400 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] Specifying what a DHCP server must implement for leasequery 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: , Thomas Narten: Discuss: Make it absolutely clear what a server must implement (in terms of the options it must store), especially in the case of options that already exist, but that a server may not be required to store. E.g, what is required for this spec that is different from normal DHC. relay agent option, client identifier (??). Specific comments: > o Query by IP address: > > For this query, the requester supplies only an IP address in the > DHCPLEASEQUERY message. The DHCP server will return any > information that it has on the most recent client to have been > assigned that IP address. make clear what info must be echoed back, esp. relay agent option, since there is no requirement in existing DHC that a server store it... _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 6 22:21: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 WAA28419; Tue, 6 Apr 2004 22:21:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB2gZ-0002Ha-GH; Tue, 06 Apr 2004 22:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB2fl-00022T-IJ for dhcwg@optimus.ietf.org; Tue, 06 Apr 2004 22:20:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28078 for ; Tue, 6 Apr 2004 22:20:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB2fi-0000Bg-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 22:20:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB2DP-0003Zf-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 21:50:58 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BB1Jv-0004ZW-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 20:53:35 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 06 Apr 2004 18:03:06 -0700 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 i370r4cp012754 for ; Tue, 6 Apr 2004 20:53:05 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-83.cisco.com [10.86.240.83]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHK37617; Tue, 6 Apr 2004 20:53:03 -0400 (EDT) Message-Id: <4.3.2.7.2.20040406205056.02cc3c10@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Apr 2004 20:53:01 -0400 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] Other comments on the leasequery spec 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: , Thomas Narten: Specific comments: > For this query, the requester supplies only a MAC address in the > DHCPLEASEQUERY message. The DHCP server will return any > information that it has on the IP address most recently accessed > by a client with that MAC address. In addition, it may supply > addition IP addresses which have been associated with that MAC > address in different subnets. Information about these bindings > can then be found using the Query by IP Address, described > above. may or does above? (multiple occurrences) Seems like this should be a MUST (in order for good interoperability/correctness). I.e., if only one address is returned (when there are several) it might be the wrong address and incorrect behavior may result. > Any DHCP server which supports the DHCPLEASEQUERY message should save > the information from the most recent Relay Agent Information option > (option 82) [RFC 3046] associated with every IP address which it > serves. It is assumed that most clients which generate the seems like should -> MUST. > A server which implements DHCPLEASEQUERY should also save the > information on the most recent Vendor class identifier, option 60, > associated with each IP address, since this option is also a likely > candidate to be requested by clients sending the DHCPLEASEQUERY > message. Why? How is this info useful to the relay agent? Also, for interoperabilty, SHOULD->MUST?? > client-last-transaction-time is this really critical? How is it used? Document doesn't say. > o DHCPLEASEUNASSIGNED > > The server MUST respond with a DHCPLEASEUNASSIGNED message if > this server has information about the IP address, but there is > no active lease for the IP address. The DHCPLEASEUNASSIGNED > message is only returned for a query by IP address, and > indicates that the server manages this IP address but there is > no currently active lease on this IP address. Are any DHC options returned? I'd assume no, but it would be good to say that explicitely. > If the "ciaddr" field is zero in a DHCPLEASEQUERY message, then the > IP address placed in the "ciaddr" field of a DHCPLEASEACTIVE message > MUST be that of an IP address for which the client that most recently > used the IP address matches the Client-identifier or MAC address > specified in the DHCPLEASEQUERY message. wording: not "must recently used" but the one who currently owns the lease. Right? > In the case where more than one IP address has been accessed by the > client specified by the MAC address or Client-identifier option, then > the DHCP server MUST return the IP address returned to the client in > the most recent transaction with the client unless the DHCP server > has been configured by the server administrator to use some other > preference mechanism. Shouldn't it return _all_ the addresses? Above reads like only one address needs to be returned. > If the Client-identifier option (option 61) is specified in the > Parameter Request List option (option 55), then the Client-identifier > (if any) of the client associated with the IP address in the "ciaddr" > field SHOULD be returned in the DHCPLEASEACTIVE message. Does a server already normally store the client identifier option? I.e., is this required already? > In the case where more than one IP address has been involved in a > DHCP message exchange with the client specified by the MAC address > and/or Client-identifier option, then the list of all of the IP > addresses SHOULD be returned in the associated-ip option (option > TBD), if that option was requested as part of the Parameter Request > List option. Seems potentially problematic for a client to ask for just one, and get only one, if there are many. It might get back the wrong one and do the wrong thing. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Apr 7 18:37: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 SAA18021; Wed, 7 Apr 2004 18:37:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBLfM-0004cU-D5; Wed, 07 Apr 2004 18:37:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBLfI-0004Xo-OJ for dhcwg@optimus.ietf.org; Wed, 07 Apr 2004 18:37:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18004 for ; Wed, 7 Apr 2004 18:36:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBLfF-0000VB-00 for dhcwg@ietf.org; Wed, 07 Apr 2004 18:36:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBKGL-0003Sq-00 for dhcwg@ietf.org; Wed, 07 Apr 2004 17:07:11 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1BBIGE-00068P-00 for dhcwg@ietf.org; Wed, 07 Apr 2004 14:58:54 -0400 Received: from [10.224.137.82] (m6a8d36d0.tmodns.net [208.54.141.106]) by toccata.fugue.com (Postfix) with ESMTP id 573993A1DB1 for ; Wed, 7 Apr 2004 13:52:28 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <4.3.2.7.2.20040403072041.029964c8@flask.cisco.com> References: <4.3.2.7.2.20040403072041.029964c8@flask.cisco.com> Content-Type: multipart/mixed; boundary=Apple-Mail-4--25803957 Message-Id: From: Ted Lemon Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 Date: Wed, 7 Apr 2004 12:56:51 -0500 To: dhcwg@ietf.org 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 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: , --Apple-Mail-4--25803957 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit I have a bunch of suggested changes to this draft, which fall into three categories: 1. A single change to the protocol itself. 2. Editorial changes - I think there was some extra text in this draft explaining proxy servers that isn't needed, and generate questions during the IESG review, so I'm suggesting that it be deleted. 3. Copyediting. There were some minor spelling and grammatical errors. The change to the protocol is that it currently specifies an encapsulation of suboptions, like option 82, but allows for the appearance of multiple suboptions, which is different than the behavior specified for handling options in RFC3396. This is not a huge problem, but it probably requires additional code in DHCP servers and clients that isn't necessary, so I'd suggest changing it so that if you want to specify multiple proxy servers for the same protocol, you should just list more than one IP address/port tuple in the suboption for that protocol. I've enclosed a diff for all the changes. --Apple-Mail-4--25803957 Content-Type: application/octet-stream; x-unix-mode=0644; name="draft-ietf-dhc-proxyserver-opt-00.txt.diffs" Content-Disposition: attachment; filename=draft-ietf-dhc-proxyserver-opt-00.txt.diffs Content-Transfer-Encoding: quoted-printable ***=20draft-ietf-dhc-proxyserver-opt-00.txt.orig=09Wed=20Apr=20=207=20= 11:53:23=202004=0A---=20draft-ietf-dhc-proxyserver-opt-00.txt=09Wed=20= Apr=20=207=2012:45:24=202004=0A***************=0A***=2081,107=20****=0A=20= =201.=20Terminologies=20Used=0A=20=20=0A=20=20=20=20=20=20=20=20=20=20= DHCP=20Client:=20A=20DHCP=20[1]=20client=20is=20an=20Internet=20host=20= that=20uses=0A!=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20DHCP=20= to=20obtain=20configuration=20information=20such=20as=20network=0A!=20=09= =20=20=20=20=20=20=20=20address.=0A=20=20=0A!=20=20=20=20=20=20=20=20=20= DHCP=20Server:=20A=20DHCP=20server=20is=20an=20Internet=20host=20that=20= returns=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= configuration=20parameters=20to=20DHCP=20clients.=0A=20=20=0A!=20=20=20=20= =20=20=20=20=20Proxy=20Server:=20In=20a=20enterprise=20network=20that=20= connects=20to=20Internet,=0A!=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20a=20proxy=20server=20is=20a=20server=20that=20acts=20as=20an=20= intermediary=0A!=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= between=20a=20workstation=20user=20and=20the=20Internet=20so=20that=20= the=0A!=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20enterprise=20= can=20ensure=20security,=20administrative=20control,=0A!=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20and=20caching=20service.=20A=20Proxy=20= server=20MAY=20be=20associated=20with=0A!=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20or=20part=20of=20a=20gateway=20server=20that=20= separates=20the=20enterprise=0A!=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20network=20from=20the=20outside=20network=20(Usually=20Internet)=0A= !=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20and=20a=20firewall=20= server=20that=20protects=20the=20enterprise=20network=0A!=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20from=20outside=20intrusion.=0A=20=20=0A= !=20=20=20=20=20=20=20=20=20=20HTTP:=20=20A=20protocol=20(RFC=202068,=20= Hypertext=20Transfer=20Protocol,=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20utilizing=20TCP)=20to=20transfer=20hypertext=20request=20= and=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= information=20between=20servers=20and=20browsers.=0A=20=20=0A!=20=20=20=20= =20=20=20=20=20=20FTP:=20=20=20A=20protocol=20(RFC=20959,=20File=20= Transfer=20Protocol=20Utilizing=20TCP)=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20that=20allows=20users=20to=20copy=20file(s)=20= between=20their=20local=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20system=20and=20any=20other=20system,=20which=20is=20reachable=20= on=20the=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= network.=0A---=2081,101=20----=0A=20=201.=20Terminologies=20Used=0A=20=20= =0A=20=20=20=20=20=20=20=20=20=20DHCP=20Client:=20A=20DHCP=20[1]=20= client=20is=20an=20Internet=20host=20that=20uses=0A!=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20DHCP=20to=20obtain=20configuration=20= information=20such=20as=20its=0A!=20=09=09network=20address.=0A=20=20=0A= !=20=20=20=20=20=20=20=20=20DHCP=20Server:=20A=20DHCP=20server=20is=20an=20= Internet=20host=20that=20provides=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20configuration=20parameters=20to=20DHCP=20clients.=0A=20=20= =0A!=20=20=20=20=20=20=20=20=20Proxy=20Server:=20A=20server=20that=20= acts=20as=20an=20intermediary=20between=20a=0A!=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20host=20and=20the=20Internet,=20providing=20data=20= filtering,=0A!=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= administrative=20control,=20and/or=20caching.=0A=20=20=0A!=20=20=20=20=20= =20=20=20=20HTTP:=20=20=20A=20protocol=20(RFC=202068,=20Hypertext=20= Transfer=20Protocol,=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20utilizing=20TCP)=20to=20transfer=20hypertext=20request=20and=20=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20information=20between=20= servers=20and=20browsers.=0A=20=20=0A!=20=20=20=20=20=20=20=20=20FTP:=20=20= =20=20A=20protocol=20(RFC=20959,=20File=20Transfer=20Protocol=20= Utilizing=20TCP)=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= that=20allows=20users=20to=20copy=20file(s)=20between=20their=20local=20=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20system=20and=20any=20= other=20system,=20which=20is=20reachable=20on=20the=20=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20network.=0A***************=0A***=20= 123,135=20****=0A=20=20=20=20=20=20=20=20=20Gopher:=20=20A=20Protocol=20= (RFC=201436)=20designed=20for=20distributed=20document=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20search=20and=20retrieval.=0A=20=20=0A= !=20=20=20=20=20=20=20=20=20SOCKS:=20=20SOCKSv5=20is=20an=20approved=20= standard=20(RFC=201928)=20generic,=0A=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20proxy=20protocol=20for=20TCP/IP=20based=20networking=20= applications.=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= The=20SOCKS=20protocol=20provides=20flexible=20framework=20for=20=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20developing=20secure=20= communications=20by=20easily=20integrating=20=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20other=20security=20technologies.=0A=20=20=0A!=20= =20=20=20=20=20=20=20=20WAIS=20:=20=20A=20protocol=20(Wide=20Area=20= Information=20Server)=20designed=20for=20=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20wide-area=20networked-baed=20information=20= system=20for=20searching,=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20browsing=20and=20publishing.=0A=20=20=0A---=20117,129=20----=0A=20= =20=20=20=20=20=20=20=20Gopher:=20=20A=20Protocol=20(RFC=201436)=20= designed=20for=20distributed=20document=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20search=20and=20retrieval.=0A=20=20=0A!=20=20=20=20=20= =20=20=20SOCKS:=20=20=20SOCKSv5=20is=20an=20approved=20standard=20(RFC=20= 1928)=20generic,=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= proxy=20protocol=20for=20TCP/IP=20based=20networking=20applications.=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20The=20SOCKS=20= protocol=20provides=20flexible=20framework=20for=20=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20developing=20secure=20communications=20= by=20easily=20integrating=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20other=20security=20technologies.=0A=20=20=0A!=20=20=20=20=20=20= =20=20WAIS=20:=20=20=20A=20protocol=20(Wide=20Area=20Information=20= Server)=20designed=20for=20=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20wide-area=20networked-baed=20information=20system=20for=20= searching,=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= browsing=20and=20publishing.=0A=20=20=0A***************=0A***=20137,149=20= ****=0A=20=20=0A=20=20=20=20=20The=20Dynamic=20Host=20Configuration=20= Protocol=20[1]=20provides=20a=20framework=20for=20=0A=20=20=20=20=20= passing=20configuration=20information=20to=20hosts=20on=20a=20TCP/IP=20= network.=0A!=20=20=20=20However,=20the=20configuration=20capability=20= provided=20by=20DHCP=20does=20not=0A!=20=20=20=20include=20Proxy(HTTP,=20= FTP,=20NNTP,=20Gopher=20etc.)server=20configuration=20to=0A!=20=20=20=20= be=20used=20so=20as=20to=20have=20controlled=20and/or=20efficient=20= access=20to=20the=0A!=20=20=20=20Internet=20from=20within=20a=20= firewall/enterprise=20network.=0A=20=20=0A!=20=20=20=20Following=20= Figure,=20depicts=20the=20typical=20setup=20of=20a=20secure=20subnet=0A!=20= =20=20=20inside=20a=20firewall=20with=20Proxy=20server.=0A=20=20=0A=20=20= =20=20=20+---------------------------+=09=09+-----------+=0A=20=20=20=20=20= |=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20|=09=09|Remote=20HTTP|=09=0A---=20131,144=20----=0A=20=20=0A=20=20= =20=20=20The=20Dynamic=20Host=20Configuration=20Protocol=20[1]=20= provides=20a=20framework=20for=20=0A=20=20=20=20=20passing=20= configuration=20information=20to=20hosts=20on=20a=20TCP/IP=20network.=0A= !=20=20=20=20This=20document=20describes=20a=20DHCP=20configuration=20= option=20that=20can=20be=0A!=20=20=20=20used=20to=20inform=20a=20DHCP=20= client=20of=20the=20IP=20addresses=20of=20one=20or=20more=0A!=20=20=20=20= proxy=20services=20that=20are=20either=20available=20to=20it=20or=20that=20= must=20be=20used=0A!=20=20=20=20in=20order=20to=20access=20internet=20= services,=20for=20example=20through=20a=0A!=20=20=20=20corporate=20= firewall.=0A=20=20=0A!=20=20=20=20The=20following=20diagram=20depicts=20= a=20typical=20setup=20providing=20proxy=0A!=20=20=20=20service=20to=20= clients=20on=20a=20network=20that=20is=20protected=20by=20a=20firewall.=0A= =20=20=0A=20=20=20=20=20+---------------------------+=09=09+-----------+=0A= =20=20=20=20=20|=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20|=09=09|Remote=20HTTP|=09=0A***************=0A= ***=20160,180=20****=0A=20=20=09=09=09=09=20=20+------------>|Server=09=20= =20=20=20|=0A=20=20=09=09=09=09=09=20=20=20=20=20=20=20=20+-----------+=0A= =20=20=0A!=20=20=20=20The=20primary=20use=20of=20proxies=20is=20to=20= allow=20access=20to=20the=20WWW=20=0A!=20=20=20=20(World=20Wide=20Web)=20= from=20within=20a=20firewall.=20A=20proxy=20is=20a=20special=20=0A!=20=20= =20=20software=20typically=20runs=20on=20firewall=20machine,=20waits=20= for=20a=20request=20=0A!=20=20=20=20from=20inside=20the=20firewall,=20= forwards=20the=20request=20to=20the=20remote=20server=0A!=20=20=20=20= outside=20the=20firewall,=20reads=20the=20response=20and=20then=20sends=20= it=20back=20to=0A!=20=20=20=20the=20client.=20Usually,=20all=20the=20= clients=20use=20the=20same=20proxy=20within=20a=20=0A!=20=20=20=20given=20= network,=20which=20helps=20in=20efficient=20caching=20of=20documents=20= that=20=0A!=20=20=20=20are=20requested=20by=20a=20number=20of=20clients.=20= This=20behavior=20makes=20proxies=20=0A!=20=20=20=20attractive=20to=20= clients=20not=20inside=20a=20firewall.=0A!=20=0A!=20=20=20=20Proxy=20= server=20increases=20the=20network=20security=20and=20user=20= productivity=20=0A!=20=20=20=20by=20content=20filtering=20and=20= controlling=20both=20internal=20and=20external=20=0A!=20=20=20=20access=20= to=20information.=20Also,=20it=20provides=20several=20other=20=0A!=20=20=20= =20functionalities=20that=20are=20not=20discussed=20here.=0A!=20=0A=20=20= =0A=20=20=0A=20=20Senthil=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20Expires=20Aug,=202004=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20[Page=203]=0A---=20155,165=20----=0A=20=20=09=09=09=09=20=20= +------------>|Server=09=20=20=20=20|=0A=20=20=09=09=09=09=09=20=20=20=20= =20=20=20=20+-----------+=0A=20=20=0A!=20=20=20=20The=20primary=20use=20= of=20proxies=20is=20to=20allow=20access=20to=20the=20World=20Wide=20Web=0A= !=20=20=20=20from=20within=20a=20firewall.=20A=20proxy=20service=20= typically=20runs=20on=20a=0A!=20=20=20=20firewall=20machine.=20=20It=20= waits=20for=20a=20request=20from=20inside=20the=20firewall,=0A!=20=20=20=20= forwards=20the=20request=20to=20the=20remote=20server=20outside=20the=20= firewall,=0A!=20=20=20=20reads=20the=20response=20and=20then=20sends=20= it=20back=20to=20the=20client.=0A=20=20=0A=20=20=0A=20=20Senthil=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Expires=20= Aug,=202004=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20[Page=203]=0A= ***************=0A***=20199,222=20****=0A=20=20=20=20=20=09=20= +-------+------+------+------+------+------+-....-+------+=0A=20=20=0A=20= =20=20=20=20Code=20is=20TBD=20as=20per=20RFC-2939=20[4].=20The=20length=20= N=20gives=20the=20total=20number=0A!=20=20=20=20of=20octets=20in=20the=20= Proxy=20Server=20Configuration=20Sub=20Option.=20The=20minimum=0A!=20=20=20= =20length=20is=208=20octets.=20The=20Proxy=20Server=20Configuration=20= sub=20option=20consists=20=0A!=20=20=20=20of=20a=20sequence=20of=20= SubOpt/Length/Value=20tuples=20for=20each=20sub=20option=20encoded=0A!=20= =20=20=20in=20the=20following=20manner:=0A!=20=0A!=20=20=20=20The=20= format=20Proxy=20Server=20Configuration=20sub=20Option=20is:=0A!=20=0A!=20= =20=20=20=09=20=20=20SubOpt=20=20=20Len=20=20=20=20=09=20IP=20Address=09=20= =20=20=20=20=20Port=20(2=20octet)=0A!=20=20=20=20=09=20= +-------+------+------+------+------+------+------+------+=0A!=20=20=20=20= =09=20|=20=20t=09=20|=20=20N=20=20=20|=20=20a1=20=20|=20=20a2=20=20|=20=20= a3=20=20|=20=20a4=20=20|=20=20=20=20port=20=20=20=20=20|=0A!=20=20=20=20=09= =20+-------+------+------+------+------+------+------+------+=0A!=20=0A!=20= =20=20=20More=20than=20one=20Sub=20Option=20MAY=20be=20specified=20for=20= the=20same=20protocol.=0A!=20=20=20=20In=20that=20case,=20the=20= precedence=20should=20be=20given=20in=20the=20order=20in=20which=0A!=20=20= =20=20these=20options=20are=20received=20by=20the=20client.=20The=20= first=20one=20received=0A!=20=20=20=20shall=20be=20given=20higher=20= priority=20and=20so=20on.=20The=20SubOpt=20field=20t=20=0A!=20=20=20=20= specifies=20the=20type=20of=20Protocol=20and=20MUST=20be=20one=20of=20= the=20protocol=20=0A!=20=20=20=20number.=0A=20=20=20=20=20=0A=20=20=20=20= =20=20=20=20=20+-------------------------------+=0A=20=20=20=20=20=20=20=20= =20|=20protocol=20=20=20=20=20|=20=20=20=20=20=20=20Number=20=20=20|=0A= ---=20184,225=20----=0A=20=20=20=20=20=09=20= +-------+------+------+------+------+------+-....-+------+=0A=20=20=0A=20= =20=20=20=20Code=20is=20TBD=20as=20per=20RFC-2939=20[4].=20The=20length=20= N=20gives=20the=20total=20number=0A!=20=20=20=20of=20octets=20in=20the=20= Proxy=20Server=20Configuration=20option,=20excluding=0A!=20=20=20=20the=20= code=20and=20length=20bytes,=20which=20are=20one=20octet=20each.=20The=20= minimum=0A!=20=20=20=20length=20is=208=20octets.=20=20=20The=20Proxy=20= Server=20Configuration=20option=0A!=20=20=20=20encapsulates=20one=20or=20= more=20Proxy=20Server=20Configuration=20suboptions,=0A!=20=20=20=20each=20= of=20which=20has=20a=20minimum=20length=20of=208=20octets.=20=20=20= Suboptions=20need=0A!=20=20=20=20not=20appear=20in=20any=20particular=20= order.=0A!=20=0A!=20[I'm=20sorry=20for=20not=20catching=20this=20sooner,=20= but=20it=20doesn't=20make=20sense=20to=0A!=20specify=20multiple=20= suboptions=20of=20the=20same=20type.=20=20=20Better=20to=20just=0A!=20= specify=20more=20than=20one=20IP=20address/port=20tuple=20within=20the=20= same=0A!=20suboption.=20=20=20The=20changes=20above=20and=20below=20= reflect=20this=20suggestion.=20=20=20I=0A!=20would=20say=20that=20this=20= is=20a=20necessary=20change,=20because=20otherwise=20the=0A!=20handling=20= of=20these=20suboptions=20is=20different=20than=20the=20handling=20of=20= other=0A!=20suboptions.]=0A!=20=0A!=20=20=20=20Each=20Proxy=20Server=20= Configuration=20suboption=20consists=20of=20a=20code,=20T,=0A!=20=20=20=20= which=20indicates=20thr=20protocol=20being=20proxied,=20followed=20by=20= a=20length,=0A!=20=20=20=20N,=20which=20is=20the=20length=20of=20the=20= entire=20suboption=20excluding=20the=20code=0A!=20=20=20=20and=20the=20= length=20bytes,=20followed=20by=20one=20or=20more=20pairs=20of=20IP=20= address=0A!=20=20=20=20and=20port,=20as=20follows:=0A!=20=0A!=20=20=20=20= =20=20+---+---+---+---+---+---+---+---+=20=20=20= +---+---+---+---+---+---+=0A!=20=20=20=20=20=20|=20T=20|=20N=20|=20IP=20= address=201=20=20|=20port=20=20|...|=20IP=20address=20N=20=20|=20port=20=20= |=0A!=20=20=20=20=20=20+---+---+---+---+---+---+---+---+=20=20=20= +---+---+---+---+---+---+=0A!=20=0A!=20=20=20=20The=20code=20(T)=20and=20= length=20(N)=20are=20one=20octet=20each;=20each=20IP=20address=20is=0A!=20= =20=20=20four=20octets,=20and=20each=20port=20number=20is=20a=20= two-octet=20integer=20encoded=0A!=20=20=20=20in=20network=20byte=20= order.=20=20=20The=20minimum=20value=20for=20N=20is=206.=0A!=20=0A!=20=20= =20=20In=20cases=20where=20it=20makes=20sense=20to=20specify=20more=20= than=20one=20proxy=0A!=20=20=20=20server=20for=20a=20given=20protocol,=20= these=20proxy=20servers=20MUST=20be=20specified=0A!=20=20=20=20as=20= additional=20IP=20addresses=20and=20ports=20within=20the=20same=20= suboption.=0A!=20=20=20=20The=20list=20is=20ordered=20by=20precedence,=20= with=20the=20most=20preferred=20proxy=0A!=20=20=20=20server=20appearing=20= first=20in=20the=20list,=20and=20the=20least=20preferred=20proxy=0A!=20=20= =20=20server=20appearing=20last=20in=20the=20list.=20=20=20The=20DHCP=20= client=20SHOULD=20honor=0A!=20=20=20=20this=20ordering.=0A=20=20=20=20=20= =0A=20=20=20=20=20=20=20=20=20+-------------------------------+=0A=20=20=20= =20=20=20=20=20=20|=20protocol=20=20=20=20=20|=20=20=20=20=20=20=20= Number=20=20=20|=0A***************=0A***=20230,235=20****=0A---=20= 233,241=20----=0A=20=20=20=20=20=20=20=20=20|=20=20=20Gopher=20=20=20=20=20= |=20=20=20=20=20=20=20=20=20TBD=20=20=20=20|=0A=20=20=20=20=20=20=20=20=20= +-------------------------------+=0A=20=20=20=20=20=20=20=20=20|=20=20=20= SSL=20=20=20=20=20=20=20=20|=20=20=20=20=20=20=20=20=20TBD=20=20=20=20|=0A= +=20[what=20does=20it=20mean=20to=20have=20an=20SSL=20proxy?=20=20=20I=20= don't=20think=20this=20makes=0A+=20sense=20-=20you=20really=20can't=20= proxy=20SSL,=20because=20the=20certificate=20check=0A+=20would=20fail.]=0A= =20=20=20=20=20=20=20=20=20+-------------------------------+=0A=20=20=20=20= =20=20=20=20=20|=20=20=20SOCKS=20=20=20=20=20=20|=20=20=20=20=20=20=20=20= =20TBD=20=20=20=20|=0A=20=20=20=20=20=20=20=20=20= +-------------------------------+=0A***************=0A***=20242,265=20= ****=0A=20=20=0C=0A=20=20Internet-Draft=20=20=20=20DHCP=20Option=20for=20= Proxy=20Server=20Configuration=20=20=20Feb=202004=0A=20=20=0A!=20=20=20=20= DHCP=20server=20should=20send=20the=20port=20field=20(port=20number)=20= in=20Network=20Byte=0A!=20=20=20=20Order.=0A!=20=0A!=205.=20Option=20= Usage=0A=20=20=0A!=20=20=20=20The=20Proxy=20Server=20Configuration=20= field=20shall=20NOT=20be=20terminated=20with=20a=0A!=20=20=20=20255=20= sub-option.=20=20The=20length=20N=20of=20the=20DHCP=20Proxy=20Server=20= Configuration=0A!=20=20=20=20Option=20shall=20include=20all=20bytes=20of=20= the=20sub-option=20code/length/value=0A!=20=20=20=20tuples.=20The=20= length=20N=20of=20the=20sub-options=20shall=20be=20the=20number=20of=20= octets=0A!=20=20=20=20in=20only=20that=20sub-option's=20value=20field.=20= The=20port=20MUST=20be=20a=20valid=0A!=20=20=20=20TCP/UDP=20port.=20The=20= minimum=20length=20of=20a=20sub-option=20is=206=20octets.=20=0A!=20=20=20= =20The=20sub-options=20need=20not=20appear=20in=20protocol=20type=20= order.=0A!=20=0A!=208.=20Security=20Considerations=0A!=20=0A!=20=20=20=20= =20The=20DHCP=20Options=20defined=20here=20allow=20an=20interloper=20= DHCP=20server=20to=0A!=20=20=20=20=20misdirect=20a=20client=20to=20= access=20nonexistent/erring=20Proxy=20Server=20due=20to=20=0A!=20=20=20=20= =20which=20the=20connection=20to=20the=20Internet=20might=20be=20denied.=0A= =20=20=20=20=20=0A=20=20=20=20=20=20DHCP=20provides=20an=20= authentication=20mechanism,=20as=20described=20in=20RFC=203118=0A=20=20=20= =20=20=20[3],=20which=20may=20be=20used=20if=20authentication=20is=20= required.=0A---=20248,261=20----=0A=20=20=0C=0A=20=20Internet-Draft=20=20= =20=20DHCP=20Option=20for=20Proxy=20Server=20Configuration=20=20=20Feb=20= 2004=0A=20=20=0A!=205.=20Security=20Considerations=0A=20=20=0A!=20=20=20=20= =20The=20DHCP=20Options=20defined=20here=20allows=20an=20interloper=20= DHCP=20server=20to=0A!=20=20=20=20=20misdirect=20a=20client,=20causing=20= it=20to=20access=20a=20nonexistent=20or=0A!=20=20=20=20=20malicious=20= proxy=20server.=20=20=20This=20allows=20for=20a=20denial=20of=20service=20= or=0A!=20=20=20=20=20man-in-the-middle=20attack.=20=20=20This=20is=20a=20= well-known=20property=20of=20the=0A!=20=20=20=20=20DHCP=20protocol;=20= this=20option=20does=20not=20create=20any=20additional=20risk=20of=0A!=20= =20=20=20=20such=20attacks.=0A=20=20=20=20=20=0A=20=20=20=20=20=20DHCP=20= provides=20an=20authentication=20mechanism,=20as=20described=20in=20RFC=20= 3118=0A=20=20=20=20=20=20[3],=20which=20may=20be=20used=20if=20= authentication=20is=20required.=0A***************=0A***=20270,277=20****=0A= =20=20=20=20=20IANA=20is=20requested=20to=20assign=20an=20option=20code=20= to=20the=20Proxy=20Server=0A=20=20=20=20=20Configuration=20Option=20and=20= protocol=20numbers=20for=20the=20sub=20option.=0A=20=20=0A!=20=20=20=20= IANA=20is=20also=20requested=20to=20maintain=20a=20new=20number=20space=20= for=20the=20=0A!=20=20=20=20Proxy=20Server=20Configuration=20sub=20= options.=0A=20=20=0A=20=2010.=20Acknowledgements=0A=20=20=0A---=20= 266,273=20----=0A=20=20=20=20=20IANA=20is=20requested=20to=20assign=20an=20= option=20code=20to=20the=20Proxy=20Server=0A=20=20=20=20=20Configuration=20= Option=20and=20protocol=20numbers=20for=20the=20sub=20option.=0A=20=20=0A= !=20=20=20=20IANA=20is=20also=20requested=20to=20maintain=20a=20new=20= number=20space=20for=20Proxy=0A!=20=20=20=20Server=20Configuration=20sub=20= option=20codes.=0A=20=20=0A=20=2010.=20Acknowledgements=0A=20=20=0A= --Apple-Mail-4--25803957-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Apr 7 20:39: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 UAA22953; Wed, 7 Apr 2004 20:39:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBNZO-0006aI-9V; Wed, 07 Apr 2004 20:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBNZL-0006Za-Sx for dhcwg@optimus.ietf.org; Wed, 07 Apr 2004 20:38:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22849 for ; Wed, 7 Apr 2004 20:38:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBNZJ-0003uW-00 for dhcwg@ietf.org; Wed, 07 Apr 2004 20:38:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBLGH-0005n8-00 for dhcwg@ietf.org; Wed, 07 Apr 2004 18:11:11 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BBKA2-0002UL-00 for dhcwg@ietf.org; Wed, 07 Apr 2004 17:00:38 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 07 Apr 2004 13:57:22 -0700 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 i37L06cp017219; Wed, 7 Apr 2004 17:00:06 -0400 (EDT) Received: from kkinnear-w2k03.cisco.com ([161.44.65.230]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHL11713; Wed, 7 Apr 2004 17:00:04 -0400 (EDT) Message-Id: <4.3.2.7.2.20040407164610.026a2930@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 Apr 2004 17:00:03 -0400 To: Ralph Droms , dhcwg@ietf.org From: Kim Kinnear Subject: Re: [dhcwg] Other comments on the leasequery spec Cc: kkinnear@cisco.com In-Reply-To: <4.3.2.7.2.20040406205056.02cc3c10@flask.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 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 08:53 PM 4/6/2004, Ralph Droms wrote: >Thomas Narten: > >Specific comments: > >> For this query, the requester supplies only a MAC address in the >> DHCPLEASEQUERY message. The DHCP server will return any >> information that it has on the IP address most recently accessed >> by a client with that MAC address. In addition, it may supply >> addition IP addresses which have been associated with that MAC >> address in different subnets. Information about these bindings >> can then be found using the Query by IP Address, described >> above. > >may or does above? (multiple occurrences) Seems like this should be a >MUST (in order for good interoperability/correctness). I.e., if only >one address is returned (when there are several) it might be the >wrong address and incorrect behavior may result. Yes, it MUST supply them if any exist, so the client "may" or "may not" see any, depending on whether they exist. We'll fix this. >> Any DHCP server which supports the DHCPLEASEQUERY message should save >> the information from the most recent Relay Agent Information option >> (option 82) [RFC 3046] associated with every IP address which it >> serves. It is assumed that most clients which generate the > >seems like should -> MUST. Sure. Except that you said that section 5 couldn't have SHOULD or MUST's in it, since it is the overview. >> A server which implements DHCPLEASEQUERY should also save the >> information on the most recent Vendor class identifier, option 60, >> associated with each IP address, since this option is also a likely >> candidate to be requested by clients sending the DHCPLEASEQUERY >> message. > >Why? How is this info useful to the relay agent? Some devices (notably DOCSIS) encode lots of stuff in the vendor-class-id. >Also, for >interoperabilty, SHOULD->MUST?? Sure, but again, we either need to rescind the prohibition on RFC 2119 keywords in the overview, or just make sure that we do this properly elsewhere (or both, of course). >> client-last-transaction-time > >is this really critical? How is it used? Document doesn't say. That certainly slipped through the cracks. The client-last-transaction time is what is used to decide the "latest" and therefore most important IP address to return in the ciaddr when the query is by MAC address or client-identifier. It is also used to order the list of other IP addresses, returned in the associated-ip option. We'll make sure that we add that somewhere. >> o DHCPLEASEUNASSIGNED >> >> The server MUST respond with a DHCPLEASEUNASSIGNED message if >> this server has information about the IP address, but there is >> no active lease for the IP address. The DHCPLEASEUNASSIGNED >> message is only returned for a query by IP address, and >> indicates that the server manages this IP address but there is >> no currently active lease on this IP address. > >Are any DHC options returned? I'd assume no, but it would be good to >say that explicitely. I agree with your assumption. We can certainly say that explicitly. >> If the "ciaddr" field is zero in a DHCPLEASEQUERY message, then the >> IP address placed in the "ciaddr" field of a DHCPLEASEACTIVE message >> MUST be that of an IP address for which the client that most recently >> used the IP address matches the Client-identifier or MAC address >> specified in the DHCPLEASEQUERY message. > >wording: not "must recently used" but the one who currently owns the >lease. Right? Yes. >> In the case where more than one IP address has been accessed by the >> client specified by the MAC address or Client-identifier option, then >> the DHCP server MUST return the IP address returned to the client in >> the most recent transaction with the client unless the DHCP server >> has been configured by the server administrator to use some other >> preference mechanism. > >Shouldn't it return _all_ the addresses? Above reads like only one >address needs to be returned. It returns the IP address associated with this client that was most recently accessed by this client. It returns this one and all of the others in the associated-ip option. We can make that more clear. >> If the Client-identifier option (option 61) is specified in the >> Parameter Request List option (option 55), then the Client-identifier >> (if any) of the client associated with the IP address in the "ciaddr" >> field SHOULD be returned in the DHCPLEASEACTIVE message. > >Does a server already normally store the client identifier option? >I.e., is this required already? Yes. >> In the case where more than one IP address has been involved in a >> DHCP message exchange with the client specified by the MAC address >> and/or Client-identifier option, then the list of all of the IP >> addresses SHOULD be returned in the associated-ip option (option >> TBD), if that option was requested as part of the Parameter Request >> List option. > >Seems potentially problematic for a client to ask for just one, and >get only one, if there are many. It might get back the wrong one and >do the wrong thing. What is the "wrong" one? If it gets the one most recently accessed by the client, then that is only the wrong one if it wants something else. If it wants something else, it should ask for all of them. I guess I don't see the problem here. If you want the most recent, then you don't have to ask for them all. If you don't want the most recent, then you should ask for them all. Cheers -- Kim >_______________________________________________ >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 Apr 7 21:20: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 VAA00574; Wed, 7 Apr 2004 21:20:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBODG-0006c2-9n; Wed, 07 Apr 2004 21:20:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBOCx-0006Hc-I7 for dhcwg@optimus.ietf.org; Wed, 07 Apr 2004 21:19:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00414 for ; Wed, 7 Apr 2004 21:19:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBOCu-0002xF-00 for dhcwg@ietf.org; Wed, 07 Apr 2004 21:19:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBMU7-00053o-00 for dhcwg@ietf.org; Wed, 07 Apr 2004 19:29:32 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BBKah-00072m-00 for dhcwg@ietf.org; Wed, 07 Apr 2004 17:28:12 -0400 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 i37LRdKj014211 for ; Wed, 7 Apr 2004 14:27:39 -0700 (PDT) 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 AHL14335; Wed, 7 Apr 2004 17:27:38 -0400 (EDT) Message-Id: <4.3.2.7.2.20040407171155.02d49ac8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 Apr 2004 17:27:36 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 In-Reply-To: <4.3.2.7.2.20040403072041.029964c8@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=1.2 required=5.0 tests=AWL,OPT_HEADER 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: , One technical question: rather than allowing multiple instances of the same suboption, would it be possible to allow multiple servers to be specified in one instance of the suboption? If so, the number of proxy servers in the suboption would be reflected in the suboption length field, which would be 6*number-of-servers. I also have some editorial suggestions... The document should be revised to reflect the new boilerplate in RFC 3667. Use "suboption" throughout the document. I don't think HTTP, FTP, SSL, etc. need to appear in the Terminologies section. Those definitions could be replaced with references to the relevant RFCs in the body of the document. Section 2, first paragraph; replace "does not include Proxy(HTTP, FTP, NNTP, Gopher etc.)server configuration to be used" with "does not include a list of proxy servers for HTTP, FTP, NNTP, Gopher and other protocols to be used". Section 2, second paragraph: replace "Following Figure, depicts..." with "The following figure depicts..." Section 2, third paragraph: replace "special software typically runs on firewall machine" with "process that typically runs on a firewall" Section 2, fourth paragraph: replace "Proxy server" with "A proxy server". Section 4, second paragraph: replace "Code is TBD as per RFC-2939" with "Code is TBD and will be assigned by IANA according to RFC 2939" Section 4, fourth paragraph: the end of the last sentence should be modified to allow for new protocol numbers to be defined in the future. Section 4, fifth paragraph: should both the proxy server address and port nubmer be in network byte order? Sections 8 and higher should be renumbered (sections 6 and 7 are missing). _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Apr 7 22:06: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 WAA07220; Wed, 7 Apr 2004 22:06:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBOva-0004yo-CS; Wed, 07 Apr 2004 22:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBOvX-0004xU-2X for dhcwg@optimus.ietf.org; Wed, 07 Apr 2004 22:05:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07189 for ; Wed, 7 Apr 2004 22:05:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBOvU-0001pH-00 for dhcwg@ietf.org; Wed, 07 Apr 2004 22:05:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBNcA-0004RA-00 for dhcwg@ietf.org; Wed, 07 Apr 2004 20:41:55 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BBLNU-0006aw-00 for dhcwg@ietf.org; Wed, 07 Apr 2004 18:18:36 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i37MHbN17435; Wed, 7 Apr 2004 15:17:37 -0700 (PDT) Message-Id: <200404072217.i37MHbN17435@boreas.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, dhcwg@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 07 Apr 2004 15:17:36 -0700 X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-9.2 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.60 Subject: [dhcwg] RFC 3736 on Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 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 Request for Comments is now available in online RFC libraries. RFC 3736 Title: Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 Author(s): R. Droms Status: Standards Track Date: April 2004 Mailbox: rdroms@cisco.com Pages: 9 Characters: 18510 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dhc-dhcpv6-stateless-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3736.txt Stateless Dynamic Host Configuration Protocol service for IPv6 (DHCPv6) is used by nodes to obtain configuration information, such as the addresses of DNS recursive name servers, that does not require the maintenance of any dynamic state for individual clients. A node that uses stateless DHCP must have obtained its IPv6 addresses through some other mechanism, typically stateless address autoconfiguration. This document explains which parts of RFC 3315 must be implemented in each of the different kinds of DHCP agents so that agent can support stateless DHCP. This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040407151354.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3736 --OtherAccess Content-Type: Message/External-body; name="rfc3736.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040407151354.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Apr 8 15:58: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 PAA15480; Thu, 8 Apr 2004 15:58:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBfez-00053x-O9; Thu, 08 Apr 2004 15:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBfej-00053B-P8 for dhcwg@optimus.ietf.org; Thu, 08 Apr 2004 15:57:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15438 for ; Thu, 8 Apr 2004 15:57:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBfeh-0002BA-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 15:57:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB23w-0001p7-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 21:41:10 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BB0rX-0002Ot-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 20:24:15 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 06 Apr 2004 17:33:45 -0700 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 i370Nfcr009646 for ; Tue, 6 Apr 2004 20:23:44 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-83.cisco.com [10.86.240.83]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHK36475; Tue, 6 Apr 2004 20:23:40 -0400 (EDT) Message-Id: <4.3.2.7.2.20040406202208.02cc44c8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Apr 2004 20:23:07 -0400 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] Should the leasequery spec be reviewed by other WGs? 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: , Bert Wijnen: Discuss: - Have IPCDN and/or ADSLMIB WGs looked at this? Both CABLE and ADSL are used as typical examples of where this functionality would be used/needed. So I like to know what these WGs think of this. I see Rich Woundy as one of the authors, he is IPCDN co-chair, so possibly that aspect is OK. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Apr 8 15:58: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 PAA15481; Thu, 8 Apr 2004 15:58:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBff0-00054D-Gc; Thu, 08 Apr 2004 15:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBfen-00053L-Ky for dhcwg@optimus.ietf.org; Thu, 08 Apr 2004 15:57:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15444 for ; Thu, 8 Apr 2004 15:57:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBfel-0002Be-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 15:57:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB24W-0001wB-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 21:41:45 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BB0tZ-0002Yc-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 20:26:21 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 06 Apr 2004 17:23:34 -0700 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 i370PoCC002985 for ; Tue, 6 Apr 2004 20:25:50 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-83.cisco.com [10.86.240.83]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHK36571; Tue, 6 Apr 2004 20:25:49 -0400 (EDT) Message-Id: <4.3.2.7.2.20040406202408.02cc4ed8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Apr 2004 20:24:54 -0400 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] Should the leasequery spec explicitly be IPv4-specific? 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: , Bert Wijnen: Discuss: - It seems to be implicitly IPv4 specific without explaining/justifying why and uses "IP address" to mean IPv4 addresses only. Do we not want them to either be IPv4/v6 agnostic or to be specific in stating that they are IPv4 only if such is the case and justified? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Apr 8 16:45: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 PAA15479; Thu, 8 Apr 2004 15:58:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBff0-000545-4t; Thu, 08 Apr 2004 15:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBfej-00053C-SQ for dhcwg@optimus.ietf.org; Thu, 08 Apr 2004 15:57:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15439 for ; Thu, 8 Apr 2004 15:57:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBfeg-0002Ay-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 15:57:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB23w-0001p0-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 21:41:09 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BB0rV-0002Oj-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 20:24:13 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 06 Apr 2004 17:21:26 -0700 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 i370NeCE002384 for ; Tue, 6 Apr 2004 20:23:42 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-83.cisco.com [10.86.240.83]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHK36472; Tue, 6 Apr 2004 20:23:39 -0400 (EDT) Message-Id: <4.3.2.7.2.20040406201645.02cc2b08@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Apr 2004 20:20:37 -0400 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] Use of SNMP instead of leasequery 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: , Bert Wijnen: Discuss: - what is the status of this solution vs DHCP MIB solution (I thought they were competing solutions some time back). The DHC MIB has also been submitted for PS, no? I know it is still in MIB Doctor review... but it is a 2nd solution to same problem. - The reasonings for not using SNMP and MIB seem very weak to me Ted Hardie: Discuss: It's too bad that SNMP is off the table here, as that would give you a realistic way to limit data to specific queries and queriers. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Apr 8 16:45: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 PAA15478; Thu, 8 Apr 2004 15:58:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBfez-00053p-CQ; Thu, 08 Apr 2004 15:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBfee-00052i-U9 for dhcwg@optimus.ietf.org; Thu, 08 Apr 2004 15:57:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15431 for ; Thu, 8 Apr 2004 15:57:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBfed-0002Ad-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 15:57:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB22O-0001Wu-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 21:39:34 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BB0m4-0001y6-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 20:18:36 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 06 Apr 2004 17:28:06 -0700 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 i370I4cp009014 for ; Tue, 6 Apr 2004 20:18:04 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-83.cisco.com [10.86.240.83]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHK36195; Tue, 6 Apr 2004 20:18:03 -0400 (EDT) Message-Id: <4.3.2.7.2.20040406201536.01f62c28@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Apr 2004 20:16:37 -0400 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] Restrictions of information flow in leasequery messages 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: , Ted Hardie: Discuss: This whole method has "invitation to mischief" printed in large, block letters across its shirt. After being told repeatedly that there is no restriction on the use cases for this mechanism, this text: For this query, the requester supplies only an IP address in the DHCPLEASEQUERY message. The DHCP server will return any information that it has on the most recent client to have been assigned that IP address. sets off lots of alarm bells. If I read this right, *any information* associated with that IP address is returned? If information used to construct a location object is present (as in the geopriv dhcp-li draft), that would get returned? That seems kind of excessive for an access concentrator, but very, very nice for a black hat. This whole section on Parameter Request List options: 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. has no restrictions of any type on the return of any data. Why is all of this data being made available via this method? It's too bad that SNMP is off the table here, as that would give you a realistic way to limit data to specific queries and queriers. Limiting the protocol to a very specific use that fits the demonstrated need seems like it would make getting the security mechanisms right easier; if this is meant to be truly general purpose, it needs a general purpose mechanism that would give it the same level of security as SNMP would for this same purpose. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Apr 8 18: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 SAA00491; Thu, 8 Apr 2004 18:08:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBhgn-0000jA-9C; Thu, 08 Apr 2004 18:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBhgU-0000TO-Rj for dhcwg@optimus.ietf.org; Thu, 08 Apr 2004 18:07:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00377 for ; Thu, 8 Apr 2004 18:07:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBhgR-0002jx-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 18:07:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBfd4-0001zv-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 15:56:05 -0400 Received: from smtp802.mail.sc5.yahoo.com ([66.163.168.181]) by ietf-mx with smtp (Exim 4.12) id 1BAtug-0000qr-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 12:59:02 -0400 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.116.97 with login) by smtp802.mail.sc5.yahoo.com with SMTP; 6 Apr 2004 16:59:01 -0000 Reply-To: From: "Richard Barr Hibbs" To: "'Dhcwg'" Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-3315id-for-v4-02.txt + LAST CALL Comments Date: Tue, 6 Apr 2004 10:06:31 -0700 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <001901c41bdc$9ebd07c0$d0412ca1@amer.cisco.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: 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 > -----Original Message----- > From: Bernie Volz [mailto:volz@cisco.com] > Sent: Tuesday, 06 April 2004 06:40 > > I don't think a new option is such a good idea. > If a new option is used, how does a client know > when to send it or the 'old' client identifier > option? This forces 'new' clients to send both - > at least in the DISCOVER (older servers would > not echo back the new option in the OFFER > and new servers would could send back just the > new option). This goes against your proposed > text for 4.1, "but MUST NOT send both." > ...although I believe that when you significantly change both the syntax and semantics of an existing option it should be recast as a new option, I'll relent on that point... I also seem to have failed the transition test by requiring divine knowledge on the part of clients... oops.... > I'm also not completely happy with encoding the > IAID and DUID in a single option. > > The main reason I don't like this is that it > forces the server to do something that we don't > really want it to do - pull apart the data in > the client identifier option - the option data is > no longer 'opaque'. Note that it will be > important for the DHCP server to do this for: > 1. Dynamic DNS updates since the client > identifier is only the DUID portion (see section > 3.3 of draft-ietf-dnsext-dhcid-rr-07.txt). > 2. Client based policies (ie, reservations) or > limits, since these will want to look just at the > DUID portion. > I strongly believe that the client identifier should remain opaque to the server because to change the semantics is a significant change to the operation of existing servers. > But, there is an advantage to encoding the IAID > and DUID in the option as it supports current > DHCP server implementations. Without this, a > client that has multiple interfaces (either > connected to the same link or not) that are > serviced by a single DHCP server might not get > multiple addresses. > > I guess given the lesser of the two evils, I'm > inclined to go along with the option as you've > proposed it in the draft. > > So, I support this document moving forward. > ...I'd prefer this work to be incorporated into a revision of RFC2132, rather than creating a new RFC that will probably be obsoleted shortly after publication, which also gives us the opportunity to more fully consider the ramifications of altering the semantics of the client identifier in the context of DHCP-DNS dynamic updates. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Apr 8 18:11: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 SAA00813; Thu, 8 Apr 2004 18:11:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBhjh-0002DA-Cu; Thu, 08 Apr 2004 18:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBhj9-0001tM-5I for dhcwg@optimus.ietf.org; Thu, 08 Apr 2004 18:10:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00684 for ; Thu, 8 Apr 2004 18:10:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBhj5-00036Z-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 18:10:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBfeq-0002CN-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 15:57:53 -0400 Received: from smtp804.mail.sc5.yahoo.com ([66.163.168.183]) by ietf-mx with smtp (Exim 4.12) id 1BB3oF-0005hX-00 for dhcwg@ietf.org; Tue, 06 Apr 2004 23:33:03 -0400 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.116.97 with login) by smtp804.mail.sc5.yahoo.com with SMTP; 7 Apr 2004 03:33:03 -0000 Reply-To: From: "Richard Barr Hibbs" To: "Dhcwg" Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-reclassify-options-00 Date: Tue, 6 Apr 2004 20:40:35 -0700 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4.3.2.7.2.20040403074305.029b19b0@flask.cisco.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.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID 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 support advancing this draft, to reclassify DHCPv4 options in the range 128-223 as public, not private or vendor-specific options. --Barr > -----Original Message----- > From: Ralph Droms > Sent: Monday, 05 April 2004 05:46 > > Please respond to this WG last call. If you > support acceptance of the > document without change, respond with a simple > acknowledgment, so that > support for the document can be assessed. > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Apr 8 18:12: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 SAA00956; Thu, 8 Apr 2004 18:12:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBhkf-0002Yr-4L; Thu, 08 Apr 2004 18:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBhkE-0002Sq-SU for dhcwg@optimus.ietf.org; Thu, 08 Apr 2004 18:11:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00842 for ; Thu, 8 Apr 2004 18:11:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBhkB-0003JJ-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 18:11:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBfft-0002Kg-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 15:59:02 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BBCZv-0000m2-00 for dhcwg@ietf.org; Wed, 07 Apr 2004 08:54:51 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 07 Apr 2004 05:51:46 -0700 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 i37CsJCC022856 for ; Wed, 7 Apr 2004 08:54:19 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-8.cisco.com [10.86.242.8]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHK59049; Wed, 7 Apr 2004 08:54:18 -0400 (EDT) Message-Id: <4.3.2.7.2.20040407085147.01f90c68@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 Apr 2004 08:53:58 -0400 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=1.0 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Subject: [dhcwg] Revised 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: , Here is a draft charter for the WG, based on discussion at the WG meeting in Seoul and discussion on the mailing list. Please review and respond with comments. - Ralph dhc WG draft revised charter ---------------------------- The dhc working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCPv4 is currently a "Draft Standard" and is documented in RFC2131 and RFC2132. DHCPv6 is currently a "Proposed Standard" and is documented in RFC3315. Subsequent RFCS document additional options and other enhancements to the specifications. The DHC WG is responsible for reviewing (and sometimes developing) DHCP options or other extensions (for both IPv4 and IPv6). The DHC WG is expected to review all proposed extensions to DHCP to ensure that they are consistent with the DHCP specification and other option formats, that they do not duplicate existing mechanisms, etc. The DHC WG will not (generally) be responsible for evaluating the semantic content of proposed options. The DHC WG will not adopt new proposals for extensions to DHCP as working group documents without first coordinating with other relevant working groups and determining who has the responsibility for reviewing the semantic content of an option. The DHC WG has the following main objectives: * The DHC WG will address security in DHCP o Develop and document security requirements for DHCP. RFC 3118 defines current security mechanisms for DHCPv4. Unfortunately, RFC 3118 has neither been implemented nor deployed to date. Specific issues to be considered include: - Improved key management and scalability - Security for messages passed between relay agents and servers - Threats of DoS attacks through FORCERENEW - The increased usage of DHC on unsecured (e.g., wireless) and public LANs - The need for clients to be able to authenticate servers, without simultaneously requiring client authentication by the server. o Develop and document a roadmap of any new documents or protocols needed to meet the security requirements for DHCP * Write an analysis of the DHCP specification, including RFC2131, RFC2132 and other RFCs defining additional options, which identifies ambiguities, contradictory specifications and other obstacles to development of interoperable implementations. Recommend a process for resolving identified problems and incorporating the resolutions into the DHCP specification. * 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. * 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. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Apr 8 18:13: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 SAA01108; Thu, 8 Apr 2004 18:13:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBhld-0002sI-6S; Thu, 08 Apr 2004 18:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBhl0-0002iS-EV for dhcwg@optimus.ietf.org; Thu, 08 Apr 2004 18:12:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00922 for ; Thu, 8 Apr 2004 18:12:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBhkw-0003RI-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 18:12:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBfgs-0002QU-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 16:00:03 -0400 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 1BBJoz-00070h-00 for dhcwg@ietf.org; Wed, 07 Apr 2004 16:38:53 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 07 Apr 2004 12:46:13 +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 i37KcLn2000768; Wed, 7 Apr 2004 13:38:21 -0700 (PDT) Received: from kkinnear-w2k03.cisco.com ([161.44.65.230]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHL09670; Wed, 7 Apr 2004 16:38:19 -0400 (EDT) Message-Id: <4.3.2.7.2.20040407163537.02686008@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 Apr 2004 16:38:19 -0400 To: Ralph Droms , dhcwg@ietf.org From: Kim Kinnear Subject: Re: [dhcwg] Security for leasequery messages Cc: kkinnear@cisco.com In-Reply-To: <4.3.2.7.2.20040406195254.02bc7b90@flask.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 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, This is clearly an issue, and there are no easy answers. Here is one approach: Nothing is mandatory to implement, since one approach is to ensure that there is physical security between the access concentrator and the DHCP server. A better approach is to use some form of the not-yet-fully-baked relay agent authentication. For example: http://www.ietf.org/internet-drafts/draft-ietf-dhc-auth-suboption-03.txt but since this is still coming along, it can't be mandatory, that's for sure. We could wait to standardize leasequery until something was approved for relay agent authentication, but that will further delay something that has already undergone numerous delays. There are large number of similar-to-the-standard leasequery installations, and more every day. It would be nice to bring them all into compliance over time, and time is getting away from us. One approach would be to make something mandatory once that something exists, which is a little odd but perhaps doable. We might be able to say: "When some form of relay-agent to DHCP server authentication becomes a standard, its use for leasequery becomes mandatory." Something to consider. Any other ideas for handle this one? Cheers -- Kim At 07:56 PM 4/6/2004, Ralph Droms wrote: >The following issues relate to security for leasequery messages: > >Steve Bellovin: > >Discuss: >(26 March 2004) >The Security Considerations section says this: > > DHCP servers SHOULD prevent exposure of location information > (particularly the mapping of hardware address to IP address lease, > which can be an invasion of broadband subscriber privacy) by > employing some form of relay agent authentication between the > DHCPLEASEQUERY client and the DHCP server. > > Clients of the DHCPLEASEQUERY message SHOULD ensure that their data > path to the DHCP server is secure. Clients SHOULD use Relay Agent > Information security as a way to achieve this goal. > >What is "some form of ... authentication"? What is "Relay Agent Information >security"? Put another way, what is mandatory to implement? > >Russ Housley: > >Discuss: > Section 7 says: > > > > DHCP servers SHOULD prevent exposure of location information > > (particularly the mapping of hardware address to IP address lease, > > which can be an invasion of broadband subscriber privacy) by > > employing some form of relay agent authentication between the > > DHCPLEASEQUERY client and the DHCP server. > > > There needs to be more discussion of the authentication requirements. > I would prefer the specification to name a mandatory-to-implement > mechanism, but that may be asking too much. > > Section 7 also says: > > > > Clients of the DHCPLEASEQUERY message SHOULD ensure that their data > > path to the DHCP server is secure. > > > What security services are needed? Integrity, authentication, access > control, replay protection confidentiality? The hint about Relay Agent > Information security, with no reference, is not sufficient. > > > >_______________________________________________ >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 Apr 8 18:13: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 SAA01117; Thu, 8 Apr 2004 18:13:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBhld-0002vc-Rz; Thu, 08 Apr 2004 18:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBhl4-0002jc-Fu for dhcwg@optimus.ietf.org; Thu, 08 Apr 2004 18:12:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00942 for ; Thu, 8 Apr 2004 18:12:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBhl0-0003S6-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 18:12:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBfgu-0002Qt-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 16:00:05 -0400 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 1BBJt4-0007UM-00 for dhcwg@ietf.org; Wed, 07 Apr 2004 16:43:06 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 07 Apr 2004 12:51: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 i37KgVn4005995; Wed, 7 Apr 2004 13:42:34 -0700 (PDT) Received: from kkinnear-w2k03.cisco.com ([161.44.65.230]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHL10043; Wed, 7 Apr 2004 16:42:30 -0400 (EDT) Message-Id: <4.3.2.7.2.20040407163857.02690a00@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 Apr 2004 16:42:30 -0400 To: Ralph Droms , dhcwg@ietf.org From: Kim Kinnear Subject: Re: [dhcwg] Leasequery protocol issue Cc: kkinnear@cisco.com In-Reply-To: <4.3.2.7.2.20040406204605.02c44d40@flask.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 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 08:47 PM 4/6/2004, Ralph Droms wrote: >Thomas Narten: > >Discuss: >I wonder if the following is a possible protocol issue: > >Assume a client is connected to access concentrator A, and obtains a >lease. Client moves to concentrator B, and obtains a second lease. B >looses state, and issues lease query. Server will return two >addresses. How does B know which addresses (and location info) applies >to it (i.e, B) rather than A? Is there info in the protocol messages >that allows B to determine which address is its? E.g., does the >relay-agent info include such an identification in it? In some cases, I believe the relay agent info does indeed include sufficient information for the access concentrator to tell which address belongs to it. There is no requirement in the relay-agent-info RFC for that to be the case, however. I think we could suggest (i.e., SHOULD) in the leasequery draft that the relay-agent-info have such information for any access concentrator that is going to employ leasequery, and present the scenario that you describe above as motivation. >_______________________________________________ >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 Apr 8 18:13: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 SAA01140; Thu, 8 Apr 2004 18:13:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBhle-0002yB-J3; Thu, 08 Apr 2004 18:13:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBhl8-0002kk-2f for dhcwg@optimus.ietf.org; Thu, 08 Apr 2004 18:12:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00952 for ; Thu, 8 Apr 2004 18:12:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBhl4-0003Sm-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 18:12:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBfgy-0002RL-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 16:00:08 -0400 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 1BBJw1-000050-00 for dhcwg@ietf.org; Wed, 07 Apr 2004 16:46:09 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 07 Apr 2004 12:54:40 +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 i37KjaKj027941; Wed, 7 Apr 2004 13:45:37 -0700 (PDT) Received: from kkinnear-w2k03.cisco.com ([161.44.65.230]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHL10330; Wed, 7 Apr 2004 16:45:35 -0400 (EDT) Message-Id: <4.3.2.7.2.20040407164337.02692ff8@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 Apr 2004 16:45:34 -0400 To: Ralph Droms , dhcwg@ietf.org From: Kim Kinnear Subject: Re: [dhcwg] Specifying what a DHCP server must implement for leasequery Cc: kkinnear@cisco.com In-Reply-To: <4.3.2.7.2.20040406204724.02cc3b08@flask.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 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 08:49 PM 4/6/2004, Ralph Droms wrote: >Thomas Narten: > >Discuss: > >Make it absolutely clear what a server must implement (in terms of the >options it must store), especially in the case of options that already >exist, but that a server may not be required to store. E.g, what is >required for this spec that is different from normal DHC. relay agent >option, client identifier (??). The client-identifier must already be stored, or you don't have much of a DHCP server. I thought that we'd made the options to store and return clear, but obviously it isn't absolutely clear or we wouldn't have this issue, so we need to make it more clear. >Specific comments: > >> o Query by IP address: >> >> For this query, the requester supplies only an IP address in the >> DHCPLEASEQUERY message. The DHCP server will return any >> information that it has on the most recent client to have been >> assigned that IP address. > >make clear what info must be echoed back, esp. relay agent option, >since there is no requirement in existing DHC that a server store >it... > > >_______________________________________________ >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 Apr 8 18:14: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 SAA01299; Thu, 8 Apr 2004 18:14:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBhmc-0003Oc-5x; Thu, 08 Apr 2004 18:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBhm1-0003CK-FL for dhcwg@optimus.ietf.org; Thu, 08 Apr 2004 18:13:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01092 for ; Thu, 8 Apr 2004 18:13:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBhlx-0003bd-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 18:13:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBfiW-0002bd-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 16:01:44 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BBZT8-0006gX-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 09:21:22 -0400 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 i38DKmew013131 for ; Thu, 8 Apr 2004 06:20:48 -0700 (PDT) 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 AHL49118; Thu, 8 Apr 2004 09:20:47 -0400 (EDT) Message-Id: <4.3.2.7.2.20040408090911.02af0ed8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 Apr 2004 09:20:45 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-00 In-Reply-To: <4.3.2.7.2.20040403073841.029964c8@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=1.2 required=5.0 tests=AWL,OPT_HEADER 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 see that this draft includes a notice regarding IPR. The Samsung IPR statement appears to apply across all IETF submissions. Can the authors clarify if there are any IPR claims that apply specifically to this document? The format of the option - specifically, option length == 0 - is consistent with other DHCP options. Will length 0 cause problems in practice with deployed DHCP servers? The document should be republished to include RFC 3667 boilerplate, including the RFC 3667 IPR notification statement. I have one editorial comment: the document should indicate that the use of Rapid Commit is optional on the part of the client, under local (client) admin control. In section 3, I suggest changing the first sentence: A client that supports the Rapid Commit option SHOULD include it in DHCPDISCOVER messages that it sends. to: If a client that supports the Rapid Commit option intends to use the rapid commit capability, it includes a Rapid Commit option in DHCPDISCOVER messages that it sends. In section 3.1, list item 1, I suggest changing the first sentence: 1. The client broadcasts a DHCPDISCOVER message on its local physical subnet and SHOULD include the Rapid Commit option if it supports this option. to: 1. The client broadcasts a DHCPDISCOVER message on its local physical. If the client supports the Rapid Commit option and intends to use the rapid commit capability, it includes a Rapid Commit option in the DHCPDISCOVER message. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Apr 8 18:14: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 SAA01292; Thu, 8 Apr 2004 18:14:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBhmb-0003Kz-IO; Thu, 08 Apr 2004 18:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBhlz-0003Bx-J5 for dhcwg@optimus.ietf.org; Thu, 08 Apr 2004 18:13:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01087 for ; Thu, 8 Apr 2004 18:13:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBhlw-0003bB-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 18:13:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBfiR-0002b6-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 16:01:38 -0400 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 1BBYyS-000450-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 08:49:40 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 08 Apr 2004 04:58:19 +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 i38Cn7BB013075 for ; Thu, 8 Apr 2004 05:49:08 -0700 (PDT) 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 AHL47179; Thu, 8 Apr 2004 08:49:06 -0400 (EDT) Message-Id: <4.3.2.7.2.20040408084531.01f68fb8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 Apr 2004 08:49:04 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-3315id-for-v4-01 In-Reply-To: <4.3.2.7.2.20040403073217.029964c8@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: , Ted, Bill - can you give examples of real client identifiers and how those client identifiers would be used in the three examples you describe in section 2.2? I guess my question is getting at the problem of "requirements"; I think the document would be clarified by a section between 2 and 3 that summarizes the requirements for client identifiers, based on the problem examples in section 2. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Apr 8 19: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 SAA01293; Thu, 8 Apr 2004 18:14:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBhmb-0003Kr-5r; Thu, 08 Apr 2004 18:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBhlw-0003B7-O1 for dhcwg@optimus.ietf.org; Thu, 08 Apr 2004 18:13:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01070 for ; Thu, 8 Apr 2004 18:13:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBhlt-0003ar-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 18:13:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBfiM-0002aY-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 16:01:32 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BBYnO-0002ci-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 08:38:14 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 08 Apr 2004 05:47:59 -0700 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 i38CbgCC000084 for ; Thu, 8 Apr 2004 08:37:42 -0400 (EDT) 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 AHL46683; Thu, 8 Apr 2004 08:37:41 -0400 (EDT) Message-Id: <4.3.2.7.2.20040408083106.02ade250@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 Apr 2004 08:37:39 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-reclassify-options-00 In-Reply-To: <4.3.2.7.2.20040403074305.029b19b0@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.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID 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 document reflects WG consensus on how to make more DHCP option codes available to avoid exhaustion of the option code space. Although there are known uses of option codes in the range 128-254 (both documented and undocumented), the procedure described in this document provides a way to avoid clashes in the use of reclassified options. Editorial suggestions and comments: The references should be listed as Normative and Informative. Section 3, change the first sentence to: "The DHCP option space (0-255) is divided into two ranges [RFC2132]:" Reference [unused-optioncodes] has been published as RFC 3679. The document should include boilerplate from RFC 3667 when it is revised. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Apr 8 19:00: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 SAA01291; Thu, 8 Apr 2004 18:14:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBhma-0003Kj-Pk; Thu, 08 Apr 2004 18:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBhlu-0003Ab-Gv for dhcwg@optimus.ietf.org; Thu, 08 Apr 2004 18:13:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01065 for ; Thu, 8 Apr 2004 18:13:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBhlr-0003aa-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 18:13:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBfiI-0002a6-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 16:01:29 -0400 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 1BBYgp-0001tg-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 08:31:27 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 08 Apr 2004 04:40:06 +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 i38CUsGF012097 for ; Thu, 8 Apr 2004 05:30:55 -0700 (PDT) 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 AHL46356; Thu, 8 Apr 2004 08:30:53 -0400 (EDT) Message-Id: <4.3.2.7.2.20040408082319.01f3e948@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 Apr 2004 08:30:51 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-vendor-01 In-Reply-To: <4.3.2.7.2.20040403072717.029b01f8@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: , This specification provides a useful extension to the vendor class and vendor specific options capabilities in DHCP. The requirements for these capabilities are based on experience with competing uses for the existing vendor class and vendor specific options in DHCP deployments. I agree with the decision to define these two capabilities as separate options for simplicity and to minimize the requirement for RFC 3396 option concatenation. While the current DHCP option code space is nearing exhaustion, draft-ietf-dhc-reclassify-options (currently in WG last call) will increase the available option codes, reducing the need for option code conservation. The specification should separate the references into Normative and Informative, and should be updated to include the boilerplate from RFC 3667. Note to draft authors using xml2rfc: you can include the appropriate boilerplate in your docs by moving to version 1.22 and setting the ipr tag to "full3667". - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Apr 8 20:25: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 UAA14994; Thu, 8 Apr 2004 20:25:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjpU-0002fF-8O; Thu, 08 Apr 2004 20:25:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBit8-0005Mm-Ho for dhcwg@optimus.ietf.org; Thu, 08 Apr 2004 19:24:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07897 for ; Thu, 8 Apr 2004 19:24:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBit6-0004Km-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 19:24:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBhmB-0003eL-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 18:13:37 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BBflM-0002of-00; Thu, 08 Apr 2004 16:04:36 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 08 Apr 2004 13:00:41 -0700 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 i38K3sCC004603; Thu, 8 Apr 2004 16:03:55 -0400 (EDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHL91380; Thu, 8 Apr 2004 16:03:53 -0400 (EDT) From: "Bernie Volz" To: , Subject: RE: [dhcwg] Should the leasequery spec explicitly be IPv4-specific? Date: Thu, 8 Apr 2004 16:03:53 -0400 Organization: Cisco Message-ID: <002601c41da4$9dd1a220$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 Importance: Normal In-Reply-To: <4.3.2.7.2.20040406202408.02cc4ed8@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.1 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 YES! As this specification deals with DHCPv4 (is extends DHCPv4), it should be IPv4 specific. It is a separate issue as to whether corresponding functionality will be needed for DHCPv6 and something that the WG should take up. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ralph Droms Sent: Tuesday, April 06, 2004 8:25 PM To: dhcwg@ietf.org Subject: [dhcwg] Should the leasequery spec explicitly be IPv4-specific? Bert Wijnen: Discuss: - It seems to be implicitly IPv4 specific without explaining/justifying why and uses "IP address" to mean IPv4 addresses only. Do we not want them to either be IPv4/v6 agnostic or to be specific in stating that they are IPv4 only if such is the case and justified? _______________________________________________ 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 Apr 8 20:27: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 UAA15464; Thu, 8 Apr 2004 20:27:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjrW-00043h-ST; Thu, 08 Apr 2004 20:27:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjF5-0007oM-6C for dhcwg@optimus.ietf.org; Thu, 08 Apr 2004 19:47:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10833 for ; Thu, 8 Apr 2004 19:47:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjF2-0006UF-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 19:47:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBiIr-0007OX-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 18:47:21 -0400 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 1BBgPn-0001Yr-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 16:46:23 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 08 Apr 2004 12:53:55 +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 i38KjoKj018294; Thu, 8 Apr 2004 13:45:51 -0700 (PDT) Received: from kkinnear-w2k03.cisco.com ([161.44.65.230]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHL95419; Thu, 8 Apr 2004 16:45:49 -0400 (EDT) Message-Id: <4.3.2.7.2.20040408164453.0282ebd8@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 Apr 2004 16:45:47 -0400 To: Ralph Droms , dhcwg@ietf.org From: Kim Kinnear Subject: Re: [dhcwg] Should the leasequery spec explicitly be IPv4-specific? Cc: kkinnear@cisco.com In-Reply-To: <4.3.2.7.2.20040406202408.02cc4ed8@flask.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 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 08:24 PM 4/6/2004, Ralph Droms wrote: >Bert Wijnen: > >Discuss: >- It seems to be implicitly IPv4 specific without explaining/justifying why > and uses "IP address" to mean IPv4 addresses only. Do we not want them > to either be IPv4/v6 agnostic or to be specific in stating that they > are IPv4 only if such is the case and justified? This is really just an oversight -- leasequery is IPv4 specific. We'll fix the draft to make this clear. Cheers -- Kim >_______________________________________________ >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 Apr 8 20:28:09 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 UAA15622; Thu, 8 Apr 2004 20:28:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjrs-0004LV-1X; Thu, 08 Apr 2004 20:27:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjJE-00089o-UH for dhcwg@optimus.ietf.org; Thu, 08 Apr 2004 19:51:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11294 for ; Thu, 8 Apr 2004 19:51:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjJC-0006x5-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 19:51:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBiMX-00003v-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 18:51:11 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BBgVn-0002FN-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 16:52:35 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 08 Apr 2004 13:53:03 -0700 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 i38Kq1n2013771; Thu, 8 Apr 2004 13:52:02 -0700 (PDT) Received: from kkinnear-w2k03.cisco.com ([161.44.65.230]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHL96056; Thu, 8 Apr 2004 16:52:00 -0400 (EDT) Message-Id: <4.3.2.7.2.20040408164627.0283bf48@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 Apr 2004 16:52:00 -0400 To: Ralph Droms , dhcwg@ietf.org From: Kim Kinnear Subject: Re: [dhcwg] Restrictions of information flow in leasequery messages Cc: kkinnear@cisco.com In-Reply-To: <4.3.2.7.2.20040406201536.01f62c28@flask.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 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 08:16 PM 4/6/2004, Ralph Droms wrote: >Ted Hardie: > >Discuss: >This whole method has "invitation to mischief" printed in large, block letters across its >shirt. After being told repeatedly that there is no restriction on the use cases for this >mechanism, this text: > > For this query, the requester supplies only an IP address in the > DHCPLEASEQUERY message. The DHCP server will return any > information that it has on the most recent client to have been > assigned that IP address. > >sets off lots of alarm bells. If I read this right, *any information* associated >with that IP address is returned? If information used to construct a location >object is present (as in the geopriv dhcp-li draft), that would get returned? >That seems kind of excessive for an access concentrator, but very, very nice >for a black hat. This whole section on Parameter Request List options: > > 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. > >has no restrictions of any type on the return of any data. Why is all >of this data being made available via this method? I suppose because all of this data is already available on the wire (and sometimes broadcast) if you just watch it go by. Of course, you have to *be* on the wire to see it that way. What do the rest of you think about this issue? Cheers -- Kim >It's too bad that SNMP is off the table here, as that would give you a realistic >way to limit data to specific queries and queriers. > >Limiting the protocol to a very specific use that fits the >demonstrated need seems like it would make getting the security >mechanisms right easier; if this is meant to be truly general purpose, >it needs a general purpose mechanism that would give it the same level >of security as SNMP would for this same purpose. > > >_______________________________________________ >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 Apr 8 20:28: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 UAA15665; Thu, 8 Apr 2004 20:28:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjrv-0004QL-Nq; Thu, 08 Apr 2004 20:27:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjKJ-0008D8-UZ for dhcwg@optimus.ietf.org; Thu, 08 Apr 2004 19:52:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11413 for ; Thu, 8 Apr 2004 19:52:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjKH-00075u-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 19:52:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBiOL-0000G9-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 18:53:02 -0400 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 1BBgY0-0002WL-00 for dhcwg@ietf.org; Thu, 08 Apr 2004 16:54:52 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 08 Apr 2004 13:03:34 +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 i38KsJGF027866; Thu, 8 Apr 2004 13:54:19 -0700 (PDT) Received: from kkinnear-w2k03.cisco.com ([161.44.65.230]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHL96232; Thu, 8 Apr 2004 16:54:18 -0400 (EDT) Message-Id: <4.3.2.7.2.20040408165229.0283e8a8@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 Apr 2004 16:54:17 -0400 To: Ralph Droms , dhcwg@ietf.org From: Kim Kinnear Subject: Re: [dhcwg] Use of SNMP instead of leasequery Cc: kkinnear@cisco.com In-Reply-To: <4.3.2.7.2.20040406201645.02cc2b08@flask.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 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 08:20 PM 4/6/2004, Ralph Droms wrote: >Bert Wijnen: > >Discuss: >- what is the status of this solution vs DHCP MIB solution (I thought > they were competing solutions some time back). The working group felt that there was sufficient utility in this solution to pursue it. > The DHC MIB has also been submitted for PS, no? I know it is still in > MIB Doctor review... but it is a 2nd solution to same problem. I think we all saw the MIB as a solution to a moderately different problem, with different performance characteristics and different protocol interpreter requirements. Cheers -- Kim >- The reasonings for not using SNMP and MIB seem very weak to me > >Ted Hardie: > >Discuss: > >It's too bad that SNMP is off the table here, as that would give you a realistic >way to limit data to specific queries and queriers. > > >_______________________________________________ >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 Fri Apr 9 01:56: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 BAA29380; Fri, 9 Apr 2004 01:56:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBozg-0003Bk-UX; Fri, 09 Apr 2004 01:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBoz4-0003BI-0Z for dhcwg@optimus.ietf.org; Fri, 09 Apr 2004 01:55:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29364 for ; Fri, 9 Apr 2004 01:55:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBoyx-0003CD-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 01:55:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBow5-00030Q-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 01:52:20 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BBouT-0002l2-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 01:50:37 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HVW009542V6FD@mailout1.samsung.com> for dhcwg@ietf.org; Fri, 09 Apr 2004 14:49:54 +0900 (KST) Received: from ep_mmp1 (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 <0HVW0091X2UXDX@mailout1.samsung.com> for dhcwg@ietf.org; Fri, 09 Apr 2004 14:49:45 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HVW00HZQ2UWYZ@mmp1.samsung.com> for dhcwg@ietf.org; Fri, 09 Apr 2004 14:49:45 +0900 (KST) Date: Fri, 09 Apr 2004 14:50:05 +0900 From: "S. Daniel Park" Subject: RE: [dhcwg] Revised charter In-reply-to: <4.3.2.7.2.20040407085147.01f90c68@flask.cisco.com> To: "'Ralph Droms'" , dhcwg@ietf.org Cc: "'S. Daniel Park'" Message-id: <00cc01c41df6$822ffd80$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 Can we show a mobility issue in the DHC charter ? * The DHC WG will address mobility in DHCP Or out of scope of the DHC charter at this stage ? Regarding this issue, I am trying to propose a new draft as a starting point to discuss mobility support for the DHCP and it will be available in the middle of this month. 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: Wednesday, April 07, 2004 9:54 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Revised charter > > > Here is a draft charter for the WG, based on discussion at > the WG meeting in > Seoul and discussion on the mailing list. Please review and > respond with > comments. > > - Ralph > > dhc WG draft revised charter > ---------------------------- > > The dhc working group (DHC WG) has developed DHCP for automated > allocation, configuration and management of IP addresses and TCP/IP > protocol stack parameters. DHCPv4 is currently a "Draft Standard" and > is documented in RFC2131 and RFC2132. DHCPv6 is currently a "Proposed > Standard" and is documented in RFC3315. Subsequent RFCS document > additional options and other enhancements to the specifications. > > The DHC WG is responsible for reviewing (and sometimes developing) > DHCP options or other extensions (for both IPv4 and IPv6). The DHC WG > is expected to review all proposed extensions to DHCP to ensure that > they are consistent with the DHCP specification and other option > formats, that they do not duplicate existing mechanisms, etc. The DHC > WG will not (generally) be responsible for evaluating the semantic > content of proposed options. The DHC WG will not adopt new proposals > for extensions to DHCP as working group documents without first > coordinating with other relevant working groups and determining who > has the responsibility for reviewing the semantic content of an > option. > > The DHC WG has the following main objectives: > > * The DHC WG will address security in DHCP > > o Develop and document security requirements for DHCP. RFC 3118 > defines current security mechanisms for DHCPv4. > Unfortunately, RFC > 3118 has neither been implemented nor deployed to date. Specific > issues to be considered include: > > - Improved key management and scalability > > - Security for messages passed between relay agents and servers > > - Threats of DoS attacks through FORCERENEW > > - The increased usage of DHC on unsecured (e.g., wireless) and > public LANs > > - The need for clients to be able to authenticate > servers, without > simultaneously requiring client authentication by the server. > > o Develop and document a roadmap of any new documents or protocols > needed to meet the security requirements for DHCP > > * Write an analysis of the DHCP specification, including RFC2131, > RFC2132 and other RFCs defining additional options, which > identifies > ambiguities, contradictory specifications and other obstacles to > development of interoperable implementations. Recommend a process > for resolving identified problems and incorporating the resolutions > into the DHCP specification. > > * 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. > > * 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. > > > _______________________________________________ > 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 Fri Apr 9 08:29: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 IAA24905; Fri, 9 Apr 2004 08:29:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBv80-0006SO-MQ; Fri, 09 Apr 2004 08:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBv7M-0006MP-Sf for dhcwg@optimus.ietf.org; Fri, 09 Apr 2004 08:28:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24866 for ; Fri, 9 Apr 2004 08:28:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBv7L-0000Hq-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 08:28:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBv6K-0000Af-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 08:27:16 -0400 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 1BBv4l-0007gG-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 08:25:39 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 09 Apr 2004 04:34:25 +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 i39COx2Q023711; Fri, 9 Apr 2004 05:25:02 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-179.cisco.com [10.86.240.179]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHM28098; Fri, 9 Apr 2004 08:24:58 -0400 (EDT) Message-Id: <4.3.2.7.2.20040409082236.02ac7a50@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Apr 2004 08:24:55 -0400 To: "S. Daniel Park" From: Ralph Droms Subject: RE: [dhcwg] Revised charter Cc: dhcwg@ietf.org, "'S. Daniel Park'" In-Reply-To: <00cc01c41df6$822ffd80$67cadba8@LocalHost> References: <4.3.2.7.2.20040407085147.01f90c68@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: , Can you give us more details? What problems would we consider as part of mobility support in DHCP? - Ralph At 02:50 PM 4/9/2004 +0900, S. Daniel Park wrote: >Can we show a mobility issue in the DHC charter ? >* The DHC WG will address mobility in DHCP > >Or out of scope of the DHC charter at this stage ? > >Regarding this issue, I am trying to propose a >new draft as a starting point to discuss mobility >support for the DHCP and it will be available in the >middle of this month. > > >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: Wednesday, April 07, 2004 9:54 PM > > To: dhcwg@ietf.org > > Subject: [dhcwg] Revised charter > > > > > > Here is a draft charter for the WG, based on discussion at > > the WG meeting in > > Seoul and discussion on the mailing list. Please review and > > respond with > > comments. > > > > - Ralph > > > > dhc WG draft revised charter > > ---------------------------- > > > > The dhc working group (DHC WG) has developed DHCP for automated > > allocation, configuration and management of IP addresses and TCP/IP > > protocol stack parameters. DHCPv4 is currently a "Draft Standard" and > > is documented in RFC2131 and RFC2132. DHCPv6 is currently a "Proposed > > Standard" and is documented in RFC3315. Subsequent RFCS document > > additional options and other enhancements to the specifications. > > > > The DHC WG is responsible for reviewing (and sometimes developing) > > DHCP options or other extensions (for both IPv4 and IPv6). The DHC WG > > is expected to review all proposed extensions to DHCP to ensure that > > they are consistent with the DHCP specification and other option > > formats, that they do not duplicate existing mechanisms, etc. The DHC > > WG will not (generally) be responsible for evaluating the semantic > > content of proposed options. The DHC WG will not adopt new proposals > > for extensions to DHCP as working group documents without first > > coordinating with other relevant working groups and determining who > > has the responsibility for reviewing the semantic content of an > > option. > > > > The DHC WG has the following main objectives: > > > > * The DHC WG will address security in DHCP > > > > o Develop and document security requirements for DHCP. RFC 3118 > > defines current security mechanisms for DHCPv4. > > Unfortunately, RFC > > 3118 has neither been implemented nor deployed to date. Specific > > issues to be considered include: > > > > - Improved key management and scalability > > > > - Security for messages passed between relay agents and servers > > > > - Threats of DoS attacks through FORCERENEW > > > > - The increased usage of DHC on unsecured (e.g., wireless) and > > public LANs > > > > - The need for clients to be able to authenticate > > servers, without > > simultaneously requiring client authentication by the server. > > > > o Develop and document a roadmap of any new documents or protocols > > needed to meet the security requirements for DHCP > > > > * Write an analysis of the DHCP specification, including RFC2131, > > RFC2132 and other RFCs defining additional options, which > > identifies > > ambiguities, contradictory specifications and other obstacles to > > development of interoperable implementations. Recommend a process > > for resolving identified problems and incorporating the resolutions > > into the DHCP specification. > > > > * 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. > > > > * 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. > > > > > > _______________________________________________ > > 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 Fri Apr 9 08:35: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 IAA25162; Fri, 9 Apr 2004 08:35:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBvDp-0006vz-MG; Fri, 09 Apr 2004 08:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBvCy-0006s1-Is for dhcwg@optimus.ietf.org; Fri, 09 Apr 2004 08:34:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25098 for ; Fri, 9 Apr 2004 08:34:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBvCw-0000rT-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 08:34:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBvAt-0000br-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 08:31:59 -0400 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 1BBv8i-0000LL-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 08:29:44 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 09 Apr 2004 04:38:33 +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 i39CTA2O027095; Fri, 9 Apr 2004 05:29:10 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-179.cisco.com [10.86.240.179]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHM28282; Fri, 9 Apr 2004 08:29:08 -0400 (EDT) Message-Id: <4.3.2.7.2.20040409082507.01f59b00@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Apr 2004 08:29:05 -0400 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Ralph Droms Subject: Re: [dhcwg] Revised charter Cc: dhcwg@ietf.org In-Reply-To: References: <4.3.2.7.2.20040407085147.01f90c68@flask.cisco.com> <4.3.2.7.2.20040407085147.01f90c68@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: , Jinmei-san - thanks for catching the typo, and I will add a reference to the newly published RFC 3736. - Ralph At 11:08 AM 4/9/2004 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >>>>> On Wed, 07 Apr 2004 08:53:58 -0400, > >>>>> Ralph Droms said: > > > Here is a draft charter for the WG, based on discussion at the WG > meeting in > > Seoul and discussion on the mailing list. Please review and respond with > > comments. > >It basically looks good. A couple of minor comments: > > > Standard" and is documented in RFC3315. Subsequent RFCS document > > additional options and other enhancements to the specifications. > >s/RFCS/RFCs/ ? > > > * 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. > >We may want to add RFC3736 as a reference of "stateless DHCPv6". > > 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 Fri Apr 9 09:44: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 JAA27560; Fri, 9 Apr 2004 09:44:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBwIb-0005d5-FX; Fri, 09 Apr 2004 09:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBwHt-0005bL-LO for dhcwg@optimus.ietf.org; Fri, 09 Apr 2004 09:43:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27523 for ; Fri, 9 Apr 2004 09:43:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBwHq-0006XF-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 09:43:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBwGN-0006Sb-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 09:41:44 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BBwFj-0006Md-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 09:41:03 -0400 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 i39DeNKj013766; Fri, 9 Apr 2004 06:40:23 -0700 (PDT) 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 AHM32480; Fri, 9 Apr 2004 09:40:21 -0400 (EDT) Message-Id: <4.3.2.7.2.20040409093555.02ae0008@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Apr 2004 09:40:19 -0400 To: Pekka Savola From: Ralph Droms Subject: Re: [dhcwg] applicability of draft-ietf-dhc-dhcpv6-ctep-opt-01 Cc: Ted Lemon , dhcwg@ietf.org In-Reply-To: References: <99C4FAC6-869E-11D8-869D-000A95D9C74C@fugue.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: , It is not be necessary to touch the router in all cases... An IPv6 "home gateway" with a single upstream interface (to the service provider) and one or more downstream interfaces will operate in a sufficiently constrained environment so as to allow plug-and-play operation with only minimal configuration (such as a prefix delegated from the service provider). In this case, if the service provider makes IPv6 service available through a configured tunnel, the only other configuration required would be the address of the other endpoint of the tunnel. It would make sense to provide that endpoint address through DHCP along with the delegated prefix. Now, the dhc WG is debating whether or not to take on this option as a WG work item, because it applies to router configuration rather than host configuration. The use case is there - it's a matter of charter scope. - Ralph At 09:06 AM 4/5/2004 +0300, Pekka Savola wrote: >On Sun, 4 Apr 2004, Ted Lemon wrote: > > On Apr 2, 2004, at 7:44 AM, Pekka Savola wrote: > > > You're trading off having to > > > configure 90 tunnels in 10 border routers to having to configure 90 > > > tunnels in 10 DHCPv6 servers. > > > > > > IMHO, in this kind of set-up, Using DHCPv6 just doesn't seem to make > > > sense. > > > > Possibly it's easier to configure a DHCP server on a central server > > somewhere with all this information rather than configuring the router, > > because if the router dies then you have to remember to reconfigure it. > > > > But basically, I don't know. :') > >You'll have to reconfigure the router in any case to get the other >connectivity working ;-). > >Here, you don't get aggregation benefits as you have to configure >exactly the same information in 10 DHCPv6 servers as you'd have to do >in 10 routers. If you would only need to configure 1 DHCPv6 server to >get the config to all the routers, some folks might think this gives >additional benefits. > >-- >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 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Apr 9 10:23: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 KAA29993; Fri, 9 Apr 2004 10:23:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBwuL-0006vN-Cd; Fri, 09 Apr 2004 10:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBwVV-0006iE-O4 for dhcwg@optimus.ietf.org; Fri, 09 Apr 2004 09:57:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28032 for ; Fri, 9 Apr 2004 09:57:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBwVT-00002j-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 09:57:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBwTm-0007hS-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 09:55:35 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBwSd-0007Vq-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 09:54:23 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i39DrbM20279; Fri, 9 Apr 2004 16:53:37 +0300 Date: Fri, 9 Apr 2004 16:53:37 +0300 (EEST) From: Pekka Savola To: Ralph Droms cc: Ted Lemon , Subject: Re: [dhcwg] applicability of draft-ietf-dhc-dhcpv6-ctep-opt-01 In-Reply-To: <4.3.2.7.2.20040409093555.02ae0008@flask.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=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 Fri, 9 Apr 2004, Ralph Droms wrote: > An IPv6 "home gateway" with a single upstream interface (to > the service provider) and one or more downstream interfaces > will operate in a sufficiently constrained environment so > as to allow plug-and-play operation with only minimal > configuration (such as a prefix delegated from the service > provider). In this case, if the service provider makes IPv6 > service available through a configured tunnel, the only other > configuration required would be the address of the other > endpoint of the tunnel. It would make sense to provide > that endpoint address through DHCP along with the delegated > prefix. To be able to run DHCP*v6* between the CPE and the ISP, there has to be IPv6 connectivity. If there is no v6 connectivity, you cannot use DHCPv6. If there _is_ v6 connectivity, you do not need a configured tunnel, because you already have v6 connectivity. Am I missing something? (Or are you visualizing the scenario where there would be IPv6 link-local connectivity, but for global connectivity, you would have to use a tunnel? If so, could you describe a specific scenario as I fail to see where this would apply to?) -- 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 Fri Apr 9 10:25: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 KAA00060; Fri, 9 Apr 2004 10:25:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBwwI-0007Ai-1V; Fri, 09 Apr 2004 10:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBwvk-00079Z-QD for dhcwg@optimus.ietf.org; Fri, 09 Apr 2004 10:24:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00034 for ; Fri, 9 Apr 2004 10:24:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBwvh-000296-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 10:24:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBwuh-00024k-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 10:23:24 -0400 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 1BBwts-0001xv-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 10:22:32 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 09 Apr 2004 06:30:10 +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 i39ELvGF013666; Fri, 9 Apr 2004 07:21:58 -0700 (PDT) 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 AHM35565; Fri, 9 Apr 2004 10:21:56 -0400 (EDT) Message-Id: <4.3.2.7.2.20040409100329.02acd940@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Apr 2004 10:21:53 -0400 To: Pekka Savola From: Ralph Droms Subject: Re: [dhcwg] applicability of draft-ietf-dhc-dhcpv6-ctep-opt-01 Cc: In-Reply-To: References: <4.3.2.7.2.20040409093555.02ae0008@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: , Looks like I was missing something. I confused draft-ietf-dhc-dhcpv6-ctep-opt-01 with draft-daniel-dhc-ipv6in4-opt-02. I think my confusion arose because of the context of the conversation. I had understood draft-ietf-dhc-dhcpv6-ctep-opt-01 to be intended to inform a host of a tunnel endpoint (which I think would normally be accomplished through routing protocols) and draft-daniel-dhc-ipv6in4-opt-02 to talk about configuring isolated routers with the endpoint of a tunnel. My apologies for thoroughly confusing the conversation... So, let's leave draft-daniel-dhc-ipv6in4-opt-02 out of this discussion for the moment. Back to the scenario you asked about...I can imagine (if you'll give me a moment of suspension-of-disbelief) that an ISP might want to provide IPv6/linklocal service between the service provider's edge router and the customer routers, without going to full IPv6 connectivity in its core. In that scenario, the customer router could use DHCPv6 to obtain a prefix and a tunnel endpoint from a server in the service provider's edge router, while needing the tunnel for full external IPv6 connectivity. But that does seem like a far-fetched scenario... - Ralph At 04:53 PM 4/9/2004 +0300, Pekka Savola wrote: >On Fri, 9 Apr 2004, Ralph Droms wrote: > > An IPv6 "home gateway" with a single upstream interface (to > > the service provider) and one or more downstream interfaces > > will operate in a sufficiently constrained environment so > > as to allow plug-and-play operation with only minimal > > configuration (such as a prefix delegated from the service > > provider). In this case, if the service provider makes IPv6 > > service available through a configured tunnel, the only other > > configuration required would be the address of the other > > endpoint of the tunnel. It would make sense to provide > > that endpoint address through DHCP along with the delegated > > prefix. > >To be able to run DHCP*v6* between the CPE and the ISP, there has to >be IPv6 connectivity. If there is no v6 connectivity, you cannot use >DHCPv6. If there _is_ v6 connectivity, you do not need a configured >tunnel, because you already have v6 connectivity. > >Am I missing something? > >(Or are you visualizing the scenario where there would be IPv6 >link-local connectivity, but for global connectivity, you would have >to use a tunnel? If so, could you describe a specific scenario as I >fail to see where this would apply to?) > >-- >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 pqm_press@hotmail.com Fri Apr 9 11:00:10 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 LAA01917 for ; Fri, 9 Apr 2004 11:00:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBxUJ-0005Hy-00 for dhc-archive@ietf.org; Fri, 09 Apr 2004 11:00:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBxTB-0005B5-00 for dhc-archive@ietf.org; Fri, 09 Apr 2004 10:59:02 -0400 Received: from dpvc-68-161-240-106.ny325.east.verizon.net ([68.161.240.106] helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1BBxRp-000502-00; Fri, 09 Apr 2004 10:57:38 -0400 From: "Atualidade Brasileira . xfg" To: ccamp-archive@ietf.org Subject: Livre-comércio: divisor de águas at.: pxy 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.1106 MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Fri, 09 Apr 2004 10:57:38 -0400 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=13.9 required=5.0 tests=AWL,FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,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_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.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 * 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 * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * -0.0 AWL AWL: Auto-whitelist adjustment

(ref.:tcc) ConstruNews deseja uma Feliz Páscoa a todos os seus amigos e suas respectivas famílias!

Lindenberg:EnEspañol - Lindenberg:InEnglish(LinkToFreeTranslator)

Série Temas Patrulhados (5)

"Livre-comércio, divisor de águas entre os favoráveis e os contrários à liberdade econômica"

No atual governo brasileiro, o componente ideológico que impregna setores do Itamaraty, regredindo ao terceiro-mundismo dos anos 70, os leva a admitir acordos comerciais com qualquer país, especialmente, os do "sul", mas não com os Estados Unidos, uma atitude irrealista e míope de nossa diplomacia, afirma Adolpho Lindenberg em recente artigo

* Adolpho Lindenberg é autor do livro "Os católicos e a economia de mercado", em que denuncia uma política com viés esquerdista que censura, marginaliza ou encobre com um manto de silêncio, opiniões "politicamente incorretas", não afinados com as assim denominadas "causas sociais" inspiradas na teologia da libertação e nos Fóruns Sociais. Assim, os meios de comunicação, e a própria sociedade brasileira, estão sendo "patrulhados".

* Em seu recente artigo "A economia de mercado e o livre-comércio", da Série Temas Patrulhados, o autor lamenta que a economia de mercado e o livre-comércio continuem sendo o alvo predileto da dialética intervencionista e progressista. Os argumentos usados se repetem como certas melodias dos clássicos realejos de antigamente, comenta Lindenberg, que em seu artigo enumera uma série dessas diatribes, das quais citamos aqui:

- Livres de quaisquer tabelamento ou fiscalização de "órgãos competentes", os preços subiriam assustadoramente, empobrecendo os consumidores, deixando-os indefesos diante da ganância dos industriais, fazendeiros, comerciantes, etc.

- A ganância dos industriais e o esmagamento das pequenas empresas incapazes de competir contra os gigantes empresariais, só sofreriam limites se o Estado intervier no mercado, via controle de preços, estatização das empresas de serviços públicos, subsídios e barreiras alfandegárias.

- O livre-comércio seria a porta de entrada dos produtos das multinacionais em nosso país com o intuito de nos explorar e nos submeter ao imperialismo norte-americano.

* A estas e outras diatribes analisadas e refutadas no artigo, se soma, no atual governo brasileiro, o componente ideológico que passou a impregnar setores do Itamaraty, parecendo ter regredido ao terceiro-mundismo dos anos 70, dispostos a admitir acordos comerciais com qualquer país, especialmente, os do "sul", mas não com os Estados Unidos. Atitude de nossa diplomacia que tem sido qualificada de "irrealista" por analistas políticos e criticada enfaticamente.

* A única correção possível para essa miopia consiste numa boa compreensão do que seja uma concorrência sadia e de como a competitividade entre os produtores constitui o instrumento natural para manter os preços dos produtos pouco acima de seu preço de custo, explica Lindenberg.

* O mercado é uma realidade funcional que oferece condições para produtores e consumidores, vendedores e compradores entrarem em contato entre si, com vistas a conhecer, avaliar e comparar os bens oferecidos e eventualmente chegar a acordos sobre preços. Tais combinações são obtidas mediante o livre jogo da oferta e da procura.

* Todos quantos consideram preferível a determinação dos preços por via governamental - evitando destarte os "desmandos da lei da oferta e da procura" - por mais bem-intencionados que possam ser (requisito não muito comum em nossos dias...), por melhores que sejam os programas de seus computadores, nunca conseguirão combinar as centenas de fatores que condicionam os preços de um modo tão perfeito, vivo e atualizado, como aqueles que emergem das práticas mercadológicas.

* A aceitação ou recusa do livre-comércio e suas conseqüências naturais, é o divisor de águas entre as mentalidades favoráveis e as contrárias à liberdade econômica, conclui Lindenberg, cujo artigo oferecemos gratuitamente.

Link gratuito:

* Para receber gratuitamente, por e-mail, o texto completo deste artigo, clique em: Lindenberg:EsteArtigoCompletoGratuitamente(No.5)

Outros links gratuitos (e-Book e outros artigos):

Lindenberg:e-BookGratuitoBr (em formato Word, com 11 artigos de Lindenberg)

Lindenberg:IntroduçãoGratuitaDoLivro (em formato Word, Introdução do livro "Os católicos e a economia de mercado")

Lindenberg:ArtigosAnteriores

Lindenberg:ProximosArtigos

 Links de opinião

Gostariamos muito de receber seu seu voto eletrônico sobre a temática abordada neste e-mail e, se possível, conhecer sua valiosa opinião:

Lindenberg:Concordo - Lindenberg:Discrepo - Lindenberg:MinhaOpinião

Outros links

Lindenberg:DesejoAdquirirLivro (receberá instruções sobre como poder adquirir o livro no Brasil)

Remover (para ser retirado imediatamente de nosso Address Book).

A difusão desta mensagem, com uma finalidade cultural e com o intuito de promover um debate construtivo e respeitoso de idéias, é de exclusiva responsabilidade da ConstruNews. Telefone de contato: (11) 9252 - 7873

 

 From dhcwg-admin@ietf.org Fri Apr 9 11:59: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 LAA03847; Fri, 9 Apr 2004 11:59:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BByPF-0007mi-6h; Fri, 09 Apr 2004 11:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBxP2-0001C3-H5 for dhcwg@optimus.ietf.org; Fri, 09 Apr 2004 10:54:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01488 for ; Fri, 9 Apr 2004 10:54:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBxOz-0004kJ-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 10:54:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBxMl-0004bZ-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 10:52:23 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBxMC-0004Th-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 10:51:48 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i39Ep3H21107; Fri, 9 Apr 2004 17:51:03 +0300 Date: Fri, 9 Apr 2004 17:51:03 +0300 (EEST) From: Pekka Savola To: Ralph Droms cc: dhcwg@ietf.org Subject: Re: [dhcwg] applicability of draft-ietf-dhc-dhcpv6-ctep-opt-01 In-Reply-To: <4.3.2.7.2.20040409100329.02acd940@flask.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=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 Fri, 9 Apr 2004, Ralph Droms wrote: > My apologies for thoroughly confusing the conversation... No problem :) > So, let's leave draft-daniel-dhc-ipv6in4-opt-02 out of this discussion for > the moment. Back to the scenario you asked about...I can imagine (if you'll > give me a moment of suspension-of-disbelief) that an ISP might want to > provide IPv6/linklocal service between the service provider's edge router > and the customer routers, without going to full IPv6 connectivity in its > core. In that scenario, the customer router could use DHCPv6 to obtain a > prefix and a tunnel endpoint from a server in the service provider's edge > router, while needing the tunnel for full external IPv6 connectivity. > > But that does seem like a far-fetched scenario... Yes, it's very far-fetched, because in this specific scenario: 1) the access network is usually the most difficult part to get native v6, and 2) it's much simpler for all the concerned parties for the ISP to use internal tunneling to bridge the gaps in its core network. Whether these tunnels are manually configured, set up automatically using 6PE ("BGP-tunneling") between the border boxes, etc. makes little difference. It's very simple to provide v6 support across v4 core if your edge device supports v6 already. So, as stated -- I'm having a lot of trouble figuring out the real applicability of this option, and I don't think we should go forward with it. The danger is that it's more confusing than it's worth... -- 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 Fri Apr 9 12:12: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 MAA04663; Fri, 9 Apr 2004 12:12:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBybp-0003s3-Am; Fri, 09 Apr 2004 12:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBybL-0003rO-Os for dhcwg@optimus.ietf.org; Fri, 09 Apr 2004 12:11:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04538 for ; Fri, 9 Apr 2004 12:11:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBybK-0003xn-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 12:11:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BByZI-0003cW-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 12:09:27 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BByXy-0003Np-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 12:08:02 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 09 Apr 2004 09:17:53 -0700 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 i39G7NCC007346; Fri, 9 Apr 2004 12:07:23 -0400 (EDT) Received: from volzw2k (sjc-vpn4-400.cisco.com [10.21.81.144]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHM44488; Fri, 9 Apr 2004 12:07:21 -0400 (EDT) From: "Bernie Volz" To: , "'Dhcwg'" Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-3315id-for-v4-02.txt + LAST CALL Comments Date: Fri, 9 Apr 2004 12:07:20 -0400 Organization: Cisco Message-ID: <002c01c41e4c$bd8d0520$6401a8c0@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.1 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'd prefer this work to be incorporated into a revision >of RFC2132, rather than creating a new RFC that will >probably be obsoleted shortly after publication, which also >gives us the opportunity to more fully consider the ramifications >of altering the semantics of the client identifier in the context >of DHCP-DNS dynamic updates. I would be against this because it will take significantly longer (revising 2131/2132 will take a while to get through the IETF process). - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Richard Barr Hibbs Sent: Tuesday, April 06, 2004 1:07 PM To: 'Dhcwg' Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-3315id-for-v4-02.txt + LAST CALL Comments > -----Original Message----- > From: Bernie Volz [mailto:volz@cisco.com] > Sent: Tuesday, 06 April 2004 06:40 > > I don't think a new option is such a good idea. > If a new option is used, how does a client know > when to send it or the 'old' client identifier > option? This forces 'new' clients to send both - > at least in the DISCOVER (older servers would > not echo back the new option in the OFFER > and new servers would could send back just the > new option). This goes against your proposed > text for 4.1, "but MUST NOT send both." > ...although I believe that when you significantly change both the syntax and semantics of an existing option it should be recast as a new option, I'll relent on that point... I also seem to have failed the transition test by requiring divine knowledge on the part of clients... oops.... > I'm also not completely happy with encoding the > IAID and DUID in a single option. > > The main reason I don't like this is that it > forces the server to do something that we don't > really want it to do - pull apart the data in > the client identifier option - the option data is > no longer 'opaque'. Note that it will be > important for the DHCP server to do this for: > 1. Dynamic DNS updates since the client > identifier is only the DUID portion (see section > 3.3 of draft-ietf-dnsext-dhcid-rr-07.txt). > 2. Client based policies (ie, reservations) or > limits, since these will want to look just at the > DUID portion. > I strongly believe that the client identifier should remain opaque to the server because to change the semantics is a significant change to the operation of existing servers. > But, there is an advantage to encoding the IAID > and DUID in the option as it supports current > DHCP server implementations. Without this, a > client that has multiple interfaces (either > connected to the same link or not) that are > serviced by a single DHCP server might not get > multiple addresses. > > I guess given the lesser of the two evils, I'm > inclined to go along with the option as you've > proposed it in the draft. > > So, I support this document moving forward. > ...I'd prefer this work to be incorporated into a revision of RFC2132, rather than creating a new RFC that will probably be obsoleted shortly after publication, which also gives us the opportunity to more fully consider the ramifications of altering the semantics of the client identifier in the context of DHCP-DNS dynamic updates. --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 Fri Apr 9 12:18: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 MAA05208; Fri, 9 Apr 2004 12:18:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BByhd-0004WC-Cy; Fri, 09 Apr 2004 12:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBygi-0004NZ-V4 for dhcwg@optimus.ietf.org; Fri, 09 Apr 2004 12:17:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05155 for ; Fri, 9 Apr 2004 12:17:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBygg-0004VY-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 12:17:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBydZ-0004D9-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 12:13:50 -0400 Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com) by ietf-mx with esmtp (Exim 4.12) id 1BByaX-0003hY-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 12:10:41 -0400 Received: from conversion-daemon.endeavor.poss.com by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <0HVW00601V5PQF@endeavor.poss.com> for dhcwg@ietf.org; Fri, 09 Apr 2004 12:10:01 -0400 (EDT) Received: from kan1 (user236.net1137.oh.sprint-hsd.net [69.68.46.236]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HVW00E21VKNN1@endeavor.poss.com>; Fri, 09 Apr 2004 12:10:00 -0400 (EDT) Date: Fri, 09 Apr 2004 12:11:42 -0400 From: "Kevin A. Noll" Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-reclassify-options-00 In-reply-to: <4.3.2.7.2.20040403074305.029b19b0@flask.cisco.com> To: Ralph Droms , dhcwg@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) 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=SUBJ_HAS_UNIQ_ID 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 support moving this ahead. --kan-- > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Ralph Droms > Sent: Monday, 05 April, 2004 8:46 AM > To: dhcwg@ietf.org > Subject: [dhcwg] dhc WG last call on > draft-ietf-dhc-reclassify-options-00 > > > This message announces a WG last call on "Reclassifying DHCPv4 Options" > . The last call will > conclude at 5PM > EST on 4/16/04. > > Please respond to this WG last call. If you support acceptance of the > document without change, respond with a simple acknowledgment, so that > support for the document can be assessed. > > draft-ietf-dhc-reclassify-options-00 revises RFC 2132 to reclassify DHCPv4 > option codes 128 to 223 (decimal) as publicly defined options to > be managed > by IANA in accordance with RFC 2939. This document directs IANA to make > these option codes available for assignment as publicly defined > DHCP options > for future options.. This draft is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-reclassify-opti > ons-00.txt > > - Ralph Droms > > > _______________________________________________ > 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 Fri Apr 9 12:18: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 MAA05210; Fri, 9 Apr 2004 12:18:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BByhd-0004We-RK; Fri, 09 Apr 2004 12:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BByhL-0004Vt-7u for dhcwg@optimus.ietf.org; Fri, 09 Apr 2004 12:17:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05176 for ; Fri, 9 Apr 2004 12:17:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BByhJ-0004dT-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 12:17:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BByeY-0004HA-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 12:14:51 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BByb0-0003nO-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 12:11:10 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 09 Apr 2004 09:06:54 -0700 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 i39GAYcp005998; Fri, 9 Apr 2004 12:10:34 -0400 (EDT) Received: from volzw2k (sjc-vpn4-400.cisco.com [10.21.81.144]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHM44778; Fri, 9 Apr 2004 12:10:32 -0400 (EDT) From: "Bernie Volz" To: "'Kim Kinnear'" , "'Ralph Droms'" , Subject: RE: [dhcwg] Security for leasequery messages Date: Fri, 9 Apr 2004 12:10:32 -0400 Organization: Cisco Message-ID: <002d01c41e4d$2fab5850$6401a8c0@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.20040407163537.02686008@goblet.cisco.com> 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.1 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 Seems like a good approach ... But will the IESG be happy with it? Today, there's always the basic security of only allowing the requests from specific addresses (and since it is the reply that has the interesting information, spoofing the sender doesn't buy you that much). - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Kim Kinnear Sent: Wednesday, April 07, 2004 4:38 PM To: Ralph Droms; dhcwg@ietf.org Cc: kkinnear@cisco.com Subject: Re: [dhcwg] Security for leasequery messages Folks, This is clearly an issue, and there are no easy answers. Here is one approach: Nothing is mandatory to implement, since one approach is to ensure that there is physical security between the access concentrator and the DHCP server. A better approach is to use some form of the not-yet-fully-baked relay agent authentication. For example: http://www.ietf.org/internet-drafts/draft-ietf-dhc-auth-suboption-03.txt but since this is still coming along, it can't be mandatory, that's for sure. We could wait to standardize leasequery until something was approved for relay agent authentication, but that will further delay something that has already undergone numerous delays. There are large number of similar-to-the-standard leasequery installations, and more every day. It would be nice to bring them all into compliance over time, and time is getting away from us. One approach would be to make something mandatory once that something exists, which is a little odd but perhaps doable. We might be able to say: "When some form of relay-agent to DHCP server authentication becomes a standard, its use for leasequery becomes mandatory." Something to consider. Any other ideas for handle this one? Cheers -- Kim At 07:56 PM 4/6/2004, Ralph Droms wrote: >The following issues relate to security for leasequery messages: > >Steve Bellovin: > >Discuss: >(26 March 2004) >The Security Considerations section says this: > > DHCP servers SHOULD prevent exposure of location information > (particularly the mapping of hardware address to IP address lease, > which can be an invasion of broadband subscriber privacy) by > employing some form of relay agent authentication between the > DHCPLEASEQUERY client and the DHCP server. > > Clients of the DHCPLEASEQUERY message SHOULD ensure that their data > path to the DHCP server is secure. Clients SHOULD use Relay Agent > Information security as a way to achieve this goal. > >What is "some form of ... authentication"? What is "Relay Agent >Information security"? Put another way, what is mandatory to >implement? > >Russ Housley: > >Discuss: > Section 7 says: > > > > DHCP servers SHOULD prevent exposure of location information > > (particularly the mapping of hardware address to IP address lease, > > which can be an invasion of broadband subscriber privacy) by > > employing some form of relay agent authentication between the > > DHCPLEASEQUERY client and the DHCP server. > > > There needs to be more discussion of the authentication requirements. > I would prefer the specification to name a mandatory-to-implement > mechanism, but that may be asking too much. > > Section 7 also says: > > > > Clients of the DHCPLEASEQUERY message SHOULD ensure that their data > > path to the DHCP server is secure. > > What security services are needed? Integrity, authentication, access > control, replay protection confidentiality? The hint about Relay Agent > Information security, with no reference, is not sufficient. > > > >_______________________________________________ >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 Fri Apr 9 12:34: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 MAA06367; Fri, 9 Apr 2004 12:34:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BByx6-00079t-S6; Fri, 09 Apr 2004 12:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BByoE-0005Xa-0O for dhcwg@optimus.ietf.org; Fri, 09 Apr 2004 12:24:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05643 for ; Fri, 9 Apr 2004 12:24:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BByoA-0005Mj-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 12:24:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBylY-000516-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 12:22:04 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BByhh-0004bV-00; Fri, 09 Apr 2004 12:18:05 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i39GHK120536; Fri, 9 Apr 2004 11:17:21 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <1690H8XB>; Fri, 9 Apr 2004 17:31:47 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503FD6B69@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Bernie Volz , dhcwg@ietf.org, iesg@ietf.org Subject: RE: [dhcwg] Should the leasequery spec explicitly be IPv4-specifi c? Date: Fri, 9 Apr 2004 17:31:46 +0200 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 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: , Fine by me. SO let us add a few lines that states this ecplicitly in the document. The v6Ops WG just wnet through all RFCs to list which ones are IPv6 hostile/unfriendly. So if we approve any new documents that are specific for IPv4 only, let us then add a few words that say so and explain why, so that this is clear in the future. Thanks, Bert > -----Original Message----- > From: Bernie Volz [mailto:volz@cisco.com] > Sent: donderdag 8 april 2004 22:04 > To: dhcwg@ietf.org; iesg@ietf.org > Subject: RE: [dhcwg] Should the leasequery spec explicitly be > IPv4-specific? > > > YES! > > As this specification deals with DHCPv4 (is extends DHCPv4), it should > be IPv4 specific. > > It is a separate issue as to whether corresponding > functionality will be > needed for DHCPv6 and something that the WG should take up. > > - Bernie > > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of > Ralph Droms > Sent: Tuesday, April 06, 2004 8:25 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Should the leasequery spec explicitly be > IPv4-specific? > > > Bert Wijnen: > > Discuss: > - It seems to be implicitly IPv4 specific without > explaining/justifying > why > and uses "IP address" to mean IPv4 addresses only. Do we not want > them > to either be IPv4/v6 agnostic or to be specific in stating > that they > are IPv4 only if such is the case and justified? > > > _______________________________________________ > 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 Fri Apr 9 12:37: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 MAA06517; Fri, 9 Apr 2004 12:37:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBz01-0007d8-2j; Fri, 09 Apr 2004 12:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BByzS-0007Ym-Bt for dhcwg@optimus.ietf.org; Fri, 09 Apr 2004 12:36:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06487 for ; Fri, 9 Apr 2004 12:36:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BByzQ-0006a9-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 12:36:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBywi-0006G9-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 12:33:36 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BByt9-0005qU-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 12:29:55 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 09 Apr 2004 09:25:42 -0700 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 i39GTLcp009259; Fri, 9 Apr 2004 12:29:21 -0400 (EDT) Received: from volzw2k (sjc-vpn4-400.cisco.com [10.21.81.144]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHM46246; Fri, 9 Apr 2004 12:29:19 -0400 (EDT) From: "Bernie Volz" To: "'Kim Kinnear'" , "'Ralph Droms'" , Subject: RE: [dhcwg] Restrictions of information flow in leasequery messages Date: Fri, 9 Apr 2004 12:29:18 -0400 Organization: Cisco Message-ID: <002e01c41e4f$cf1de8b0$6401a8c0@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.20040408164627.0283bf48@goblet.cisco.com> 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=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 Kim: I agree with you - this information is generally available. Perhaps a solution is that a server always has the option of not returning data it considers too sensitive - such as GEOPRIV information. Perhaps something like the following should be added to the Security Considerations: In some environments it may be appropriate to configure a DHCP server with option numbers that MUST not be returned in response to DHCPLEASEQUERY messages because these options are considered to contain sensitive information. I do think that once security options exists for relay to server communication, if this was a concern at a site, the site should use those options (and restrict who the server responds to for a DHCPLEASEQUERY). - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Kim Kinnear Sent: Thursday, April 08, 2004 4:52 PM To: Ralph Droms; dhcwg@ietf.org Cc: kkinnear@cisco.com Subject: Re: [dhcwg] Restrictions of information flow in leasequery messages At 08:16 PM 4/6/2004, Ralph Droms wrote: >Ted Hardie: > >Discuss: >This whole method has "invitation to mischief" printed in large, block >letters across its shirt. After being told repeatedly that there is no >restriction on the use cases for this mechanism, this text: > > For this query, the requester supplies only an IP address in the > DHCPLEASEQUERY message. The DHCP server will return any > information that it has on the most recent client to have been > assigned that IP address. > >sets off lots of alarm bells. If I read this right, *any information* >associated with that IP address is returned? If information used to >construct a location object is present (as in the geopriv dhcp-li >draft), that would get returned? That seems kind of excessive for an >access concentrator, but very, very nice for a black hat. This whole >section on Parameter Request List options: > > 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. > >has no restrictions of any type on the return of any data. Why is all >of this data being made available via this method? I suppose because all of this data is already available on the wire (and sometimes broadcast) if you just watch it go by. Of course, you have to *be* on the wire to see it that way. What do the rest of you think about this issue? Cheers -- Kim >It's too bad that SNMP is off the table here, as that would give you a >realistic way to limit data to specific queries and queriers. > >Limiting the protocol to a very specific use that fits the demonstrated >need seems like it would make getting the security mechanisms right >easier; if this is meant to be truly general purpose, it needs a >general purpose mechanism that would give it the same level of security >as SNMP would for this same purpose. > > >_______________________________________________ >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 Fri Apr 9 12:45: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 MAA07209; Fri, 9 Apr 2004 12:45:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBz7l-0008Ti-Iq; Fri, 09 Apr 2004 12:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBz7X-0008Sw-Rw for dhcwg@optimus.ietf.org; Fri, 09 Apr 2004 12:44:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07143 for ; Fri, 9 Apr 2004 12:44:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBz7V-0007Xr-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 12:44:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBz53-0007EN-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 12:42:13 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BBz2J-0006rw-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 12:39:23 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 09 Apr 2004 09:49:20 -0700 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 i39GcnCC014718; Fri, 9 Apr 2004 12:38:49 -0400 (EDT) Received: from volzw2k (sjc-vpn4-400.cisco.com [10.21.81.144]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHM46945; Fri, 9 Apr 2004 12:38:47 -0400 (EDT) From: "Bernie Volz" To: "'Pekka Savola'" , "'Ralph Droms'" Cc: Subject: RE: [dhcwg] applicability of draft-ietf-dhc-dhcpv6-ctep-opt-01 Date: Fri, 9 Apr 2004 12:38:47 -0400 Organization: Cisco Message-ID: <002f01c41e51$21e422c0$6401a8c0@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=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 guess the solution is to ask the authors to add specific examples of the environments in which this option will be used, if they still feel this option is needed. -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Pekka Savola Sent: Friday, April 09, 2004 10:51 AM To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] applicability of draft-ietf-dhc-dhcpv6-ctep-opt-01 On Fri, 9 Apr 2004, Ralph Droms wrote: > My apologies for thoroughly confusing the conversation... No problem :) > So, let's leave draft-daniel-dhc-ipv6in4-opt-02 out of this discussion > for the moment. Back to the scenario you asked about...I can imagine > (if you'll give me a moment of suspension-of-disbelief) that an ISP > might want to provide IPv6/linklocal service between the service > provider's edge router and the customer routers, without going to full > IPv6 connectivity in its core. In that scenario, the customer router > could use DHCPv6 to obtain a prefix and a tunnel endpoint from a > server in the service provider's edge router, while needing the tunnel > for full external IPv6 connectivity. > > But that does seem like a far-fetched scenario... Yes, it's very far-fetched, because in this specific scenario: 1) the access network is usually the most difficult part to get native v6, and 2) it's much simpler for all the concerned parties for the ISP to use internal tunneling to bridge the gaps in its core network. Whether these tunnels are manually configured, set up automatically using 6PE ("BGP-tunneling") between the border boxes, etc. makes little difference. It's very simple to provide v6 support across v4 core if your edge device supports v6 already. So, as stated -- I'm having a lot of trouble figuring out the real applicability of this option, and I don't think we should go forward with it. The danger is that it's more confusing than it's worth... -- 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 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Apr 9 13:00: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 NAA08120; Fri, 9 Apr 2004 13:00:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBzMG-0001MF-I9; Fri, 09 Apr 2004 13:00:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBzLP-00016j-Fh for dhcwg@optimus.ietf.org; Fri, 09 Apr 2004 12:59:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08014 for ; Fri, 9 Apr 2004 12:59:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBzLN-0001QG-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 12:59:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBzKF-0001I2-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 12:57:56 -0400 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 1BBzJ0-00014Z-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 12:56:38 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 09 Apr 2004 09:05:23 +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 i39GtqKj001804; Fri, 9 Apr 2004 09:55:53 -0700 (PDT) Received: from volzw2k (sjc-vpn4-400.cisco.com [10.21.81.144]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHM48103; Fri, 9 Apr 2004 12:55:50 -0400 (EDT) From: "Bernie Volz" To: "'Ralph Droms'" , Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-reclassify-options-00 Date: Fri, 9 Apr 2004 12:55:49 -0400 Organization: Cisco Message-ID: <003001c41e53$835c7550$6401a8c0@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.20040408083106.02ade250@flask.cisco.com> 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.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID 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: Thanks for the comments and I've got the updated version ready to go - but will wait for additional comments during the WG Last Call. Reminder to WG: this document and several others are in last call which ends 5PM EST on 4/16/04. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ralph Droms Sent: Thursday, April 08, 2004 8:38 AM To: dhcwg@ietf.org Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-reclassify-options-00 This document reflects WG consensus on how to make more DHCP option codes available to avoid exhaustion of the option code space. Although there are known uses of option codes in the range 128-254 (both documented and undocumented), the procedure described in this document provides a way to avoid clashes in the use of reclassified options. Editorial suggestions and comments: The references should be listed as Normative and Informative. Section 3, change the first sentence to: "The DHCP option space (0-255) is divided into two ranges [RFC2132]:" Reference [unused-optioncodes] has been published as RFC 3679. The document should include boilerplate from RFC 3667 when it is revised. _______________________________________________ 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 Fri Apr 9 13:37: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 NAA09232; Fri, 9 Apr 2004 13:37:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBzw5-0006bg-Tv; Fri, 09 Apr 2004 13:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBzvu-0006aP-MG for dhcwg@optimus.ietf.org; Fri, 09 Apr 2004 13:36:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09220 for ; Fri, 9 Apr 2004 13:36:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBzvr-0005C1-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 13:36:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBzu4-00051t-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 13:34:57 -0400 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 1BBztQ-0004uI-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 13:34:16 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 09 Apr 2004 09:41:49 +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 i39HXYKj008860; Fri, 9 Apr 2004 10:33:34 -0700 (PDT) Received: from volzw2k (sjc-vpn4-400.cisco.com [10.21.81.144]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHM51354; Fri, 9 Apr 2004 13:33:32 -0400 (EDT) From: "Bernie Volz" To: "'Ralph Droms'" , Subject: RE: [dhcwg] Revised charter Date: Fri, 9 Apr 2004 13:33:31 -0400 Organization: Cisco Message-ID: <003101c41e58$c7b4d990$6401a8c0@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.20040407085147.01f90c68@flask.cisco.com> 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=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 Ralph: The draft charter great! One minor issue - you might want to make the list elements consistent. Some start out with an action, others give a description first and then the actions. To scan the list quickly, it might be nice if they all started with actions. But, this is very minor and completely your choice. - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Apr 9 13: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 NAA09273; Fri, 9 Apr 2004 13:38:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBzx2-00076W-L6; Fri, 09 Apr 2004 13:38:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBzwv-00074M-Cy for dhcwg@optimus.ietf.org; Fri, 09 Apr 2004 13:37:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09266 for ; Fri, 9 Apr 2004 13:37:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBzwq-0005Ib-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 13:37:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBzw1-0005Cn-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 13:36:58 -0400 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 1BBzv8-000568-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 13:36:02 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 09 Apr 2004 09:43: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 i39HZRGF017575; Fri, 9 Apr 2004 10:35:27 -0700 (PDT) Received: from cisco.com ([161.44.65.140]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHM51528; Fri, 9 Apr 2004 13:35:26 -0400 (EDT) Message-ID: <4076DEDF.8020004@cisco.com> Date: Fri, 09 Apr 2004 13:35:27 -0400 From: Josh Littlefield Organization: Cisco Systems User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernie Volz CC: "'Kim Kinnear'" , "'Ralph Droms'" , dhcwg@ietf.org Subject: Re: [dhcwg] Security for leasequery messages References: <002d01c41e4d$2fab5850$6401a8c0@amer.cisco.com> In-Reply-To: <002d01c41e4d$2fab5850$6401a8c0@amer.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.4 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 Is IPSec for DHCP relay to server communication any more fully baked? Isn't that draft just documenting what is already possible, rather than proposing something new? Wouldn't another approach be to use RFC 3118? In this case, we aren't talking about relayed messages, we're talking about directed messages from a relay/access concentrator to the server (and back), with non-zero giaddr. Seems to me there's no reason RFC 3118 couldn't secure these messages based on shared secret. Bernie Volz wrote: > Seems like a good approach ... But will the IESG be happy with it? > > Today, there's always the basic security of only allowing the requests > from specific addresses (and since it is the reply that has the > interesting information, spoofing the sender doesn't buy you that much). > > - Bernie > > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of > Kim Kinnear > Sent: Wednesday, April 07, 2004 4:38 PM > To: Ralph Droms; dhcwg@ietf.org > Cc: kkinnear@cisco.com > Subject: Re: [dhcwg] Security for leasequery messages > > > > Folks, > > This is clearly an issue, and there are no easy answers. > Here is one approach: > > Nothing is mandatory to implement, since one approach is to ensure that > there is physical security between the access concentrator and the DHCP > server. > > A better approach is to use some form of the not-yet-fully-baked relay > agent authentication. For example: > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-auth-suboption-03.txt > > but since this is still coming along, it can't be mandatory, that's for > sure. We could wait to standardize leasequery until something was > approved for relay agent authentication, but that will further delay > something that has already undergone numerous delays. There are large > number of similar-to-the-standard leasequery installations, and more > every day. It would be nice to bring them all into compliance over > time, and time is getting away from us. > > One approach would be to make something mandatory once that something > exists, which is a little odd but perhaps doable. We might be able to > say: > > "When some form of relay-agent to DHCP server > authentication becomes a standard, its use for leasequery > becomes mandatory." > > Something to consider. > > Any other ideas for handle this one? > > Cheers -- Kim > > At 07:56 PM 4/6/2004, Ralph Droms wrote: > >>The following issues relate to security for leasequery messages: >> >>Steve Bellovin: >> >>Discuss: >>(26 March 2004) >>The Security Considerations section says this: >> >> DHCP servers SHOULD prevent exposure of location information >> (particularly the mapping of hardware address to IP address lease, >> which can be an invasion of broadband subscriber privacy) by >> employing some form of relay agent authentication between the >> DHCPLEASEQUERY client and the DHCP server. >> >> Clients of the DHCPLEASEQUERY message SHOULD ensure that their data >> path to the DHCP server is secure. Clients SHOULD use Relay Agent >> Information security as a way to achieve this goal. >> >>What is "some form of ... authentication"? What is "Relay Agent >>Information security"? Put another way, what is mandatory to >>implement? >> >>Russ Housley: >> >>Discuss: >> Section 7 says: >> > >> > DHCP servers SHOULD prevent exposure of location information >> > (particularly the mapping of hardware address to IP address lease, >> > which can be an invasion of broadband subscriber privacy) by >> > employing some form of relay agent authentication between the >> > DHCPLEASEQUERY client and the DHCP server. >> > >> There needs to be more discussion of the authentication requirements. >> I would prefer the specification to name a mandatory-to-implement >> mechanism, but that may be asking too much. >> >> Section 7 also says: >> > >> > Clients of the DHCPLEASEQUERY message SHOULD ensure that their data > > >>>path to the DHCP server is secure. > >> >> What security services are needed? Integrity, authentication, access >> control, replay protection confidentiality? The hint about Relay > > Agent > >> Information security, with no reference, is not sufficient. >> >> >> >>_______________________________________________ >>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 -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: same Boxborough, MA 01719-2205 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Apr 9 13: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 NAA10043; Fri, 9 Apr 2004 13:59:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC0HM-0000ZU-Dy; Fri, 09 Apr 2004 13:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC0HJ-0000ZH-28 for dhcwg@optimus.ietf.org; Fri, 09 Apr 2004 13:58:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10023 for ; Fri, 9 Apr 2004 13:58:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC0HF-0007SK-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 13:58:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC0Fw-0007L7-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 13:57:33 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BC0FG-0007Er-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 13:56:50 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id D8027974FE3; Fri, 9 Apr 2004 10:56:40 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24764-04; Fri, 9 Apr 2004 10:56:40 -0700 (PDT) Received: from redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id 79B82974FE0; Fri, 9 Apr 2004 10:56:40 -0700 (PDT) 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 KAA20064; Fri, 9 Apr 2004 10:56:40 -0700 (PDT) Message-Id: <200404091756.KAA20064@redback.com> To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] *DRAFT* minutes from WG meeting in Seoul (2nd try) In-reply-to: Mail from Ralph Droms dated Fri, 26 Mar 2004 10:37:58 EST <4.3.2.7.2.20040326103738.01fa1bd8@flask.cisco.com> Date: Fri, 09 Apr 2004 10:56:39 -0700 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: , Ralph, ] ] 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. ] I don't see how this draft fits into the new charter you just posted, and also can you arrange a discussion as mentioned in the Seoul meeting minutes? thanks. - Naiming _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Apr 9 15:41: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 PAA15738; Fri, 9 Apr 2004 15:41:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC1pG-00056G-Fq; Fri, 09 Apr 2004 15:38:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC1oM-0004Me-IG for dhcwg@optimus.ietf.org; Fri, 09 Apr 2004 15:37:10 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15405; Fri, 9 Apr 2004 15:37:08 -0400 (EDT) Message-Id: <200404091937.PAA15405@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 09 Apr 2004 15:37:08 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-subscriber-id-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 : DHCP Subscriber ID Suboption for the DHCP Relay Agent Option Author(s) : R. Johnson, et al. Filename : draft-ietf-dhc-subscriber-id-06.txt Pages : 10 Date : 2004-4-9 This memo defines a new Subscriber-ID suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to associate a stable 'Subscriber-ID' with DHCP client messages in a way that is independent of the client and of the underlying physical network infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-subscriber-id-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-subscriber-id-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-subscriber-id-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-4-9155022.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-subscriber-id-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-subscriber-id-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-9155022.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 Apr 9 19:43: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 TAA01502; Fri, 9 Apr 2004 19:43:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC5eH-0000ym-Ie; Fri, 09 Apr 2004 19:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC5dz-0000yC-Dp for dhcwg@optimus.ietf.org; Fri, 09 Apr 2004 19:42:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01477 for ; Fri, 9 Apr 2004 19:42:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC5dw-0002ji-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 19:42:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC5dC-0002cg-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 19:41:54 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BC5cC-0002OY-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 19:40:53 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HVX00201GF2MT@mailout3.samsung.com> for dhcwg@ietf.org; Sat, 10 Apr 2004 08:40:14 +0900 (KST) Received: from ep_mmp1 (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 <0HVX00M6CGF1C8@mailout3.samsung.com> for dhcwg@ietf.org; Sat, 10 Apr 2004 08:40:14 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HVX0042NGF11D@mmp1.samsung.com> for dhcwg@ietf.org; Sat, 10 Apr 2004 08:40:13 +0900 (KST) Date: Sat, 10 Apr 2004 08:40:35 +0900 From: "S. Daniel Park" Subject: RE: [dhcwg] applicability of draft-ietf-dhc-dhcpv6-ctep-opt-01 In-reply-to: <002f01c41e51$21e422c0$6401a8c0@amer.cisco.com> To: "'Bernie Volz'" , "'Pekka Savola'" , "'Ralph Droms'" Cc: dhcwg@ietf.org Message-id: <00ad01c41e8c$0e3b7990$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 Ok, we need to make it more clear, so I will show my thought soon whether or not to be considered in the DHC. 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 Bernie Volz > Sent: Saturday, April 10, 2004 1:39 AM > To: 'Pekka Savola'; 'Ralph Droms' > Cc: dhcwg@ietf.org > Subject: RE: [dhcwg] applicability of > draft-ietf-dhc-dhcpv6-ctep-opt-01 > > > I guess the solution is to ask the authors to add specific examples > of the environments in which this option will be used, if they still > feel > this option is needed. > > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of > Pekka Savola > Sent: Friday, April 09, 2004 10:51 AM > To: Ralph Droms > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] applicability of > draft-ietf-dhc-dhcpv6-ctep-opt-01 > > > On Fri, 9 Apr 2004, Ralph Droms wrote: > > My apologies for thoroughly confusing the conversation... > > No problem :) > > > So, let's leave draft-daniel-dhc-ipv6in4-opt-02 out of this > discussion > > > for the moment. Back to the scenario you asked about...I > can imagine > > (if you'll give me a moment of suspension-of-disbelief) that an ISP > > might want to provide IPv6/linklocal service between the service > > provider's edge router and the customer routers, without > going to full > > > IPv6 connectivity in its core. In that scenario, the > customer router > > could use DHCPv6 to obtain a prefix and a tunnel endpoint from a > > server in the service provider's edge router, while needing > the tunnel > > > for full external IPv6 connectivity. > > > > But that does seem like a far-fetched scenario... > > Yes, it's very far-fetched, because in this specific scenario: > > 1) the access network is usually the most difficult part to get > native v6, and > > 2) it's much simpler for all the concerned parties for the > ISP to use > internal tunneling to bridge the gaps in its core network. Whether > these tunnels are manually configured, set up automatically using 6PE > ("BGP-tunneling") between the border boxes, etc. makes little > difference. It's very simple to provide v6 support across v4 core if > your edge device supports v6 already. > > So, as stated -- I'm having a lot of trouble figuring out the real > applicability of this option, and I don't think we should go forward > with it. The danger is that it's more confusing than it's worth... > > -- > 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 > > > _______________________________________________ > 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 Fri Apr 9 20:11: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 UAA02054; Fri, 9 Apr 2004 20:11:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC65N-0003M0-7m; Fri, 09 Apr 2004 20:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC65I-0003Li-Rb for dhcwg@optimus.ietf.org; Fri, 09 Apr 2004 20:10:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02043 for ; Fri, 9 Apr 2004 20:10:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC65E-0005xS-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 20:10:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC64F-0005r6-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 20:09:52 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BC63P-0005e3-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 20:08:59 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HVX00D08HQ1NX@mailout1.samsung.com> for dhcwg@ietf.org; Sat, 10 Apr 2004 09:08: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 <0HVX00K35HPX3N@mailout1.samsung.com> for dhcwg@ietf.org; Sat, 10 Apr 2004 09:08:21 +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 <0HVX0061NHPWDN@mmp2.samsung.com> for dhcwg@ietf.org; Sat, 10 Apr 2004 09:08:21 +0900 (KST) Date: Sat, 10 Apr 2004 09:08:42 +0900 From: "S. Daniel Park" Subject: RE: [dhcwg] Revised charter In-reply-to: <4.3.2.7.2.20040409082236.02ac7a50@flask.cisco.com> To: "'Ralph Droms'" Cc: dhcwg@ietf.org Message-id: <00b001c41e8f$fc085e60$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 > Can you give us more details? What problems would we > consider as part of mobility support in DHCP? Well, I think it's not problem but restriction in DHCP. I guess current DHCP architecture is not concretely matched to the mobility because of long round-trips to get IP address and related information. Above all DHCP is a natural choice in the Wireless Lan (802.11) in conjunction with Access Point (AP), thus I think it's worth discussing this with dhc folks. It's [Introduction] [Background] [Design Goals] sections of preparing draft for your information and it will be available soon. Hope this helps. 1. Introduction The world has become increasingly mobile. As a result, traditional ways of networking the world have proven inadequate to meet the challenges posed by our new collective lifestyle. Wireless technology has been successful because it enables people to connect with each other regardless of location and the most successful wireless networking technology this far has been 802.11 WLAN [802.11][WLAN]. Regarding the wireless technology, DHCP [RFC 2131] is widely used for obtaining the network configuration on the mobile node such as its unique IP address and others in the local networks. DHCP is useful with access point which generally includes a DHCP server because it minimizes mobile node configuration. The DHCP server (access point) can be allocated a pool of addresses. The administrator specifies both the DHCP based address and the size of the pool. The DHCP server (access point) can also be configured to hand out a default gateway and DNS server information. The main objective of this draft is to propose a new architecture of DHCP to support the mobility on the DHCP client as mobile node. Also fast network attachment mechanism should be considered in conjunction with the mobile IP [RFC 3220] [MIP6] which allows a mobile node to move from one link to another without changing the mobile node's "home address". Packets may be routed to the mobile node using this address regardless of the mobile node's current point of attachment to the Internet. The mobile node may also continue to communicate with other nodes (stationary or mobile) after moving to a new link. The movement of a mobile node away from its home link is thus transparent to transport and higher-layer protocols and applications. The aim of this draft is neither network information such as DNS nor fast handover mechanism [FH802.11]. 3. Background The aim of this draft is to discuss mobility issue in the DHCP environment and it is especially appropriate for processes and devices which already interpret DHCP messages. In particular, a new proposed architecture allow DHCP server to send available IP addresses to DHCP client quickly to attach a new network when in motion. Placing DHCP server on the access point is a natural choice in the 802.11 wireless environment. The Unsolicited message is an extension to the DHCP protocol. The main purpose of this draft is to provide a starting point of mobility issue in the DHC Working Group. 4. Design Goals The goal of this draft is to provide a lightweight mechanism for supporting mobility in the DHCP environment. It is designed to optimize current DHCP mechanism to cut down number of round-trips between DHCP client and DHCP server. Here are some requirements why this design is required. [1] Wireless technologies especially 802.11 are widely spread in the DHCP environment, thus fast network attachment is importantly required on the DHCP client when in motion. [2] Current 4-messages exchange is not matched for the mobility. [3] Effectively this design aims outperforming rapid commit technique by substituting the explicit DHCP operation with the implicit link-layer association event. [4] DHCP server functionality is common on the access point. [5] For supporting mobility on the current DHCP protocol, minimal additional configuration/requirement is required. - 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 Fri Apr 9 20:16: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 UAA02194; Fri, 9 Apr 2004 20:16:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC6AE-0003sJ-Bw; Fri, 09 Apr 2004 20:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC69x-0003r4-FM for dhcwg@optimus.ietf.org; Fri, 09 Apr 2004 20:15:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02186 for ; Fri, 9 Apr 2004 20:15:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC69v-0006Vr-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 20:15:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC68w-0006P7-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 20:14:43 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BC67y-0006BW-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 20:13:42 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HVX0040DHXY7U@mailout3.samsung.com> for dhcwg@ietf.org; Sat, 10 Apr 2004 09:13:10 +0900 (KST) Received: from ep_mmp1 (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 <0HVX00MP7HXSC8@mailout3.samsung.com> for dhcwg@ietf.org; Sat, 10 Apr 2004 09:13:04 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HVX00KBHHXSTS@mmp1.samsung.com> for dhcwg@ietf.org; Sat, 10 Apr 2004 09:13:04 +0900 (KST) Date: Sat, 10 Apr 2004 09:13:26 +0900 From: "S. Daniel Park" Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-00 In-reply-to: <4.3.2.7.2.20040408090911.02af0ed8@flask.cisco.com> To: "'Ralph Droms'" , dhcwg@ietf.org Message-id: <00b101c41e90$a4c75fb0$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 Ralph, thanks your editorial comments on this draft and as Bernie indicated, I will also wait for additional comments during the WGLC. Regarding IPR comment, I have no any hard stance. Anyway I will also show a concrete statement on that after WGLC. - 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 08, 2004 10:21 PM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] dhc WG last call on > draft-ietf-dhc-rapid-commit-opt-00 > > > I see that this draft includes a notice regarding IPR. The > Samsung IPR > statement appears to apply across all IETF submissions. Can > the authors > clarify if there are any IPR claims that apply specifically > to this document? > > The format of the option - specifically, option length == 0 - > is consistent > with other DHCP options. Will length 0 cause problems in > practice with > deployed DHCP servers? > > The document should be republished to include RFC 3667 boilerplate, > including the RFC 3667 IPR notification statement. > > I have one editorial comment: the document should indicate > that the use of > Rapid Commit is optional on the part of the client, under > local (client) > admin control. In section 3, I suggest changing the first sentence: > > A client that supports the Rapid Commit option SHOULD > include it in > DHCPDISCOVER messages that it sends. > > to: > > If a client that supports the Rapid Commit option intends to use > the rapid commit capability, it includes a Rapid Commit > option in > DHCPDISCOVER messages that it sends. > > In section 3.1, list item 1, I suggest changing the first sentence: > > 1. The client broadcasts a DHCPDISCOVER message on its local > physical subnet and SHOULD include the Rapid > Commit option if > it supports this option. > > to: > > 1. The client broadcasts a DHCPDISCOVER message on its local > physical. If the client supports the Rapid Commit option > and intends to use the rapid commit capability, > it includes > a Rapid Commit option in the DHCPDISCOVER 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 Fri Apr 9 23: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 XAA08025; Fri, 9 Apr 2004 23:53:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC9YD-0004r3-S1; Fri, 09 Apr 2004 23:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC9Y2-0004qW-Qo for dhcwg@optimus.ietf.org; Fri, 09 Apr 2004 23:52:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07994 for ; Fri, 9 Apr 2004 23:52:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC9Xz-0003gz-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 23:52:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC9We-0003T1-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 23:51:25 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1BC9VJ-0003HP-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 23:50:01 -0400 Received: from [192.168.1.101] (pcp08421798pcs.orovly01.az.comcast.net [69.139.223.225]) by toccata.fugue.com (Postfix) with ESMTP id C604E1C1415; Fri, 9 Apr 2004 22:43:03 -0500 (CDT) In-Reply-To: <002c01c41e4c$bd8d0520$6401a8c0@amer.cisco.com> References: <002c01c41e4c$bd8d0520$6401a8c0@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1BEB42C0-8AA2-11D8-AE87-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: , "'Dhcwg'" From: Ted Lemon Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-3315id-for-v4-02.txt + LAST CALL Comments Date: Fri, 9 Apr 2004 20:49:46 -0700 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 Apr 9, 2004, at 9:07 AM, Bernie Volz wrote: > I would be against this because it will take significantly longer > (revising 2131/2132 will take a while to get through the IETF process). Yup, I agree with Bernie on this. I don't think we should think of the RFC2131/2132 revision something that's going to happen quickly. Of course we should try to do it in a timely fashion, but we shouldn't expect that we will definitely succeed. Look at how hard it's been to make leasequery, a fairly straightforward extension, happen. :'/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Apr 9 23:56: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 XAA08146; Fri, 9 Apr 2004 23:56:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC9b7-0004zN-0W; Fri, 09 Apr 2004 23:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC9ab-0004yt-Jy for dhcwg@optimus.ietf.org; Fri, 09 Apr 2004 23:55:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08103 for ; Fri, 9 Apr 2004 23:55:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC9aZ-000451-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 23:55:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC9ZY-0003um-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 23:54:25 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1BC9Y6-0003kb-00 for dhcwg@ietf.org; Fri, 09 Apr 2004 23:52:54 -0400 Received: from [192.168.1.101] (pcp08421798pcs.orovly01.az.comcast.net [69.139.223.225]) by toccata.fugue.com (Postfix) with ESMTP id 309A51B26F0; Fri, 9 Apr 2004 22:46:06 -0500 (CDT) In-Reply-To: <4076DEDF.8020004@cisco.com> References: <002d01c41e4d$2fab5850$6401a8c0@amer.cisco.com> <4076DEDF.8020004@cisco.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8A97A43A-8AA2-11D8-AE87-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: "'Kim Kinnear'" , "'Ralph Droms'" , Bernie Volz , dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] Security for leasequery messages Date: Fri, 9 Apr 2004 20:52:52 -0700 To: Josh Littlefield 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 Apr 9, 2004, at 10:35 AM, Josh Littlefield wrote: > Wouldn't another approach be to use RFC 3118? In this case, we aren't > talking about relayed messages, we're talking about directed messages > from a relay/access concentrator to the server (and back), with > non-zero giaddr. Seems to me there's no reason RFC 3118 couldn't > secure these messages based on shared secret. That's a good point - RFC3118 is actually a credible answer to the problem of securing server<->concentrator communication, because in most cases it is not a problem to use one or only a few shared keys in this context, where it's completely lame to do so in the context of a large set of DHCP end-users. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From yqnfrankgenev@aol.com Sat Apr 10 07:47:49 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 HAA02793 for ; Sat, 10 Apr 2004 07:47:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCGxg-0001Wx-00 for dhc-archive@ietf.org; Sat, 10 Apr 2004 07:47:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCGwY-0001M7-00 for dhc-archive@ietf.org; Sat, 10 Apr 2004 07:46:39 -0400 Received: from c-24-13-168-68.client.comcast.net ([24.13.168.68] helo=69.47.159.39) by ietf-mx with smtp (Exim 4.12) id 1BCGuW-000130-00 for dhc-archive@ietf.org; Sat, 10 Apr 2004 07:44:38 -0400 Received: from mx02.ipaper.com (mx02.ipaper.com [141.129.1.11]) by smtp.pbs.org with esmtp; abr, 10 2004 07:43:30 +0300 From: dloBrittney To: dhc-archive@ietf.org Subject: earn an extra $1,000/week ioe Sender: dloBrittney Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Sat, 10 Apr 2004 08:46:59 -0300 X-Mailer: Microsoft Outlook Build 10.0.2616 Message-Id: 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=7.5 required=5.0 tests=CLICK_BELOW,EARN_MONEY, FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS, HTML_FONT_BIG,HTML_LINK_CLICK_HERE,HTML_MESSAGE,HTML_MIME_NO_HTML_TAG, HTML_TAG_BALANCE_BODY,MAILTO_TO_REMOVE,MIME_HTML_ONLY, RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 1.1 EARN_MONEY BODY: Message talks about earning money * 0.1 HTML_LINK_CLICK_HERE BODY: HTML link text says "click here" * 0.3 HTML_TAG_BALANCE_BODY BODY: HTML has unbalanced "body" tags * 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.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.7 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 0.0 CLICK_BELOW Asks you to click below * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook

Extra Income Opportunityrit

     Earn up to $10,000/Moqxis

bjjpclick herehmqocs

 

 

 

   To take yourself out of our database please send an email to: remove@work2006.cjb.net

jxqdjubemxmembvt From dhcwg-admin@ietf.org Mon Apr 12 11:58: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 LAA26107; Mon, 12 Apr 2004 11:58:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD3ov-0004qs-Ed; Mon, 12 Apr 2004 11:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD3oG-0004q9-So for dhcwg@optimus.ietf.org; Mon, 12 Apr 2004 11:57:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26059 for ; Mon, 12 Apr 2004 11:57:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD3oE-0002tL-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 11:57:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD3mg-0002gC-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 11:55:43 -0400 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 1BD3km-0002Pm-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 11:53:44 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 12 Apr 2004 08:03:07 +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 i3CFr7GF000526 for ; Mon, 12 Apr 2004 08:53:07 -0700 (PDT) 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 AHN40933; Mon, 12 Apr 2004 11:53:06 -0400 (EDT) Message-Id: <4.3.2.7.2.20040412114035.02b48728@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Apr 2004 11:42:00 -0400 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] Reminder! dhc WG last call on draft-ietf-dhc-vendor-01 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 a reminder of the WG last call on "Vendor-Identifying Vendor Options for DHCPv4" . The last call will conclude at 5PM on 4/16/04. There has been one response to the last call. Although the document will be revised and go through another WG last call, respond now if you have additional comments, so all of the necessary revisions can be made at once. - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 12 11:58: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 LAA26109; Mon, 12 Apr 2004 11:58:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD3ow-0004r8-80; Mon, 12 Apr 2004 11:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD3oK-0004qM-JK for dhcwg@optimus.ietf.org; Mon, 12 Apr 2004 11:57:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26065 for ; Mon, 12 Apr 2004 11:57:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD3oI-0002tW-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 11:57:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD3mh-0002gS-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 11:55:44 -0400 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 1BD3kn-0002Q1-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 11:53:46 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 12 Apr 2004 08:01:57 +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 i3CFr7GH000526 for ; Mon, 12 Apr 2004 08:53:09 -0700 (PDT) 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 AHN40935; Mon, 12 Apr 2004 11:53:06 -0400 (EDT) Message-Id: <4.3.2.7.2.20040412114206.02b471d8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Apr 2004 11:52:29 -0400 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] Reminder! dhc WG last call on draft-ietf-dhc-3315id-for-v4-01 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 a reminder of the WG last call on "Node-Specific Client Identifiers for DHCPv4" . The last call will conclude at 5PM on 4/16/04. There has been discussion of this draft during the WG last call. However, it is not yet possible to judge consensus on issues raised in http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg03283.html and followup messages in the same thread. If you have comments on this specification, please send your input to the mailing list. - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 12 12:07: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 MAA26606; Mon, 12 Apr 2004 12:07:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD3xc-0005xe-VX; Mon, 12 Apr 2004 12:07:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD3xA-0005tn-U0 for dhcwg@optimus.ietf.org; Mon, 12 Apr 2004 12:06:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26549 for ; Mon, 12 Apr 2004 12:06:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD3x8-00047U-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 12:06:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD3w6-0003zU-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 12:05:27 -0400 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 1BD3ut-0003iH-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 12:04:11 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 12 Apr 2004 08:13: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 i3CG3a2Q022400 for ; Mon, 12 Apr 2004 09:03:38 -0700 (PDT) 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 AHN41820; Mon, 12 Apr 2004 12:03:34 -0400 (EDT) Message-Id: <4.3.2.7.2.20040412114943.02b471d8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Apr 2004 11:51:30 -0400 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.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Subject: [dhcwg] Reminder! dhc WG last call on draft-ietf-dhc-reclassify-options-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: , This message is a reminded of the WG last call on "Reclassifying DHCPv4 Options" . The last call will conclude at 5PM EST on 4/16/04. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 12 12:19: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 MAA27054; Mon, 12 Apr 2004 12:19:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD49F-000792-2w; Mon, 12 Apr 2004 12:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD48g-00075s-1Z for dhcwg@optimus.ietf.org; Mon, 12 Apr 2004 12:18:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27023 for ; Mon, 12 Apr 2004 12:18:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD48e-0005cI-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 12:18:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD47B-0005Pv-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 12:16:54 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BD45t-0005BH-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 12:15:33 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 12 Apr 2004 09:25:49 -0700 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 i3CGEnCC007280 for ; Mon, 12 Apr 2004 12:14:49 -0400 (EDT) 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 AHN42730; Mon, 12 Apr 2004 12:14:48 -0400 (EDT) Message-Id: <4.3.2.7.2.20040412121421.02b44888@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Apr 2004 12:14:46 -0400 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=1.0 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Subject: [dhcwg] Reminder! Revised 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: , Here is a draft charter for the WG, based on discussion at the WG meeting in Seoul and discussion on the mailing list. Please review and respond with comments. - Ralph dhc WG draft revised charter ---------------------------- The dhc working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCPv4 is currently a "Draft Standard" and is documented in RFC2131 and RFC2132. DHCPv6 is currently a "Proposed Standard" and is documented in RFC3315. Subsequent RFCS document additional options and other enhancements to the specifications. The DHC WG is responsible for reviewing (and sometimes developing) DHCP options or other extensions (for both IPv4 and IPv6). The DHC WG is expected to review all proposed extensions to DHCP to ensure that they are consistent with the DHCP specification and other option formats, that they do not duplicate existing mechanisms, etc. The DHC WG will not (generally) be responsible for evaluating the semantic content of proposed options. The DHC WG will not adopt new proposals for extensions to DHCP as working group documents without first coordinating with other relevant working groups and determining who has the responsibility for reviewing the semantic content of an option. The DHC WG has the following main objectives: * The DHC WG will address security in DHCP o Develop and document security requirements for DHCP. RFC 3118 defines current security mechanisms for DHCPv4. Unfortunately, RFC 3118 has neither been implemented nor deployed to date. Specific issues to be considered include: - Improved key management and scalability - Security for messages passed between relay agents and servers - Threats of DoS attacks through FORCERENEW - The increased usage of DHC on unsecured (e.g., wireless) and public LANs - The need for clients to be able to authenticate servers, without simultaneously requiring client authentication by the server. o Develop and document a roadmap of any new documents or protocols needed to meet the security requirements for DHCP * Write an analysis of the DHCP specification, including RFC2131, RFC2132 and other RFCs defining additional options, which identifies ambiguities, contradictory specifications and other obstacles to development of interoperable implementations. Recommend a process for resolving identified problems and incorporating the resolutions into the DHCP specification. * 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. * 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. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 12 12:46:20 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 LAA26108; Mon, 12 Apr 2004 11:58:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD3ow-0004rG-Mt; Mon, 12 Apr 2004 11:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD3oM-0004qR-NG for dhcwg@optimus.ietf.org; Mon, 12 Apr 2004 11:57:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26068 for ; Mon, 12 Apr 2004 11:57:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD3oJ-0002tc-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 11:57:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD3mi-0002gb-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 11:55:45 -0400 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 1BD3kp-0002QX-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 11:53:47 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 12 Apr 2004 08:03:12 +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 i3CFr7GL000526 for ; Mon, 12 Apr 2004 08:53:13 -0700 (PDT) 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 AHN40937; Mon, 12 Apr 2004 11:53:06 -0400 (EDT) Message-Id: <4.3.2.7.2.20040412114645.02b54080@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Apr 2004 11:49:21 -0400 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=1.2 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 Subject: [dhcwg] Reminder! dhc WG last call on draft-ietf-dhc-rapid-commit-opt-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: , This message is a reminder of the WG last call on "Rapid Commit Option for DHCPv4" . The last call will conclude at 5PM EST on 4/15/04. There has been only one response to the last call. Although the document will be revised, respond now if you have additional comments, so all of the necessary revisions can be made at once. - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 12 12:46:23 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 LAA26110; Mon, 12 Apr 2004 11:58:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD3ov-0004r0-RB; Mon, 12 Apr 2004 11:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD3oJ-0004qH-AE for dhcwg@optimus.ietf.org; Mon, 12 Apr 2004 11:57:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26062 for ; Mon, 12 Apr 2004 11:57:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD3oG-0002tQ-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 11:57:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD3mh-0002gK-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 11:55:43 -0400 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 1BD3km-0002QH-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 11:53:44 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 12 Apr 2004 08:03:10 +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 i3CFr7GJ000526 for ; Mon, 12 Apr 2004 08:53:11 -0700 (PDT) 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 AHN40936; Mon, 12 Apr 2004 11:53:06 -0400 (EDT) Message-Id: <4.3.2.7.2.20040412113642.02b45e40@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Apr 2004 11:47:25 -0400 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] Reminder! dhc WG last call on draft-ietf-dhc-proxyserver-opt-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: , This message is a reminder of the WG last call on "DHCP Option for Proxy Server Configuration" . The last call will conclude at 5PM EST on Friday, 4/16/04. There have only been two responses to the last call. Although the document will be revised and go through another WG last call, respond now if you have additional comments, so all of the necessary revisions can be made at once. - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 12 13:56: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 NAA01619; Mon, 12 Apr 2004 13:56:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD5f8-0001BR-9p; Mon, 12 Apr 2004 13:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD5em-0001AT-Ar for dhcwg@optimus.ietf.org; Mon, 12 Apr 2004 13:55:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01590 for ; Mon, 12 Apr 2004 13:55:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD5ej-0002mB-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 13:55:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD5dM-0002cF-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 13:54:12 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BD5cM-0002LO-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 13:53:10 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 12 Apr 2004 11:03:35 -0700 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 i3CHqXCC010405; Mon, 12 Apr 2004 13:52:34 -0400 (EDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHN51081; Mon, 12 Apr 2004 13:52:32 -0400 (EDT) From: "Bernie Volz" To: , Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 Date: Mon, 12 Apr 2004 13:52:32 -0400 Organization: Cisco Message-ID: <002d01c420b6$ee4c96f0$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 Importance: Normal 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: 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 this has been discussed in the past and discarded, but what about removing the need for yet-another-list? If the option where changed not to use sub-options at all but instead carried tuples of: 2-octets of well-known protocol number 4-octets of proxy server internet address 2-octets of proxy server port number The option length would then be multiples of 8 bytes. For example: Option Header: TBD-option-code,24-bytes Proxy for HTTP: 80,http-proxy-server-1,8080 Proxy for HTTP: 80,http-proxy-server-2,8080 Proxy for FTP: 21,ftp-proxy-server-1,21 This avoids the need for future protocols to have an enumeration and the current "getservicename" calls can be used to find the port numbers. Otherwise, I recommend moving this draft forward. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ted Lemon Sent: Wednesday, April 07, 2004 1:57 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 I have a bunch of suggested changes to this draft, which fall into three categories: 1. A single change to the protocol itself. 2. Editorial changes - I think there was some extra text in this draft explaining proxy servers that isn't needed, and generate questions during the IESG review, so I'm suggesting that it be deleted. 3. Copyediting. There were some minor spelling and grammatical errors. The change to the protocol is that it currently specifies an encapsulation of suboptions, like option 82, but allows for the appearance of multiple suboptions, which is different than the behavior specified for handling options in RFC3396. This is not a huge problem, but it probably requires additional code in DHCP servers and clients that isn't necessary, so I'd suggest changing it so that if you want to specify multiple proxy servers for the same protocol, you should just list more than one IP address/port tuple in the suboption for that protocol. I've enclosed a diff for all the changes. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 12 14:14: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 OAA02200; Mon, 12 Apr 2004 14:14:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD5wX-0002sa-OM; Mon, 12 Apr 2004 14:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD5w7-0002rU-TC for dhcwg@optimus.ietf.org; Mon, 12 Apr 2004 14:13:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02159 for ; Mon, 12 Apr 2004 14:13:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD5w4-0005Hp-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 14:13:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD5uU-00052W-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 14:11:55 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BD5t6-0004l6-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 14:10:28 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 12 Apr 2004 11:20:57 -0700 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 i3CI9tCC015909; Mon, 12 Apr 2004 14:09:55 -0400 (EDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHN52936; Mon, 12 Apr 2004 14:09:54 -0400 (EDT) From: "Bernie Volz" To: "'Ralph Droms'" , Subject: RE: [dhcwg] Reminder! dhc WG last call on draft-ietf-dhc-vendor-01 Date: Mon, 12 Apr 2004 14:09:54 -0400 Organization: Cisco Message-ID: <002e01c420b9$5b2d23a0$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 Importance: Normal In-Reply-To: <4.3.2.7.2.20040412114035.02b48728@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 I support this draft moving forward. Back at the end of February, I had posted http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg03177. html but as there was no interest in this, I remove that suggestion. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ralph Droms Sent: Monday, April 12, 2004 11:42 AM To: dhcwg@ietf.org Subject: [dhcwg] Reminder! dhc WG last call on draft-ietf-dhc-vendor-01 This message is a reminder of the WG last call on "Vendor-Identifying Vendor Options for DHCPv4" . The last call will conclude at 5PM on 4/16/04. There has been one response to the last call. Although the document will be revised and go through another WG last call, respond now if you have additional comments, so all of the necessary revisions can be made at once. - Ralph Droms _______________________________________________ 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 Apr 12 14:20: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 OAA02466; Mon, 12 Apr 2004 14:20:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD62L-0003Kk-7X; Mon, 12 Apr 2004 14:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD61p-0003Jn-O2 for dhcwg@optimus.ietf.org; Mon, 12 Apr 2004 14:19:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02417 for ; Mon, 12 Apr 2004 14:19:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD61n-0006A7-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 14:19:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD60V-0005tO-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 14:18:07 -0400 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 1BD5yu-0005ar-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 14:16:28 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 12 Apr 2004 10:25:57 +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 i3CIFt2O021712; Mon, 12 Apr 2004 11:15:55 -0700 (PDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHN53621; Mon, 12 Apr 2004 14:15:54 -0400 (EDT) From: "Bernie Volz" To: "'Ralph Droms'" , Subject: RE: [dhcwg] Reminder! dhc WG last call on draft-ietf-dhc-rapid-commit-opt-00 - shouldn't it be -01? Date: Mon, 12 Apr 2004 14:15:54 -0400 Organization: Cisco Message-ID: <002f01c420ba$31b6dc90$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 Importance: Normal In-Reply-To: <4.3.2.7.2.20040412114645.02b54080@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.2 required=5.0 tests=AWL,PLING_QUERY 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 FYI - The current version this draft is draft-ietf-dhc-rapid-commit-opt-01.txt. Being one of the co-authors (and subject to making the changes Ralph requested on 4/8), I support this moving forward. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ralph Droms Sent: Monday, April 12, 2004 11:49 AM To: dhcwg@ietf.org Subject: [dhcwg] Reminder! dhc WG last call on draft-ietf-dhc-rapid-commit-opt-00 This message is a reminder of the WG last call on "Rapid Commit Option for DHCPv4" . The last call will conclude at 5PM EST on 4/15/04. There has been only one response to the last call. Although the document will be revised, respond now if you have additional comments, so all of the necessary revisions can be made at once. - Ralph Droms _______________________________________________ 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 Apr 12 23: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 XAA03854; Mon, 12 Apr 2004 23:21:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDETt-0005Jo-06; Mon, 12 Apr 2004 23:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDDE4-0007x6-8w for dhcwg@optimus.ietf.org; Mon, 12 Apr 2004 22:00:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01315 for ; Mon, 12 Apr 2004 22:00:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDDDy-0005i3-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 22:00:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDDCr-0005Xb-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 21:59:22 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BDDBB-0005I7-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 21:57:37 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id BCABA15214; Tue, 13 Apr 2004 10:57:23 +0900 (JST) Date: Tue, 13 Apr 2004 10:57:24 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Reminder! Revised charter In-Reply-To: <4.3.2.7.2.20040412121421.02b44888@flask.cisco.com> References: <4.3.2.7.2.20040412121421.02b44888@flask.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 Mon, 12 Apr 2004 12:14:46 -0400, >>>>> Ralph Droms said: > Here is a draft charter for the WG, based on discussion at the WG meeting in > Seoul and discussion on the mailing list. Please review and respond with > comments. I can only see differences in indentation margin between this one and the one you sent on Apr. 7th...is that intentional? 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 Mon Apr 12 23:37: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 XAA04244; Mon, 12 Apr 2004 23:37:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDEjN-0006Kj-V7; Mon, 12 Apr 2004 23:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDEeM-00064O-5p for dhcwg@optimus.ietf.org; Mon, 12 Apr 2004 23:31:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04138 for ; Mon, 12 Apr 2004 23:31:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDEeI-0006uw-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 23:31:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDEd3-0006sF-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 23:30:30 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BDEbm-0006oO-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 23:29:11 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4E09515214; Tue, 13 Apr 2004 12:29:04 +0900 (JST) Date: Tue, 13 Apr 2004 12:29:04 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] applicability of draft-ietf-dhc-dhcpv6-ctep-opt-01 In-Reply-To: References: <4.3.2.7.2.20040409100329.02acd940@flask.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 Fri, 9 Apr 2004 17:51:03 +0300 (EEST), >>>>> Pekka Savola said: > Yes, it's very far-fetched, because in this specific scenario: > 1) the access network is usually the most difficult part to get > native v6, and > 2) it's much simpler for all the concerned parties for the ISP to use > internal tunneling to bridge the gaps in its core network. Whether > these tunnels are manually configured, set up automatically using 6PE > ("BGP-tunneling") between the border boxes, etc. makes little > difference. It's very simple to provide v6 support across v4 core if > your edge device supports v6 already. > So, as stated -- I'm having a lot of trouble figuring out the real > applicability of this option, and I don't think we should go forward > with it. The danger is that it's more confusing than it's worth... FWIW, I tend to agree with you here. But, apparently the authors are now trying to clarify the applicability, so I'm open to listening to it. 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 Mon Apr 12 23:39: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 XAA04324; Mon, 12 Apr 2004 23:39:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDElI-0006jM-Rf; Mon, 12 Apr 2004 23:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDEkS-0006gK-OR for dhcwg@optimus.ietf.org; Mon, 12 Apr 2004 23:38:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04286 for ; Mon, 12 Apr 2004 23:38:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDEkP-000772-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 23:38:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDEj5-000759-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 23:36:44 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BDEiW-00072S-00 for dhcwg@ietf.org; Mon, 12 Apr 2004 23:36:09 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 12 Apr 2004 20:37:25 -0700 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 i3D3ZPGF012151; Mon, 12 Apr 2004 20:35:25 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-201.cisco.com [10.86.242.201]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHN89145; Mon, 12 Apr 2004 23:35:24 -0400 (EDT) Message-Id: <4.3.2.7.2.20040412233048.01fa1988@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Apr 2004 23:35:21 -0400 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Ralph Droms Subject: Re: [dhcwg] Reminder! Revised charter Cc: dhcwg@ietf.org In-Reply-To: References: <4.3.2.7.2.20040412121421.02b44888@flask.cisco.com> <4.3.2.7.2.20040412121421.02b44888@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=1.0 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS 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 had intended to resend the original message about the charter - I don't know why the indentation changed. I've included belowa revised version with the edits you suggested and a few other minor editorial changes. - Ralph At 10:57 AM 4/13/2004 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >>>>> On Mon, 12 Apr 2004 12:14:46 -0400, > >>>>> Ralph Droms said: > > > Here is a draft charter for the WG, based on discussion at the WG > meeting in > > Seoul and discussion on the mailing list. Please review and respond with > > comments. > >I can only see differences in indentation margin between this one and >the one you sent on Apr. 7th...is that intentional? > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp The dhc working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCPv4 is currently a "Draft Standard" and is documented in RFC 2131 and RFC 2132. DHCPv6 is currently a "Proposed Standard" and is documented in RFC 3315. Subsequent RFCs document additional options and other enhancements to the specifications. The DHC WG is responsible for reviewing (and sometimes developing) DHCP options or other extensions (for both IPv4 and IPv6). The DHC WG is expected to review all proposed extensions to DHCP to ensure that they are consistent with the DHCP specification and other option formats, that they do not duplicate existing mechanisms, etc. The DHC WG will not (generally) be responsible for evaluating the semantic content of proposed options. The DHC WG will not adopt new proposals for extensions to DHCP as working group documents without first coordinating with other relevant working groups and determining who has the responsibility for reviewing the semantic content of an option. The DHC WG has the following main objectives: * The DHC WG will address security in DHCP o Develop and document security requirements for DHCP. RFC 3118 defines current security mechanisms for DHCPv4. Unfortunately, RFC 3118 has neither been implemented nor deployed to date. Specific issues to be considered include: - Improved key management and scalability - Security for messages passed between relay agents and servers - Threats of DoS attacks through DHCPFORCERENEW - The increased usage of DHC on unsecured (e.g., wireless) and public LANs - The need for clients to be able to authenticate servers, without simultaneously requiring client authentication by the server. o Develop and document a roadmap of any new documents or protocols needed to meet the security requirements for DHCP * Write an analysis of the DHCP specification, including RFC 2131, RFC 2132 and other RFCs defining additional options, which identifies ambiguities, contradictory specifications and other obstacles to development of interoperable implementations. Recommend a process for resolving identified problems and incorporating the resolutions into the DHCP specification. * 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 (RFC 2131, RFC 2132, RFC 3315 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. * The DHCPv6 specification in RFC 3315 includes a mechanism through which clients can obtain other configuration information without obtaining an address or addresses. This mechanisms is sometimes called "stateless DHCPv6" and is specified in RFC 3736. RFC 3315 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. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 13 10:06: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 KAA12943; Tue, 13 Apr 2004 10:06:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDOY5-00048M-16; Tue, 13 Apr 2004 10:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDOXD-0003tR-T5 for dhcwg@optimus.ietf.org; Tue, 13 Apr 2004 10:05:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12799 for ; Tue, 13 Apr 2004 10:05:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDOXB-0004au-00 for dhcwg@ietf.org; Tue, 13 Apr 2004 10:05:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDOWQ-0004XM-00 for dhcwg@ietf.org; Tue, 13 Apr 2004 10:04:19 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BDOVC-0004QA-00 for dhcwg@ietf.org; Tue, 13 Apr 2004 10:03:02 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 13 Apr 2004 07:13:31 -0700 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 i3DE2Kcp016057 for ; Tue, 13 Apr 2004 10:02:21 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-201.cisco.com [10.86.242.201]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHO07692; Tue, 13 Apr 2004 10:02:19 -0400 (EDT) Message-Id: <4.3.2.7.2.20040413100052.022e0a30@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Apr 2004 10:02:16 -0400 To: From: Ralph Droms Subject: RE: [dhcwg] Reminder! dhc WG last call on draft-ietf-dhc-rapid-commit-opt-00 - shouldn't it be -01? In-Reply-To: <002f01c420ba$31b6dc90$d0412ca1@amer.cisco.com> References: <4.3.2.7.2.20040412114645.02b54080@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=1.4 required=5.0 tests=AWL,OPT_HEADER,PLING_QUERY 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: , Whoops. Thanks for catching that goof, Bernie. All - please consider this last call to be on draft-ietf-dhc-rapid-commit-opt-01.txt. - Ralph At 02:15 PM 4/12/2004 -0400, Bernie Volz wrote: >FYI - The current version this draft is >draft-ietf-dhc-rapid-commit-opt-01.txt. Being one of the co-authors (and >subject to making the changes Ralph requested on 4/8), I support this >moving forward. > >- Bernie > >-----Original Message----- >From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of >Ralph Droms >Sent: Monday, April 12, 2004 11:49 AM >To: dhcwg@ietf.org >Subject: [dhcwg] Reminder! dhc WG last call on >draft-ietf-dhc-rapid-commit-opt-00 > > >This message is a reminder of the WG last call on "Rapid Commit Option >for DHCPv4" . The last call will >conclude at 5PM EST on 4/15/04. > >There has been only one response to the last call. Although the >document will be revised, respond now if you have additional comments, >so all of the necessary revisions can be made at once. > >- Ralph Droms > > >_______________________________________________ >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 Apr 13 12:04: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 MAA18822; Tue, 13 Apr 2004 12:04:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDQOH-0007lP-BK; Tue, 13 Apr 2004 12:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDQNM-0007fG-Mm for dhcwg@optimus.ietf.org; Tue, 13 Apr 2004 12:03:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18780 for ; Tue, 13 Apr 2004 12:03:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDQNJ-0005BZ-00 for dhcwg@ietf.org; Tue, 13 Apr 2004 12:03:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDQMQ-00056t-00 for dhcwg@ietf.org; Tue, 13 Apr 2004 12:02:07 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BDQLK-00053F-00; Tue, 13 Apr 2004 12:00:58 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3DG0CN22441; Tue, 13 Apr 2004 09:00:12 -0700 (PDT) Message-Id: <200404131600.i3DG0CN22441@boreas.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, dhcwg@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 13 Apr 2004 09:00:12 -0700 X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-9.3 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.60 Subject: [dhcwg] RFC 3736 on Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 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 Request for Comments is now available in online RFC libraries. RFC 3736 Title: Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 Author(s): R. Droms Status: Standards Track Date: April 2004 Mailbox: rdroms@cisco.com Pages: 9 Characters: 18510 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dhc-dhcpv6-stateless-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3736.txt Stateless Dynamic Host Configuration Protocol service for IPv6 (DHCPv6) is used by nodes to obtain configuration information, such as the addresses of DNS recursive name servers, that does not require the maintenance of any dynamic state for individual clients. A node that uses stateless DHCP must have obtained its IPv6 addresses through some other mechanism, typically stateless address autoconfiguration. This document explains which parts of RFC 3315 must be implemented in each of the different kinds of DHCP agents so that agent can support stateless DHCP. This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040413085915.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3736 --OtherAccess Content-Type: Message/External-body; name="rfc3736.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040413085915.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 13 15:15: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 PAA29882; Tue, 13 Apr 2004 15:15:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTDU-0001W3-DM; Tue, 13 Apr 2004 15:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDT6b-00041Z-Bu for dhcwg@optimus.ietf.org; Tue, 13 Apr 2004 14:57:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27547 for ; Tue, 13 Apr 2004 14:57:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDT6U-0005V5-00 for dhcwg@ietf.org; Tue, 13 Apr 2004 14:57:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDT5D-0005Pl-00 for dhcwg@ietf.org; Tue, 13 Apr 2004 14:56:31 -0400 Received: from smtp805.mail.sc5.yahoo.com ([66.163.168.184]) by ietf-mx with smtp (Exim 4.12) id 1BDT3h-0005EN-00 for dhcwg@ietf.org; Tue, 13 Apr 2004 14:54:57 -0400 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.116.97 with login) by smtp805.mail.sc5.yahoo.com with SMTP; 13 Apr 2004 18:54:29 -0000 Reply-To: From: "Richard Barr Hibbs" To: Subject: RE: [dhcwg] Reminder! Revised charter Date: Tue, 13 Apr 2004 12:02:22 -0700 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4.3.2.7.2.20040412121421.02b44888@flask.cisco.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: 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 revised charter looks good to me, Ralph --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 13 16:00:14 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 QAA03174; Tue, 13 Apr 2004 16:00:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTnL-0004EO-Ry; Tue, 13 Apr 2004 15:42:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTcC-0002gZ-AA for dhcwg@optimus.ietf.org; Tue, 13 Apr 2004 15:30:36 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01462; Tue, 13 Apr 2004 15:30:34 -0400 (EDT) Message-Id: <200404131930.PAA01462@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 13 Apr 2004 15:30:34 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-agentopt-radius-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 : RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option Author(s) : R. Droms, J. Schnizlein Filename : draft-ietf-dhc-agentopt-radius-06.txt Pages : 10 Date : 2004-4-13 A NAS (network access server) may choose to authenticate the identity of a device before granting that device access to the network. The IEEE 802.1X protocol is an example of a mechanism for providing authenticated layer 2 network access. A network element using RADIUS as an authentication authority will receive attributes from a RADIUS server that may be used by a DHCP server in the selection of configuration parameters to be delivered to the device through its DHCP client. The RADIUS Attributes sub-option enables a network element to pass along attributes for the user of a device received during RADIUS authentication to a DHCP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentopt-radius-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-agentopt-radius-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-agentopt-radius-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-4-13155017.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-agentopt-radius-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-agentopt-radius-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-13155017.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 Apr 13 17:19: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 RAA09575; Tue, 13 Apr 2004 17:19:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDV1t-0004NP-BR; Tue, 13 Apr 2004 17:01:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDU6e-0000BG-In for dhcwg@optimus.ietf.org; Tue, 13 Apr 2004 16:02:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03284 for ; Tue, 13 Apr 2004 16:02:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDU6b-0003WA-00 for dhcwg@ietf.org; Tue, 13 Apr 2004 16:02:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDU31-0003AS-00 for dhcwg@ietf.org; Tue, 13 Apr 2004 15:58:20 -0400 Received: from ftp.relicore.com ([4.36.57.198]) by ietf-mx with esmtp (Exim 4.12) id 1BDU0Q-0002ns-00 for dhcwg@ietf.org; Tue, 13 Apr 2004 15:55:38 -0400 Received: from STEVEPC ([192.168.0.222]) by ftp.relicore.com (8.12.9/8.12.9) with SMTP id i3DJW5tB024934; Tue, 13 Apr 2004 15:32:05 -0400 (EDT) From: "Steve Gonczi" To: Cc: Date: Tue, 13 Apr 2004 15:54:52 -0400 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.20040413100052.022e0a30@flask.cisco.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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [dhcwg] RE: dhc WG last call on draft-ietf-dhc-rapid-commit-opt-01 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 Greetings, I have some feedback on draft-ietf-dhc-rapid-commit-opt-01: 1) The draft verbatim quotes a fair amount of text from RFC 2131 E.g.: Sub-sections 1..6 under Paragraph 3.1 (BTW these sub-sections should probably be numbered 3.1.1 ..3.1.6) IMHO it would be preferable to just point to RFC 2131 where the Rapid Commit protocol works exactly as 2131, and focus more on the differences. There are some drawbacks to having the common DHCP behavior described in 2 different documents. E.g. the 2 texts may lose sync at one point. Eliminating the quoted RFC 2131 text would also shorten the document and would make it an easier read. 2) IMHO the Rapid Commit draft needs to mandate the following: "If a client obtains more than one addresses via Rapid Commit ack-s, it MUST release any such addresses if it decides not to use them." The draft does suggest some mitigating measures, under 3.2 Administrative considerations, such as: Configuring a single Rapid Commit server, or using shorter leases for Rapid Commit, but I believe the above would be a cleaner solution. cheers, Steve Gonczi _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 13 17:35:21 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 RAA10513; Tue, 13 Apr 2004 17:35:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVJM-0007K5-6L; Tue, 13 Apr 2004 17:19:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDUxo-0002aX-Cn for dhcwg@optimus.ietf.org; Tue, 13 Apr 2004 16:57:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07371 for ; Tue, 13 Apr 2004 16:56:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDUxm-0001lE-00 for dhcwg@ietf.org; Tue, 13 Apr 2004 16:56:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDUqa-0000tr-00 for dhcwg@ietf.org; Tue, 13 Apr 2004 16:49:33 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BDUiv-00004r-00 for dhcwg@ietf.org; Tue, 13 Apr 2004 16:41:37 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 13 Apr 2004 13:35:09 -0700 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 i3DKewcp028819; Tue, 13 Apr 2004 16:40:58 -0400 (EDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHO49862; Tue, 13 Apr 2004 16:40:57 -0400 (EDT) From: "Bernie Volz" To: "'Steve Gonczi'" Cc: Date: Tue, 13 Apr 2004 16:40:57 -0400 Organization: Cisco Message-ID: <003b01c42197$9fc1c0f0$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 Importance: Normal 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: 7bit Subject: [dhcwg] RE: dhc WG last call on draft-ietf-dhc-rapid-commit-opt-01 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'm pretty neutral on the issue of whether or not to copy text from 2131. When we eventually revise 2131, I believe we'd incorporate this capability (rapid commit) into the revised 2131 text so I don't think it is a significant issue. We could remove the text for those steps where there are no differences (such as step 4 - only) and replace it with "see RFC 2131". But, this may just increase the confusion (or at least complexity of following the flow)? Regarding issue 2, DHCPv6 doesn't mandate this (though in that case addresses aren't scarce) and doing this begs the question of how long does the client need to stick around listening for potential DHCPACKs for these additional messages? Section 3.2 is clear about when this option should be used and spells out the issues. It is also why we say: A server MAY allow configuration for a different (likely shorter) initial lease time for addresses assigned when Rapid Commit is used to expedite reclaiming addresses not used by clients. The main point of Rapid Commit is to get the client configured as quickly as possible. Doing a lease renewal tens of minutes later is not as significant an issue. We didn't include text in RFC 3315 (as best I could find and remember) about releasing addresses in this case for DHCPv6. So, not sure it is needed here (though again, addresses are not as scarce in v6). - Bernie -----Original Message----- From: Steve Gonczi [mailto:steve@relicore.com] Sent: Tuesday, April 13, 2004 3:55 PM To: volz@cisco.com Cc: dhcwg@ietf.org Subject: RE: dhc WG last call on draft-ietf-dhc-rapid-commit-opt-01 Greetings, I have some feedback on draft-ietf-dhc-rapid-commit-opt-01: 1) The draft verbatim quotes a fair amount of text from RFC 2131 E.g.: Sub-sections 1..6 under Paragraph 3.1 (BTW these sub-sections should probably be numbered 3.1.1 ..3.1.6) IMHO it would be preferable to just point to RFC 2131 where the Rapid Commit protocol works exactly as 2131, and focus more on the differences. There are some drawbacks to having the common DHCP behavior described in 2 different documents. E.g. the 2 texts may lose sync at one point. Eliminating the quoted RFC 2131 text would also shorten the document and would make it an easier read. 2) IMHO the Rapid Commit draft needs to mandate the following: "If a client obtains more than one addresses via Rapid Commit ack-s, it MUST release any such addresses if it decides not to use them." The draft does suggest some mitigating measures, under 3.2 Administrative considerations, such as: Configuring a single Rapid Commit server, or using shorter leases for Rapid Commit, but I believe the above would be a cleaner solution. cheers, Steve Gonczi _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Apr 14 03:01: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 DAA05060; Wed, 14 Apr 2004 03:01:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDeFe-0005qx-BE; Wed, 14 Apr 2004 02:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDeA8-0005A2-8Y for dhcwg@optimus.ietf.org; Wed, 14 Apr 2004 02:46:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04432 for ; Wed, 14 Apr 2004 02:46:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDeA4-0000aW-00 for dhcwg@ietf.org; Wed, 14 Apr 2004 02:46:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDe9D-0000UN-00 for dhcwg@ietf.org; Wed, 14 Apr 2004 02:45:24 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BDe8Y-0000Jf-00 for dhcwg@ietf.org; Wed, 14 Apr 2004 02:44:42 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW50091SEPNXU@mailout2.samsung.com> for dhcwg@ietf.org; Wed, 14 Apr 2004 15:44:11 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HW5009EPEPBD9@mailout2.samsung.com> for dhcwg@ietf.org; Wed, 14 Apr 2004 15:44:00 +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 <0HW50012VEPB5H@mmp2.samsung.com> for dhcwg@ietf.org; Wed, 14 Apr 2004 15:43:59 +0900 (KST) Date: Wed, 14 Apr 2004 15:44:22 +0900 From: "S. Daniel Park" Subject: RE: [dhcwg] Reminder! dhc WG last call on draft-ietf-dhc-reclassify-options-00 In-reply-to: <4.3.2.7.2.20040412114943.02b471d8@flask.cisco.com> To: "'Ralph Droms'" , dhcwg@ietf.org Message-id: <017601c421eb$eba1d7e0$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.3 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID 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 this draft moving forward. - 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: Tuesday, April 13, 2004 12:52 AM > To: dhcwg@ietf.org > Subject: [dhcwg] Reminder! dhc WG last call on > draft-ietf-dhc-reclassify-options-00 > > > This message is a reminded of the WG last call on > "Reclassifying DHCPv4 > Options" . The last call will > conclude at 5PM EST on 4/16/04. > > Please respond to this WG last call. If you support acceptance of the > document without change, respond with a simple acknowledgment, so that > support for the document can be assessed. > > - Ralph Droms > > > _______________________________________________ > 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 Apr 14 03:48: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 DAA06740; Wed, 14 Apr 2004 03:48:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDf30-00062P-Qd; Wed, 14 Apr 2004 03:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDf0O-0005EE-Gd for dhcwg@optimus.ietf.org; Wed, 14 Apr 2004 03:40:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06439 for ; Wed, 14 Apr 2004 03:40:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDf0M-0006fk-00 for dhcwg@ietf.org; Wed, 14 Apr 2004 03:40:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDezP-0006a4-00 for dhcwg@ietf.org; Wed, 14 Apr 2004 03:39:19 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BDez9-0006Uc-00 for dhcwg@ietf.org; Wed, 14 Apr 2004 03:39:04 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW500035H891M@mailout3.samsung.com> for dhcwg@ietf.org; Wed, 14 Apr 2004 16:38:33 +0900 (KST) Received: from ep_mmp1 (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 <0HW5005QUH6J68@mailout3.samsung.com> for dhcwg@ietf.org; Wed, 14 Apr 2004 16:37:32 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HW5009D2H6JJE@mmp1.samsung.com> for dhcwg@ietf.org; Wed, 14 Apr 2004 16:37:31 +0900 (KST) Date: Wed, 14 Apr 2004 16:37:54 +0900 From: "S. Daniel Park" Subject: RE: [dhcwg] Reminder! dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 In-reply-to: <4.3.2.7.2.20040412113642.02b45e40@flask.cisco.com> To: "'Ralph Droms'" , dhcwg@ietf.org Message-id: <017801c421f3$660f1310$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=1.4 required=5.0 tests=AWL,OPT_HEADER 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 have a two comments on this draft. [1] This draft said as below: >Proxy server increases the network security and >user productivity by content filtering and controlling >both internal and external access to information. I guess you are so confusing between filtering and proxy. Typically there are two types of firewalls such as *Filtering Firewalls - to block selected network packets. *Proxy Servers - to make network connections for you. Also, I am not sure proxy server increases the network security. [2] In Security Considerations >DHCP provides an authentication mechanism, as >described in RFC 3118 [3], which may be used if >authentication is required. Some proxy such as HTTP can provide an authentication to users without DHCP support. It means proxy server can ask the users to login/password before a connection to the outside is made. - 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: Tuesday, April 13, 2004 12:47 AM > To: dhcwg@ietf.org > Subject: [dhcwg] Reminder! dhc WG last call on > draft-ietf-dhc-proxyserver-opt-00 > > > This message is a reminder of the WG last call on "DHCP > Option for Proxy > Server Configuration" . > The last call > will conclude at 5PM EST on Friday, 4/16/04. > > There have only been two responses to the last call. > Although the document > will be revised and go through another WG last call, respond > now if you have > additional comments, so all of the necessary revisions can be > made at once. > > - Ralph Droms > > > _______________________________________________ > 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 Apr 14 13:19: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 NAA07900; Wed, 14 Apr 2004 13:19:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnrs-0007M1-Sz; Wed, 14 Apr 2004 13:08:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnJ3-0006kT-Ph for dhcwg@optimus.ietf.org; Wed, 14 Apr 2004 12:32:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04507 for ; Wed, 14 Apr 2004 12:32:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDnJ2-00057z-00 for dhcwg@ietf.org; Wed, 14 Apr 2004 12:32:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDnIL-00050u-00 for dhcwg@ietf.org; Wed, 14 Apr 2004 12:31:25 -0400 Received: from smtp808.mail.sc5.yahoo.com ([66.163.168.187]) by ietf-mx with smtp (Exim 4.12) id 1BDnHK-0004t2-00 for dhcwg@ietf.org; Wed, 14 Apr 2004 12:30:22 -0400 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.116.97 with login) by smtp808.mail.sc5.yahoo.com with SMTP; 14 Apr 2004 16:30:20 -0000 Reply-To: From: "Richard Barr Hibbs" To: Subject: RE: [dhcwg] RE: dhc WG last call on draft-ietf-dhc-rapid-commit-opt-01 Date: Wed, 14 Apr 2004 09:38:16 -0700 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal 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: 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 > -----Original Message----- > From: Steve Gonczi > Sent: Tuesday, 13 April 2004 12:55 > > I have some feedback on > draft-ietf-dhc-rapid-commit-opt-01: > > 1) The draft verbatim quotes a fair amount of > text from RFC 2131 > > E.g.: Sub-sections 1..6 under Paragraph 3.1 > (BTW these sub-sections should probably be > numbered 3.1.1 ..3.1.6) > > IMHO it would be preferable to just point to RFC 2131 > where the Rapid Commit protocol works exactly as 2131, > and focus more on the differences. > > There are some drawbacks to having the common > DHCP behavior > described in 2 different documents. E.g. the 2 > texts may lose > sync at one point. > Eliminating the quoted RFC 2131 text would also shorten > the document and would make it an easier read. > ...yes, Steve, we have inadvertently introduced synchronization errors in the past by having the same action described in two (or more) different RFCs, but Bernie may have had in mind my current draft on procedures for updating DHCPv4 (http://www.ietf.org/internet-drafts/draft-hibbs-dhc-changes -00.txt) when he included the quoted text. I personally feel that supplying replacement text in it's entirety for the existing text in an RFC to be updated by an I-D is a good idea, in that a complete replacement avoids many typographical errors when applying the new text. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Apr 14 13:52:20 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 NAA10987; Wed, 14 Apr 2004 13:52:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDoOk-0000ML-7x; Wed, 14 Apr 2004 13:42:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDo8l-0003nh-30 for dhcwg@optimus.ietf.org; Wed, 14 Apr 2004 13:25:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08632 for ; Wed, 14 Apr 2004 13:25:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDo8j-0001vY-00 for dhcwg@ietf.org; Wed, 14 Apr 2004 13:25:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDo7p-0001mN-00 for dhcwg@ietf.org; Wed, 14 Apr 2004 13:24:38 -0400 Received: from smtp812.mail.sc5.yahoo.com ([66.163.170.82]) by ietf-mx with smtp (Exim 4.12) id 1BDo6a-0001dz-00 for dhcwg@ietf.org; Wed, 14 Apr 2004 13:23:20 -0400 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.116.97 with login) by smtp812.mail.sc5.yahoo.com with SMTP; 14 Apr 2004 17:23:18 -0000 Reply-To: From: "Richard Barr Hibbs" To: Subject: RE: [dhcwg] Use of SNMP instead of leasequery Date: Wed, 14 Apr 2004 10:31:14 -0700 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: <4.3.2.7.2.20040406201645.02cc2b08@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 comments in-line --Barr > -----Original Message----- > From: Ralph Droms > Sent: Tuesday, 06 April 2004 17:21 > > Bert Wijnen: > - what is the status of this solution vs. DHCP MIB > solution (I thought they were competing solutions > some time back). > - The DHC MIB has also been submitted for PS, > no? I know it is still in MIB Doctor review... but > it is a 2nd solution to same problem. > - The reasoning for not using SNMP and MIB seem > very weak to me > ...the MIB effort grew out of traffic engineering and troubleshooting activities at Pacific*Bell, and was primarily intended as a method of gathering performance statistics about the servers we operated and the load presented to them by our very large installation [for that time.] Despite the presence in the proposed DHCPv4 server MIB of objects that report configuration and [status] information. DHCPLEASEQUERY is intended to provide detailed, specific information about individual leases, while the MIB was intended to provide more generic, server-wide aggregated or summarized data. Also, the DHCPLEASEQUERY message type is not required to be supported by all DHCPv4 servers: the I-D does not make that demand for either existing or new server implementations. > Ted Hardie: > It's too bad that SNMP is off the table here, as > that would give you a realistic way to limit data > to specific queries and queries. > ...my primary objection to making the information reported by responses to DHCPLEASEQUERY messages accessible through the DHCPv4 server MIB is that processing of DHCPLEASEQUERY messages is not required of all DHCPv4 servers: my sense from the MIB Doctor review of the proposed server MIB is that defining optional MIB objects and objects for optional features is discouraged. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Apr 14 14:03:14 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 OAA11484; Wed, 14 Apr 2004 14:03:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDoRZ-0001Ei-W4; Wed, 14 Apr 2004 13:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDoNs-0008Ov-II for dhcwg@optimus.ietf.org; Wed, 14 Apr 2004 13:41:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10008 for ; Wed, 14 Apr 2004 13:41:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDoNq-00031h-00 for dhcwg@ietf.org; Wed, 14 Apr 2004 13:41:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDoN0-0002zP-00 for dhcwg@ietf.org; Wed, 14 Apr 2004 13:40:19 -0400 Received: from smtp814.mail.sc5.yahoo.com ([66.163.170.84]) by ietf-mx with smtp (Exim 4.12) id 1BDoMY-0002wO-00 for dhcwg@ietf.org; Wed, 14 Apr 2004 13:39:50 -0400 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.116.97 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 14 Apr 2004 17:39:38 -0000 Reply-To: From: "Richard Barr Hibbs" To: Subject: RE: [dhcwg] Restrictions of information flow in leasequery messages Date: Wed, 14 Apr 2004 10:47:35 -0700 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: <002e01c41e4f$cf1de8b0$6401a8c0@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 comments in-line --Barr > -----Original Message----- > From: Bernie Volz > Sent: Friday, 09 April 2004 09:29 > > Perhaps a solution is that a server always has > the option of not returning data it considers > too sensitive - such as GEOPRIV information. > ...I'd suggest that the option of which information to return be specifically named as a "local policy" issue -- I still carry the bruises from the discussion about provisioning servers with client location information, so am just a bit sensitive to this one in particular. As I've been repeatedly told, in some legal jurisdictions physical location information is required, to be available to emergency responders and others according to statute or ordinance. One method for obtaining this information might be to use the DHCPLEASEQUERY mechanism, so we need to be specific, I think, that the data to be returned ought to be in the realm of local administrative decisions. In some jurisdictions, location information would be considered private or privileged information, while in others it may be mandated to be publicly available. Let's stay away from the policy questions and declared this a local administrative matter. > Perhaps something like the following should be > added to the Security Considerations: > > In some environments it may be appropriate to > configure a DHCP server with option numbers that > MUST not be returned in response to DHCPLEASEQUERY > messages because these options are considered to > contain sensitive information. > ...I like this wording.... > I do think that once security options exists for > relay to server communication, if this was a > concern at a site, the site should use those > options (and restrict who the server responds to > for a DHCPLEASEQUERY). > ...you're almost suggesting that a more complete security model be developed for DHCPv4, including Access Control Lists for DHCPLEASEQUERY requests and responses. While I don't object, I think that we should keep in mind what we might be calling for as a future requirement. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Apr 14 15:42:15 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 PAA18975; Wed, 14 Apr 2004 15:42:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDqCu-0004rJ-On; Wed, 14 Apr 2004 15:38:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDq4q-0002rW-Mj for dhcwg@optimus.ietf.org; Wed, 14 Apr 2004 15:29:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18091 for ; Wed, 14 Apr 2004 15:29:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDq4p-0002Lf-00 for dhcwg@ietf.org; Wed, 14 Apr 2004 15:29:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDq3v-0002JI-00 for dhcwg@ietf.org; Wed, 14 Apr 2004 15:28:43 -0400 Received: from ftp.relicore.com ([4.36.57.198]) by ietf-mx with esmtp (Exim 4.12) id 1BDq3Z-0002GC-00 for dhcwg@ietf.org; Wed, 14 Apr 2004 15:28:21 -0400 Received: from STEVEPC ([192.168.0.222]) by ftp.relicore.com (8.12.9/8.12.9) with SMTP id i3EJ4stB027446; Wed, 14 Apr 2004 15:04:54 -0400 (EDT) From: "Steve Gonczi" To: "Bernie Volz" Cc: Date: Wed, 14 Apr 2004 15:27:42 -0400 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: <003b01c42197$9fc1c0f0$d0412ca1@amer.cisco.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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [dhcwg] RE: dhc WG last call on draft-ietf-dhc-rapid-commit-opt-01 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'm pretty neutral on the issue of whether or not to copy text from > 2131. When we eventually revise 2131, I believe we'd incorporate this > capability (rapid commit) into the revised 2131 text so I don't think it > is a significant issue. Yes, if rapid commit gets merged with 2131, the text would be entirely appropriate for that draft. Is the merging of the 2 documents intended by the WG? In the past, I have seen the opposite trend (i.e. breaking out optional features into separate drafts, like in the case of the DHC load balancing RFC that was originally part of the failover draft). I maintain that the current draft would be easier to read if it just described the specifics of what it does differently. >Section 3.2 is clear about when this option should be used and spells >out the issues. It is also why we say: > A server MAY allow configuration for a different (likely > shorter) initial lease time for addresses assigned when Rapid > Commit is used to expedite reclaiming addresses not used by > clients. Regarding the IPv4 address leakage issue: I would prefer at least allowing a solution in the protocol itself, instead of mandating deployment policy. (Which you do in 3.2) Ideally, protocol standards would speak to the implementer community, not the sysadmins. If it is impractical to solve the issue in the protocol itself the deployment restrictions should be a SHOULD not a MUST. Section 3.2 should consider other possibilities to deal with address depletion, such as using the DHC load balancing algo to prevent multiple responding servers. How about: "Since the Rapid Commit protocol provides no facilities to prevent tying up multiple IPv4 addresses by multiple responding servers, deployments SHOULD prevent multiple address commitments, relying on one or more of the following options: a) If possible, deploy the DHC load balancing protocol, or b) Allow a single Rapid Commit enabled server per site c) Provide a sufficiently large IP address pool d) Employ sufficiently short Rapid Commit lease times Cheers /sG _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Apr 15 22:47: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 WAA21162; Thu, 15 Apr 2004 22:47:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEJKj-0007to-E0; Thu, 15 Apr 2004 22:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEJHf-0007K9-Ak for dhcwg@optimus.ietf.org; Thu, 15 Apr 2004 22:40:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20908 for ; Thu, 15 Apr 2004 22:40:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEJHb-0003M0-UI for dhcwg@ietf.org; Thu, 15 Apr 2004 22:40:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEJGo-0003IC-00 for dhcwg@ietf.org; Thu, 15 Apr 2004 22:39:59 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BEJFq-0003A0-00 for dhcwg@ietf.org; Thu, 15 Apr 2004 22:38:58 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW80091QSO3JT@mailout1.samsung.com> for dhcwg@ietf.org; Fri, 16 Apr 2004 11:38:27 +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 <0HW800MGQSNKUH@mailout1.samsung.com> for dhcwg@ietf.org; Fri, 16 Apr 2004 11:38:08 +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 <0HW8001VESNJ5M@mmp2.samsung.com> for dhcwg@ietf.org; Fri, 16 Apr 2004 11:38:08 +0900 (KST) Date: Fri, 16 Apr 2004 11:38:31 +0900 From: "S. Daniel Park" Subject: RE: [dhcwg] RE: dhc WG last call on draft-ietf-dhc-rapid-commit-opt-01 In-reply-to: To: "'Steve Gonczi'" , "'Bernie Volz'" Cc: dhcwg@ietf.org, "'S. Daniel Park'" Message-id: <01ad01c4235b$e8321950$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 Steve, thanks your valuable comments on the draft during WGLC and kindly look my response inline. - Daniel (Soohong Daniel Park) - Mobile Platform Laboratory, SAMSUNG Electronics. > How about: > > "Since the Rapid Commit protocol provides no facilities to > prevent tying up > multiple IPv4 addresses by multiple responding servers, deployments > SHOULD prevent multiple address commitments, relying on one > or more of the > following options: > > a) If possible, deploy the DHC load balancing protocol, or > b) Allow a single Rapid Commit enabled server per site > c) Provide a sufficiently large IP address pool > d) Employ sufficiently short Rapid Commit lease times > I think the current draft already sufficiently described (b),(c),(d). IMO, (a) is beyond our scope because it is a supplementary method on the DHCP body not specific Rapid Commit issue. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Apr 15 23:43:18 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 XAA24115; Thu, 15 Apr 2004 23:43:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEKBy-0001X5-VS; Thu, 15 Apr 2004 23:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEK5s-0008NG-O7 for dhcwg@optimus.ietf.org; Thu, 15 Apr 2004 23:32:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23632 for ; Thu, 15 Apr 2004 23:32:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEK5q-00073V-L4 for dhcwg@ietf.org; Thu, 15 Apr 2004 23:32:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEK4r-00070W-00 for dhcwg@ietf.org; Thu, 15 Apr 2004 23:31:42 -0400 Received: from smtp812.mail.sc5.yahoo.com ([66.163.170.82]) by ietf-mx with smtp (Exim 4.12) id 1BEK3u-0006xL-00 for dhcwg@ietf.org; Thu, 15 Apr 2004 23:30:42 -0400 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.116.97 with login) by smtp812.mail.sc5.yahoo.com with SMTP; 16 Apr 2004 03:30:42 -0000 Reply-To: From: "Richard Barr Hibbs" To: Subject: RE: [dhcwg] Reminder! dhc WG last call on draft-ietf-dhc-rapid-commit-opt-00 - shouldn't it be -01? Date: Thu, 15 Apr 2004 20:38:43 -0700 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: <002f01c420ba$31b6dc90$d0412ca1@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.1 required=5.0 tests=AWL,PLING_QUERY 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 support advancing this draft. --Barr > -----Original Message----- > From: Bernie Volz > Sent: Monday, 12 April 2004 11:16 > > FYI - The current version this draft is > draft-ietf-dhc-rapid-commit-opt-01.txt. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Apr 15 23:44:19 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 XAA24163; Thu, 15 Apr 2004 23:44:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEKBz-0001XH-L9; Thu, 15 Apr 2004 23:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEKAp-00017R-4A for dhcwg@optimus.ietf.org; Thu, 15 Apr 2004 23:37:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23794 for ; Thu, 15 Apr 2004 23:37:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEKAn-0007Jb-2L for dhcwg@ietf.org; Thu, 15 Apr 2004 23:37:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEK9p-0007GG-00 for dhcwg@ietf.org; Thu, 15 Apr 2004 23:36:50 -0400 Received: from smtp808.mail.sc5.yahoo.com ([66.163.168.187]) by ietf-mx with smtp (Exim 4.12) id 1BEK95-0007DN-00 for dhcwg@ietf.org; Thu, 15 Apr 2004 23:36:03 -0400 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.116.97 with login) by smtp808.mail.sc5.yahoo.com with SMTP; 16 Apr 2004 03:36:03 -0000 Reply-To: From: "Richard Barr Hibbs" To: Subject: RE: [dhcwg] Reminder! dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 Date: Thu, 15 Apr 2004 20:44:04 -0700 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: <017801c421f3$660f1310$67cadba8@LocalHost> 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 I support advancing this draft. --Barr > > -----Original Message----- > > From: Ralph Droms > > Sent: Tuesday, April 13, 2004 12:47 AM > > > > This message is a reminder of the WG last call on "DHCP > > Option for Proxy Server Configuration" > . > > The last call will conclude at 5PM EST on Friday, 4/16/04. > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Apr 15 23:50:20 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 XAA24486; Thu, 15 Apr 2004 23:50:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEKHp-0002rd-Ex; Thu, 15 Apr 2004 23:45:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEKFd-0002Jb-EU for dhcwg@optimus.ietf.org; Thu, 15 Apr 2004 23:42:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24089 for ; Thu, 15 Apr 2004 23:42:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEKFb-0007mO-4z for dhcwg@ietf.org; Thu, 15 Apr 2004 23:42:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEKEm-0007jC-00 for dhcwg@ietf.org; Thu, 15 Apr 2004 23:41:57 -0400 Received: from smtp814.mail.sc5.yahoo.com ([66.163.170.84]) by ietf-mx with smtp (Exim 4.12) id 1BEKE0-0007f0-00 for dhcwg@ietf.org; Thu, 15 Apr 2004 23:41:08 -0400 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.116.97 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 16 Apr 2004 03:41:08 -0000 Reply-To: From: "Richard Barr Hibbs" To: "S. Daniel Park" , "'Ralph Droms'" , Subject: RE: [dhcwg] Reminder! dhc WG last call on draft-ietf-dhc-reclassify-options-00 Date: Thu, 15 Apr 2004 20:49:08 -0700 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: <017601c421eb$eba1d7e0$67cadba8@LocalHost> 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 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 thought I'd previously responded to this last call, but I can't find the message, so.... I support advancing this draft. --Barr > > -----Original Message----- > > From: Ralph Droms > > Sent: Tuesday, April 13, 2004 12:52 AM > > > > This message is a reminded of the WG last call on > > "Reclassifying DHCPv4 Options" > . The last > call will conclude at 5PM EST on 4/16/04. > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Apr 16 00:08: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 AAA25199; Fri, 16 Apr 2004 00:08:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEKYE-0005lQ-VF; Fri, 16 Apr 2004 00:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEKV3-0004dN-Tq for dhcwg@optimus.ietf.org; Thu, 15 Apr 2004 23:58:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24851 for ; Thu, 15 Apr 2004 23:58:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEKV1-00016i-IQ for dhcwg@ietf.org; Thu, 15 Apr 2004 23:58:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEKU7-00013j-00 for dhcwg@ietf.org; Thu, 15 Apr 2004 23:57:47 -0400 Received: from smtp805.mail.sc5.yahoo.com ([66.163.168.184]) by ietf-mx with smtp (Exim 4.12) id 1BEKTB-00010m-00 for dhcwg@ietf.org; Thu, 15 Apr 2004 23:56:50 -0400 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.116.97 with login) by smtp805.mail.sc5.yahoo.com with SMTP; 16 Apr 2004 03:56:49 -0000 Reply-To: From: "Richard Barr Hibbs" To: Subject: RE: [dhcwg] Reminder! dhc WG last call on draft-ietf-dhc-3315id-for-v4-01 Date: Thu, 15 Apr 2004 21:04:50 -0700 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: <4.3.2.7.2.20040412114206.02b471d8@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 I support advancing this draft, but have a couple of minor suggestions that I believe the authors should consider. (1) Section 1.0 Applicability, second sentence: "DHCPv4 servers implementations...." SHOULD read "DHCPv4 server implementations...." (2) Section 2.1 Client identities are ephemeral, last sentence: "...domain name as published through the DHCP server" probably SHOULD read "...domain name as published through the DHCPv4 server" as this paragraph is discussing an issue with RFC 2132. In other places in the draft DHCPv4 and DHCPv6 were separately identified where appropriate, and jointly identified as DHCP when appropriate. (3) Section 4.3 Changes from RFC2131, last sentence, "...is replaced by the text, 'The client MUST explicitly provide a client identifier through the "client identifier" option'" would be improved by the addition of the following wording, "...and MUST use the SAME client identifier for ALL messages." --Barr > -----Original Message----- > From: Ralph Droms > Sent: Monday, 12 April 2004 08:52 > > This message is a reminder of the WG last call on > "Node-Specific Client Identifiers for DHCPv4" > . The last call > will conclude at 5PM on 4/16/04. > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Apr 16 00: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 AAA25556; Fri, 16 Apr 2004 00:19:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEKko-0007lG-S8; Fri, 16 Apr 2004 00:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEKdm-0006bb-Hr for dhcwg@optimus.ietf.org; Fri, 16 Apr 2004 00:07:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25190 for ; Fri, 16 Apr 2004 00:07:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEKdk-0001iO-30 for dhcwg@ietf.org; Fri, 16 Apr 2004 00:07:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEKcl-0001ev-00 for dhcwg@ietf.org; Fri, 16 Apr 2004 00:06:43 -0400 Received: from smtp812.mail.sc5.yahoo.com ([66.163.170.82]) by ietf-mx with smtp (Exim 4.12) id 1BEKbm-0001ZQ-00 for dhcwg@ietf.org; Fri, 16 Apr 2004 00:05:42 -0400 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.116.97 with login) by smtp812.mail.sc5.yahoo.com with SMTP; 16 Apr 2004 04:05:43 -0000 Reply-To: From: "Richard Barr Hibbs" To: "Dhcwg" Subject: FW: [dhcwg] Reminder! dhc WG last call on draft-ietf-dhc-3315id-for-v4-01 Date: Thu, 15 Apr 2004 21:13:43 -0700 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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 duh! left out something.... (4) Section 4.4, Changes from RFC2132, replacement text would be improved by the addition of a diagram. --Barr -----Original Message----- From: Richard Barr Hibbs [mailto:rbhibbs@pacbell.net] Sent: Thursday, 15 April 2004 21:05 To: dhcwg@ietf.org Subject: RE: [dhcwg] Reminder! dhc WG last call on draft-ietf-dhc-3315id-for-v4-01 I support advancing this draft, but have a couple of minor suggestions that I believe the authors should consider. (1) Section 1.0 Applicability, second sentence: "DHCPv4 servers implementations...." SHOULD read "DHCPv4 server implementations...." (2) Section 2.1 Client identities are ephemeral, last sentence: "...domain name as published through the DHCP server" probably SHOULD read "...domain name as published through the DHCPv4 server" as this paragraph is discussing an issue with RFC 2132. In other places in the draft DHCPv4 and DHCPv6 were separately identified where appropriate, and jointly identified as DHCP when appropriate. (3) Section 4.3 Changes from RFC2131, last sentence, "...is replaced by the text, 'The client MUST explicitly provide a client identifier through the "client identifier" option'" would be improved by the addition of the following wording, "...and MUST use the SAME client identifier for ALL messages." --Barr > -----Original Message----- > From: Ralph Droms > Sent: Monday, 12 April 2004 08:52 > > This message is a reminder of the WG last call on > "Node-Specific Client Identifiers for DHCPv4" > . The last call > will conclude at 5PM on 4/16/04. > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Apr 16 02:31:07 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 CAA15242; Fri, 16 Apr 2004 02:31:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEMob-0005uX-AC; Fri, 16 Apr 2004 02:27:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEMjb-0003kJ-No for dhcwg@optimus.ietf.org; Fri, 16 Apr 2004 02:21:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14691 for ; Fri, 16 Apr 2004 02:21:53 -0400 (EDT) From: narten@us.ibm.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEMjY-00050Z-0B for dhcwg@ietf.org; Fri, 16 Apr 2004 02:21:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEMif-0004x0-00 for dhcwg@ietf.org; Fri, 16 Apr 2004 02:20:57 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BEMiI-0004t4-00 for dhcwg@ietf.org; Fri, 16 Apr 2004 02:20:34 -0400 Received: from [203.192.215.86] (helo=ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BEMiG-0006PX-AE for dhcwg@ietf.org; Fri, 16 Apr 2004 02:20:32 -0400 To: dhcwg@ietf.org Date: Sat, 1 Jan 2000 00:29:28 +0530 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_001B_01C0CA80.6B015D10" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.5 required=5.0 tests=DATE_IN_PAST_96_XX,HTML_40_50, HTML_MESSAGE,HTML_RELAYING_FRAME,MICROSOFT_EXECUTABLE, MIME_SUSPECT_NAME,MISSING_MIMEOLE,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 Subject: [dhcwg] Mail Delivery (failure dhcwg@ietf.org) 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. ------=_NextPart_000_001B_01C0CA80.6B015D10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001C_01C0CA80.6B015D10" ------=_NextPart_001_001C_01C0CA80.6B015D10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_001C_01C0CA80.6B015D10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If the message will not displayed automatically,
follow the link to read the delivered message.

Received message is available at:
www.ietf.org/inbox/dhcwg/read.php?sessionid-29955
 
------=_NextPart_001_001C_01C0CA80.6B015D10-- ------=_NextPart_000_001B_01C0CA80.6B015D10 Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [Filename: message.scr, Content-Type: audio/x-wav] The attachment file in the message has been removed by eManager. ------=_NextPart_000_001B_01C0CA80.6B015D10-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Apr 16 13:08: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 NAA22300; Fri, 16 Apr 2004 13:08:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEWhC-0000dG-SR; Fri, 16 Apr 2004 13:00:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEWZc-0004dz-57 for dhcwg@optimus.ietf.org; Fri, 16 Apr 2004 12:52:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21285 for ; Fri, 16 Apr 2004 12:52:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEWZa-0003Ws-Bq for dhcwg@ietf.org; Fri, 16 Apr 2004 12:52:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEWYh-0003U6-00 for dhcwg@ietf.org; Fri, 16 Apr 2004 12:51:20 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BEWXy-0003Nu-00 for dhcwg@ietf.org; Fri, 16 Apr 2004 12:50:34 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 16 Apr 2004 10:01:45 -0700 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 i3GGo2AH013544 for ; Fri, 16 Apr 2004 12:50:02 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (dhcp-10-86-160-195.cisco.com [10.86.160.195]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHQ75867; Fri, 16 Apr 2004 12:50:01 -0400 (EDT) Message-Id: <4.3.2.7.2.20040416124804.02aa3778@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Apr 2004 12:49:58 -0400 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=1.1 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Subject: [dhcwg] Revised charter (final) 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 a final charter for the WG, based on discussion at the WG meeting in Seoul and discussion on the mailing list. I will submit this charter to the IESG for review. - Ralph dhc WG final revised charter ---------------------------- The dhc working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCPv4 is currently a "Draft Standard" and is documented in RFC 2131 and RFC 2132. DHCPv6 is currently a "Proposed Standard" and is documented in RFC 3315. Subsequent RFCs document additional options and other enhancements to the specifications. The DHC WG is responsible for reviewing (and sometimes developing) DHCP options or other extensions (for both IPv4 and IPv6). The DHC WG is expected to review all proposed extensions to DHCP to ensure that they are consistent with the DHCP specification and other option formats, that they do not duplicate existing mechanisms, etc. The DHC WG will not (generally) be responsible for evaluating the semantic content of proposed options. The DHC WG will not adopt new proposals for extensions to DHCP as working group documents without first coordinating with other relevant working groups and determining who has the responsibility for reviewing the semantic content of an option. The DHC WG has the following main objectives: * Address security in DHCP o Develop and document security requirements for DHCP. RFC 3118 defines current security mechanisms for DHCPv4. Unfortunately, RFC 3118 has neither been implemented nor deployed to date. Specific issues to be considered include: - Improved key management and scalability - Security for messages passed between relay agents and servers - Threats of DoS attacks through DHCPFORCERENEW - The increased usage of DHC on unsecured (e.g., wireless) and public LANs - The need for clients to be able to authenticate servers, without simultaneously requiring client authentication by the server. o Develop and document a roadmap of any new documents or protocols needed to meet the security requirements for DHCP * Write an analysis of the DHCP specification, including RFC 2131, RFC 2132 and other RFCs defining additional options, which identifies ambiguities, contradictory specifications and other obstacles to development of interoperable implementations. Recommend a process for resolving identified problems and incorporating the resolutions into the DHCP specification. * 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. 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 (RFC 2131, RFC 2132, RFC 3315 and subsequent RFCs) do not explicitly explain how a dual-stack host uses DHCP to obtain configuration settings for both IP stacks. * 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. The DHCPv6 specification in RFC 3315 includes a mechanism through which clients can obtain other configuration information without obtaining an address or addresses. This mechanisms is sometimes called "stateless DHCPv6" and is specified in RFC 3736. RFC 3315 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. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Apr 16 13:39: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 NAA23550; Fri, 16 Apr 2004 13:39:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEX7F-0000Bu-Gm; Fri, 16 Apr 2004 13:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEWw4-00055s-Kd for dhcwg@optimus.ietf.org; Fri, 16 Apr 2004 13:15:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22644 for ; Fri, 16 Apr 2004 13:15:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEWw2-0005Lb-Kr for dhcwg@ietf.org; Fri, 16 Apr 2004 13:15:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEWvH-0005Hk-00 for dhcwg@ietf.org; Fri, 16 Apr 2004 13:14:39 -0400 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 1BEWun-0005C0-00 for dhcwg@ietf.org; Fri, 16 Apr 2004 13:14:09 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 16 Apr 2004 09:23:13 +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 i3GHDb7t001679 for ; Fri, 16 Apr 2004 10:13:37 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.168]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHQ78031; Fri, 16 Apr 2004 13:13:36 -0400 (EDT) Message-Id: <4.3.2.7.2.20040416131324.02a67ab0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Apr 2004 13:13:34 -0400 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] New 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: , At the dhc WG meeting in Seoul, the WG expressed interest in taking on the following documents as dhc WG work items, pending revision of the WG charter to cover the areas of work addressed by the documents. Now that the WG has agreed to a revised charter that includes the appropriate charter items, we can confirm that there is consensus for the WG to take on the documents. So, please review the following documents: Renumbering Requirements for Stateless DHCPv6 Lifetime Option for DHCPv6 IPv4 and IPv6 Dual-Stack Issues for DHCPv6 and respond to the WG mailing list with comments and indicate whether you agree or disagree that the WG should accept the documents as work items. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Apr 16 16:13: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 QAA03948; Fri, 16 Apr 2004 16:13:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEZBI-0005tj-3D; Fri, 16 Apr 2004 15:39:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEZ8N-0004z7-De for dhcwg@optimus.ietf.org; Fri, 16 Apr 2004 15:36:19 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00954; Fri, 16 Apr 2004 15:36:17 -0400 (EDT) Message-Id: <200404161936.PAA00954@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 16 Apr 2004 15:36:16 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dna-ipv4-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 : Detection of Network Attachment (DNA) in IPv4 Author(s) : B. Aboba Filename : draft-ietf-dhc-dna-ipv4-07.txt Pages : 17 Date : 2004-4-16 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 document synthesizes experience garnered over the years in the deployment of hosts supporting ARP, DHCP and Link-Local IPv4 addresses. A procedure is specified for detection of network attachment in order to better accommodate mobile hosts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-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-dna-ipv4-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-4-16154442.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dna-ipv4-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dna-ipv4-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-16154442.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 Apr 16 17:21:53 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 RAA11070; Fri, 16 Apr 2004 17:21:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEafv-0003TE-Ey; Fri, 16 Apr 2004 17:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaXe-0000qZ-3z for dhcwg@optimus.ietf.org; Fri, 16 Apr 2004 17:06:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09950 for ; Fri, 16 Apr 2004 17:06:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEaXb-0001px-Jf for dhcwg@ietf.org; Fri, 16 Apr 2004 17:06:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEaUw-0001ZS-00 for dhcwg@ietf.org; Fri, 16 Apr 2004 17:03:42 -0400 Received: from smtp812.mail.sc5.yahoo.com ([66.163.170.82]) by ietf-mx with smtp (Exim 4.12) id 1BEaTj-0001OR-00 for dhcwg@ietf.org; Fri, 16 Apr 2004 17:02:27 -0400 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.116.97 with login) by smtp812.mail.sc5.yahoo.com with SMTP; 16 Apr 2004 21:02:27 -0000 Reply-To: From: "Richard Barr Hibbs" To: "Dhcwg" Date: Fri, 16 Apr 2004 14:10:29 -0700 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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] I-D ACTION:draft-hibbs-dhc-changes-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: , Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Proposed Changes to the Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Author(s) : R. Hibbs Filename : draft-hibbs-dhc-changes-01.txt Pages : 7 Date : 2004-4-14 This memo describes the requirements of Internet-Drafts proposing changes to the Dynamic Host Configuration Protocol for IPv4 (DHCPv4). These requirements specifically cover documentation expected whenever message formats or client state transitions are modified. Changes from the "-00" version of this draft include changing all occurrences of the mnemonic "DHCP" to "DHCPv4" for clarity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hibbs-dhc-changes- 01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-hibbs-dhc-changes-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-hibbs-dhc-changes-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. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 19 04:36: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 EAA25990; Mon, 19 Apr 2004 04:36:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFU5r-0000z5-7z; Mon, 19 Apr 2004 04:25:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFTrd-0006fT-AA for dhcwg@optimus.ietf.org; Mon, 19 Apr 2004 04:10:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24463 for ; Mon, 19 Apr 2004 04:10:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFTrY-0005RR-Ma for dhcwg@ietf.org; Mon, 19 Apr 2004 04:10:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFTqb-0005FM-00 for dhcwg@ietf.org; Mon, 19 Apr 2004 04:09:45 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BFTqJ-00053B-00 for dhcwg@ietf.org; Mon, 19 Apr 2004 04:09:27 -0400 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 i3J88p9j078429 for ; Mon, 19 Apr 2004 10:08:52 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i3J7xGgr077731 for ; Mon, 19 Apr 2004 09:59:16 +0200 (CEST) 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 i3J7xF9h077730; Mon, 19 Apr 2004 09:59:16 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 641E711ECA5; Mon, 19 Apr 2004 09:59:14 +0200 (CEST) Date: Mon, 19 Apr 2004 09:59:09 +0200 From: Martin Stiemerling To: Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] New dhc WG work items Message-ID: <2147483647.1082368749@[10.1.1.109]> In-Reply-To: <4.3.2.7.2.20040416131324.02a67ab0@flask.cisco.com> References: <4.3.2.7.2.20040416131324.02a67ab0@flask.cisco.com> X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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.1 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, Please see comments inline. Martin --On Freitag, 16. April 2004 13:13 Uhr -0400 Ralph Droms wrote: | At the dhc WG meeting in Seoul, the WG expressed interest in taking on the | following documents as dhc WG work items, pending revision of the WG | charter | to cover the areas of work addressed by the documents. | | Now that the WG has agreed to a revised charter that includes the | appropriate charter items, we can confirm that there is consensus for the | WG | to take on the documents. So, please review the following documents: | | Renumbering Requirements for Stateless DHCPv6 | | | Lifetime Option for DHCPv6 | Those two documents are OK to go for WG documents. | | IPv4 and IPv6 Dual-Stack Issues for DHCPv6 | Following the discussion at the last meeting in Seoul, I do not see that this document is currently ready to get a WG draft. Many issues are open and the discussions have shown that for instance (from the minutes): "[...] kre remarked that title is all wrong; draft really discusses problem of accepting configuration from multiple interfaces. [...]" Probably it is better to take another revision and afterwards decided again. | | and respond to the WG mailing list with comments and indicate whether you | agree or disagree that the WG should accept the documents as work items. | | - 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 Apr 19 11:58: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 LAA18457; Mon, 19 Apr 2004 11:58:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFb22-0007dU-Sh; Mon, 19 Apr 2004 11:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFatN-0005LW-FO for dhcwg@optimus.ietf.org; Mon, 19 Apr 2004 11:41:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17474 for ; Mon, 19 Apr 2004 11:41:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFatM-0005VR-AG for dhcwg@ietf.org; Mon, 19 Apr 2004 11:41:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFasO-0005Gl-00 for dhcwg@ietf.org; Mon, 19 Apr 2004 11:40:05 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1BFarR-00051F-00 for dhcwg@ietf.org; Mon, 19 Apr 2004 11:39:05 -0400 Received: from [69.136.112.90] (pcp08419874pcs.orovly01.az.comcast.net [69.136.112.90]) by toccata.fugue.com (Postfix) with ESMTP id E96421D0DEE; Mon, 19 Apr 2004 10:30:37 -0500 (CDT) In-Reply-To: <2147483647.1082368749@[10.1.1.109]> References: <4.3.2.7.2.20040416131324.02a67ab0@flask.cisco.com> <2147483647.1082368749@[10.1.1.109]> Mime-Version: 1.0 (Apple Message framework v613) 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] New dhc WG work items Date: Mon, 19 Apr 2004 08:39:00 -0700 To: Martin Stiemerling 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 Apr 19, 2004, at 12:59 AM, Martin Stiemerling wrote: > Probably it is better to take another revision and afterwards decided > again. It was generally agreed that there was work to do. Taking it on as a wg item would allow us to do that work. Taking it on as a wg item doesn't mean it's done and ready for last call! So I'm in favor of taking this on as a work item, and also the other two drafts. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 20 11:22: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 LAA25004; Tue, 20 Apr 2004 11:22:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwlJ-0002Tf-44; Tue, 20 Apr 2004 11:02:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwcb-0007bE-V7 for dhcwg@optimus.ietf.org; Tue, 20 Apr 2004 10:53:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23160 for ; Tue, 20 Apr 2004 10:53:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwcZ-0000JO-Bt for dhcwg@ietf.org; Tue, 20 Apr 2004 10:53:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwbn-000032-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 10:52:24 -0400 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 1BFwb0-0007Y8-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 10:51:34 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 20 Apr 2004 07:01:24 +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 i3KEoo8k006461; Tue, 20 Apr 2004 07:50:58 -0700 (PDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHS53353; Tue, 20 Apr 2004 10:50:50 -0400 (EDT) From: "Bernie Volz" To: "'Ralph Droms'" , Subject: RE: [dhcwg] New dhc WG work items Date: Tue, 20 Apr 2004 10:50:49 -0400 Organization: Cisco Message-ID: <001201c426e6$df0de5a0$d0412ca1@amer.cisco.com> 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.5709 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 In-Reply-To: <4.3.2.7.2.20040416131324.02a67ab0@flask.cisco.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 Hi: I'm in favor of taking on these drafts, though somewhat hesitant = regarding the dual stack issues since I think this is a wider issue than just DHCP = - as there could be dual stack issues with manual configuration or configuration through other protocols (such as PPP, RADIUS, ...). I also suggest that this work be called something like "DHCP Dual-Stack Issues" = or "Interaction of DHCPv4 and DHCPv6 [on Dual-Stack Hosts]". A complete = review could even suggest new options for DHCPv4? And, should this work even consider the issue of multiple administrative domains - such as VPNs and = the like and the complexity that those add, which is something that is only = know at the client. - Bernie > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On=20 > Behalf Of Ralph Droms > Sent: Friday, April 16, 2004 1:14 PM > To: dhcwg@ietf.org > Subject: [dhcwg] New dhc WG work items >=20 >=20 > At the dhc WG meeting in Seoul, the WG expressed interest in=20 > taking on the following documents as dhc WG work items,=20 > pending revision of the WG charter to cover the areas of work=20 > addressed by the documents. >=20 > Now that the WG has agreed to a revised charter that includes=20 > the appropriate charter items, we can confirm that there is=20 > consensus for the WG to take on the documents. So, please=20 > review the following documents: >=20 > Renumbering Requirements for Stateless DHCPv6 > >=20 > Lifetime Option for DHCPv6 > >=20 > IPv4 and IPv6 Dual-Stack Issues for DHCPv6 > >=20 > and respond to the WG mailing list with comments and indicate=20 > whether you agree or disagree that the WG should accept the=20 > documents as work items. >=20 > - Ralph=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 20 11:32: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 LAA26142; Tue, 20 Apr 2004 11:32:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwlR-0002Wc-M9; Tue, 20 Apr 2004 11:02:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFweP-0008Ds-FF for dhcwg@optimus.ietf.org; Tue, 20 Apr 2004 10:55:05 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23237; Tue, 20 Apr 2004 10:55:01 -0400 (EDT) Message-Id: <200404201455.KAA23237@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 20 Apr 2004 10:55:01 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-rapid-commit-opt-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: , --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, et al. Filename : draft-ietf-dhc-rapid-commit-opt-02.txt Pages : 11 Date : 2004-4-19 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-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-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-dhc-rapid-commit-opt-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. --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-4-20111630.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-rapid-commit-opt-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-rapid-commit-opt-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-20111630.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 Apr 20 12:12: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 MAA00292; Tue, 20 Apr 2004 12:12:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxeH-0007Tn-V5; Tue, 20 Apr 2004 11:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwnK-0003Y2-Ud for dhcwg@optimus.ietf.org; Tue, 20 Apr 2004 11:04:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23977 for ; Tue, 20 Apr 2004 11:04:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwnI-0003PG-8q for dhcwg@ietf.org; Tue, 20 Apr 2004 11:04:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwmW-00038c-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 11:03:29 -0400 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 1BFwlX-0002ca-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 11:02:27 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 20 Apr 2004 07:12:16 +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 i3KF1r7v009419 for ; Tue, 20 Apr 2004 08:01:55 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-104.cisco.com [10.86.240.104]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHS54420; Tue, 20 Apr 2004 11:01:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20040420103705.01fa7e50@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Apr 2004 11:01:43 -0400 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Results of WG last call on draft-ietf-dhc-3315id-for-v4 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: , draft-ietf-dhc-3315id-for-v4 did not pass WG last call. Barr Hibbs raised the issue of creating a new DHCP option for the new client identifier. Bernie Volz responded, http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg03389.html , and I infer from Barr's message http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg03478.html that he now supports using the existing option 61 for the new client identifier. Barr also raised the issue of folding the definition of the new identifier into the revision of RFC 2131 and RFC 2132. Bernie and Ted Lemon responded, http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg03426.html and http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg03440.html, and I infer from Barr's message http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg03478.html that he now supports moving forward with the new client identifier independent of any revision of RFC 2131 and RFC 2132. I asked about an example of a client identifier constructed according to this draft, http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg03413.html Finally, Barr provided some editorial corrections and suggestions, http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg03478.html and http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg03479.html So, we'll wait for a revision of the draft to be published and then conduct another WG last call. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 20 12: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 MAA00974; Tue, 20 Apr 2004 12:19:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxfL-0007gH-MO; Tue, 20 Apr 2004 12:00:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwzn-0007du-Vj for dhcwg@optimus.ietf.org; Tue, 20 Apr 2004 11:17:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24659 for ; Tue, 20 Apr 2004 11:17:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwzn-00070P-3A for dhcwg@ietf.org; Tue, 20 Apr 2004 11:17:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwys-0006kh-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 11:16:15 -0400 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 1BFwyV-0006SL-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 11:15:51 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 20 Apr 2004 07:25:41 +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 i3KFFG7v029903; Tue, 20 Apr 2004 08:15:19 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-104.cisco.com [10.86.240.104]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHS55665; Tue, 20 Apr 2004 11:15:15 -0400 (EDT) Message-Id: <4.3.2.7.2.20040420110742.01f91588@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Apr 2004 11:15:12 -0400 To: dhcwg@ietf.org From: Ralph Droms Cc: ksenthil@india.hp.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.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Results of WG last call on draft-ietf-dhc-proxyserver-opt 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: , draft-ietf-dhc-proxyserver-opt did not pass WG last call. Ted Lemon and Bernie Volz made substantive suggestions about the syntax of the option, http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg03397.html and http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg03450.html Ted, S. Daniel Park and I all made editorial changes and suggestions, in Ted's earlier message, http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg03466.html and http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg03399.html We need to complete discussion of the substantive suggestions and then we will conduct another WG last call on the revised draft. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 20 12: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 MAA01689; Tue, 20 Apr 2004 12:36:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxhD-0008Tm-SQ; Tue, 20 Apr 2004 12:02:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFx6X-0001qX-Tc for dhcwg@optimus.ietf.org; Tue, 20 Apr 2004 11:24:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25091 for ; Tue, 20 Apr 2004 11:24:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFx6X-00018h-07 for dhcwg@ietf.org; Tue, 20 Apr 2004 11:24:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFx5T-0000pf-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 11:23:04 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BFx4P-0000JP-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 11:21:57 -0400 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 i3KFLOhE018202 for ; Tue, 20 Apr 2004 08:21:24 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-104.cisco.com [10.86.240.104]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHS56324; Tue, 20 Apr 2004 11:21:23 -0400 (EDT) Message-Id: <4.3.2.7.2.20040420111554.01f9f660@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Apr 2004 11:19:52 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 In-Reply-To: References: <4.3.2.7.2.20040403072041.029964c8@flask.cisco.com> <4.3.2.7.2.20040403072041.029964c8@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=1.3 required=5.0 tests=AWL,OPT_HEADER 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: , Ted and I both made the same suggestion about carrying a list of servers in one instance of the suboption, rather than multiple instances of the same suboption each carrying one server. Is this change acceptable to the WG (please respond yes or no)? - Ralph At 12:56 PM 4/7/2004 -0500, Ted Lemon wrote: >I have a bunch of suggested changes to this draft, which fall into three >categories: > >1. A single change to the protocol itself. >2. Editorial changes - I think there was some extra text in this draft >explaining proxy servers that isn't needed, and generate questions during >the IESG review, so I'm suggesting that it be deleted. >3. Copyediting. There were some minor spelling and grammatical errors. > >The change to the protocol is that it currently specifies an encapsulation >of suboptions, like option 82, but allows for the appearance of multiple >suboptions, which is different than the behavior specified for handling >options in RFC3396. This is not a huge problem, but it probably requires >additional code in DHCP servers and clients that isn't necessary, so I'd >suggest changing it so that if you want to specify multiple proxy servers >for the same protocol, you should just list more than one IP address/port >tuple in the suboption for that protocol. > >I've enclosed a diff for all the changes. > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 20 12:37:08 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 MAA01726; Tue, 20 Apr 2004 12:37:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxhE-0008VE-DO; Tue, 20 Apr 2004 12:02:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFx6Y-0001qZ-KH for dhcwg@optimus.ietf.org; Tue, 20 Apr 2004 11:24:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25094 for ; Tue, 20 Apr 2004 11:24:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFx6X-00018o-N5 for dhcwg@ietf.org; Tue, 20 Apr 2004 11:24:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFx5U-0000po-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 11:23:05 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BFx4P-0000JQ-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 11:21:58 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 20 Apr 2004 08:22:31 -0700 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 i3KFLPhE018215; Tue, 20 Apr 2004 08:21:25 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-104.cisco.com [10.86.240.104]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHS56325; Tue, 20 Apr 2004 11:21:23 -0400 (EDT) Message-Id: <4.3.2.7.2.20040420112046.02f506d0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Apr 2004 11:21:21 -0400 To: From: Ralph Droms Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 Cc: In-Reply-To: <002d01c420b6$ee4c96f0$d0412ca1@amer.cisco.com> 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=1.3 required=5.0 tests=AWL,OPT_HEADER 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 made a suggestion about the syntax of the option. Any comment from the WG? - Ralph At 01:52 PM 4/12/2004 -0400, Bernie Volz wrote: >Perhaps this has been discussed in the past and discarded, but what >about removing the need for yet-another-list? If the option where >changed not to use sub-options at all but instead carried tuples of: > 2-octets of well-known protocol number > 4-octets of proxy server internet address > 2-octets of proxy server port number >The option length would then be multiples of 8 bytes. > >For example: > Option Header: TBD-option-code,24-bytes > Proxy for HTTP: 80,http-proxy-server-1,8080 > Proxy for HTTP: 80,http-proxy-server-2,8080 > Proxy for FTP: 21,ftp-proxy-server-1,21 > >This avoids the need for future protocols to have an enumeration and the >current "getservicename" calls can be used to find the port numbers. > >Otherwise, I recommend moving this draft forward. > >- Bernie >-----Original Message----- >From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of >Ted Lemon >Sent: Wednesday, April 07, 2004 1:57 PM >To: dhcwg@ietf.org >Subject: Re: [dhcwg] dhc WG last call on >draft-ietf-dhc-proxyserver-opt-00 > > >I have a bunch of suggested changes to this draft, which fall into >three categories: > >1. A single change to the protocol itself. >2. Editorial changes - I think there was some extra text in this draft >explaining proxy servers that isn't needed, and generate questions >during the IESG review, so I'm suggesting that it be deleted. >3. Copyediting. There were some minor spelling and grammatical errors. > >The change to the protocol is that it currently specifies an >encapsulation of suboptions, like option 82, but allows for the >appearance of multiple suboptions, which is different than the behavior >specified for handling options in RFC3396. This is not a huge >problem, but it probably requires additional code in DHCP servers and >clients that isn't necessary, so I'd suggest changing it so that if you >want to specify multiple proxy servers for the same protocol, you >should just list more than one IP address/port tuple in the suboption >for that protocol. > >I've enclosed a diff for all the changes. > > > >_______________________________________________ >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 Apr 20 12:41: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 MAA02254; Tue, 20 Apr 2004 12:41:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxnB-00035m-L7; Tue, 20 Apr 2004 12:08:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxBv-0004Ky-GF for dhcwg@optimus.ietf.org; Tue, 20 Apr 2004 11:29:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25642 for ; Tue, 20 Apr 2004 11:29:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFxBu-0002zf-HV for dhcwg@ietf.org; Tue, 20 Apr 2004 11:29:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFxAG-0002Kl-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 11:28:01 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BFx8g-0001ZG-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 11:26:22 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 20 Apr 2004 08:24:45 -0700 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 i3KFPowb027280 for ; Tue, 20 Apr 2004 11:25:51 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-104.cisco.com [10.86.240.104]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHS56739; Tue, 20 Apr 2004 11:25:50 -0400 (EDT) Message-Id: <4.3.2.7.2.20040420112239.01f61868@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Apr 2004 11:25:33 -0400 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Results of WG last call on draft-ietf-dhc-rapid-commit-opt 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: , draft-ietf-dhc-rapid-commit-opt did not pass WG last call. A new revision of the document, draft-ietf-dhc-rapid-commit-opt-02.txt, has been published in response to the comments received during the WG last call. I'll start a WG last call on this new revision. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 20 12:43:03 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 MAA02429; Tue, 20 Apr 2004 12:43:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxna-0003Ib-97; Tue, 20 Apr 2004 12:08:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxFF-0006g1-PP for dhcwg@optimus.ietf.org; Tue, 20 Apr 2004 11:33:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26190 for ; Tue, 20 Apr 2004 11:33:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFxFE-0004IW-Q9 for dhcwg@ietf.org; Tue, 20 Apr 2004 11:33:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFxEH-0003yN-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 11:32:09 -0400 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 1BFxD9-0003KM-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 11:30:59 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 20 Apr 2004 07:42:01 +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 i3KFUR7t000815 for ; Tue, 20 Apr 2004 08:30:27 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-104.cisco.com [10.86.240.104]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHS57195; Tue, 20 Apr 2004 11:30:26 -0400 (EDT) Message-Id: <4.3.2.7.2.20040420112559.02f34e78@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Apr 2004 11:30:23 -0400 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt 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 announces a WG last call on "Rapid Commit Option for DHCPv4" . The last call will conclude at 5PM EDT on 4/30/2004. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Note that this is a new last call on this document, which was revised after comment recieved during the WG last call that ended on 4/15/2004. draft-ietf-dhc-rapid-commit-opt 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. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-rapid-commit-opt-02.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 20 12:45: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 MAA02748; Tue, 20 Apr 2004 12:45:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxoB-0003oM-Em; Tue, 20 Apr 2004 12:09:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxMD-0001pT-AS for dhcwg@optimus.ietf.org; Tue, 20 Apr 2004 11:40:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26857 for ; Tue, 20 Apr 2004 11:40:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFxMC-0006iT-8m for dhcwg@ietf.org; Tue, 20 Apr 2004 11:40:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFxKs-00066T-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 11:38:59 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BFxJX-0005Rg-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 11:37:35 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 20 Apr 2004 08:49:27 -0700 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 i3KFb3AH005856 for ; Tue, 20 Apr 2004 11:37:03 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-104.cisco.com [10.86.240.104]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHS57834; Tue, 20 Apr 2004 11:37:02 -0400 (EDT) Message-Id: <4.3.2.7.2.20040420113501.02f34e78@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Apr 2004 11:36:59 -0400 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.2 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Subject: [dhcwg] Results of WG last call on draft-ietf-dhc-reclassify-options 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: , draft-ietf-dhc-reclassify-options passed WG last call, but requires some minor editorial changes http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg03411.html Once a revised version of the I-D has been published, it will be sent to the IESG for review. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 20 12:49:13 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 MAA03179; Tue, 20 Apr 2004 12:49:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxp8-0004Gz-Pv; Tue, 20 Apr 2004 12:10:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxTO-0004yX-LY for dhcwg@optimus.ietf.org; Tue, 20 Apr 2004 11:47:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27511 for ; Tue, 20 Apr 2004 11:47:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFxTN-0001Ic-HX for dhcwg@ietf.org; Tue, 20 Apr 2004 11:47:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFxQq-0000Vr-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 11:45:09 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BFxPZ-00002V-01 for dhcwg@ietf.org; Tue, 20 Apr 2004 11:43:49 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BFxLH-0005LJ-9Q for dhcwg@ietf.org; Tue, 20 Apr 2004 11:39:23 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 20 Apr 2004 08:51:13 -0700 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 i3KFcnwb000783 for ; Tue, 20 Apr 2004 11:38:49 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-104.cisco.com [10.86.240.104]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHS57988; Tue, 20 Apr 2004 11:38:48 -0400 (EDT) Message-Id: <4.3.2.7.2.20040420113756.01f61868@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Apr 2004 11:38:45 -0400 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Results of WG last call on draft-ietf-dhc-vendor 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: , draft-ietf-dhc-vendor passed WG last call, but requires some minor editorial changes http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg03412.html Once a revised version of the I-D has been published, it will be sent to the IESG for review. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 20 12:55:03 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 MAA03707; Tue, 20 Apr 2004 12:55:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFyGz-00019N-Ns; Tue, 20 Apr 2004 12:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxhZ-00009n-Cw for dhcwg@optimus.ietf.org; Tue, 20 Apr 2004 12:02:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29048 for ; Tue, 20 Apr 2004 12:02:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFxhY-00062n-4p for dhcwg@ietf.org; Tue, 20 Apr 2004 12:02:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFxfh-0005Ow-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 12:00:29 -0400 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 1BFxem-0004yF-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 11:59:32 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 20 Apr 2004 08:10: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 i3KFwx8k012929 for ; Tue, 20 Apr 2004 08:59:00 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-104.cisco.com [10.86.240.104]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHS59855; Tue, 20 Apr 2004 11:58:58 -0400 (EDT) Message-Id: <4.3.2.7.2.20040420115100.01f91588@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Apr 2004 11:58:56 -0400 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Question about 3315id-for-v4 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 seems one of the motivations for draft-ietf-dhc-3315id-for-v4 is to specify a way in which a dual-stack host can use the same identifier in DHCPv4 and in DHCPv6. A uniform identifier for both versions of DHCP would be useful in the DHCID RR when detecting and reconciling DNS name clashes. So, is there consensus that draft-ietf-dhc-3315id-for-v4 should be designed to support the consistent identification of a host in a DHCID RR regardless of whether the host uses DHCPv4 or DHCPv6? If the answer is yes, how can that consistent identification be achieved? I think the identifier in the latest revision of draft-ietf-dhc-3315id-for-v4 could be used, if the DHCP server and the client agree to use only the DUID in the DHCID RR. However, I think it would be better to avoid requiring the DHCPv4 server to parse the 3315id-for-v4 client identifier for use in the DHCID RR. Is there some other way in which the use of the DHCID RR can be defined to avoid requiring the parsing of any client identification (either DHCpv4 or DHCPv6)? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 20 13:08:05 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 NAA04636; Tue, 20 Apr 2004 13:08:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFySh-0006x1-Vk; Tue, 20 Apr 2004 12:51:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxqx-0005C9-HN for dhcwg@optimus.ietf.org; Tue, 20 Apr 2004 12:12:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00135 for ; Tue, 20 Apr 2004 12:12:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFxqw-0001S9-5r for dhcwg@ietf.org; Tue, 20 Apr 2004 12:12:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFxpw-00016v-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 12:11:05 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BFxot-0000Ts-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 12:09:59 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 20 Apr 2004 09:21:52 -0700 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 i3KG9Qwd007924 for ; Tue, 20 Apr 2004 12:09:28 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-104.cisco.com [10.86.240.104]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHS60770; Tue, 20 Apr 2004 12:09:25 -0400 (EDT) Message-Id: <4.3.2.7.2.20040420120119.02f474d0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Apr 2004 12:09:24 -0400 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Design team for automated address management 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 the WG meeting in Seoul, I promised to "arrange for a discussion to reconcile this option with DHCPv6 prefix delegation and earlier ODAP work." I would like to identify a small team of volunteers to take up this issue and review draft-shen-dhc-block-alloc-01, earlier work on ODAP and DHCPv6 prefix delegation. The result of this review will include an analysis of the similarities and differences between the various proposals, a description of the automated address management problem space and recommendations for work on DHCP required in that space. I would like to get at least one author from each of the drafts on the design team and, of course, other volunteers are welcome. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 20 13:13:19 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 NAA05041; Tue, 20 Apr 2004 13:13:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFyTo-0007bo-1E; Tue, 20 Apr 2004 12:52:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFy4c-0002dM-Cs for dhcwg@optimus.ietf.org; Tue, 20 Apr 2004 12:26:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01252 for ; Tue, 20 Apr 2004 12:26:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFy4a-0005Tc-S4 for dhcwg@ietf.org; Tue, 20 Apr 2004 12:26:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFy3f-0005Dd-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 12:25:16 -0400 Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx with esmtp (Exim 4.12) id 1BFy3D-0004xZ-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 12:24:48 -0400 Received: from homerdmz.incognito.com ([206.172.52.116] helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 4.30) id 1BFy2i-00068Z-PK for dhcwg@ietf.org; Tue, 20 Apr 2004 09:24:16 -0700 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Apr 2004 09:23:46 -0700 Message-ID: From: "Kostur, Andre" To: dhcwg@ietf.org Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-rapid-commit-opt-02.txt Date: Tue, 20 Apr 2004 09:23:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C426F3.DA5B9540" X-Spam-Score: 2.0 (++) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 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_01C426F3.DA5B9540 Content-Type: text/plain; charset="iso-8859-1" Items to note: Section 3.1: The first step says "The client broadcasts a DHCPDISCOVER mess on its local physical." Physical what? Interface, I presume? The second step talks about using the client identifier or chaddr plus assigned network address as the identifier for the lease. I believe this puts it in conflict with RFC 2131 (which talks about using a subnet address, not necessarily the address of the lease), and RFC 3046 which adds in the Remote ID. I believe that this draft should probably reference RFC 3046 on this topic. Come to think of it, it looks like this draft re-iterates a bunch of wording that is already in RFC 2131 (such as: When allocating a new address, servers SHOULD check that the offered network address is not already in use; e.g., the server may probe the offered address with an ICMP Echo Request. Servers SHOULD be implemented so that network administrators MAY choose to disable probes of newly allocated addresses. ). Does this really need to be restated, or would a reference back to the "normal" DHCP behaviour as defined in RFC 2131 be sufficient? Section 4: This states that a client SHOULD include this option in a discover if it's prepared to perform the DISCOVER-ACK exchange. Shouldn't that be a MUST since there is that if clause at the end? ------_=_NextPart_001_01C426F3.DA5B9540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] I-D = ACTION:draft-ietf-dhc-rapid-commit-opt-02.txt

Items to note:

Section 3.1:

The first step says "The client broadcasts a = DHCPDISCOVER mess on its local physical."  Physical = what?  Interface, I presume?

The second step talks about using the client = identifier or chaddr plus assigned network address as the identifier = for the lease.  I believe this puts it in conflict with RFC 2131 = (which talks about using a subnet address, not necessarily the address = of the lease), and RFC 3046 which adds in the Remote ID.  I = believe that this draft should probably reference RFC 3046 on this = topic.

Come to think of it, it looks like this draft = re-iterates a bunch of wording that is already in RFC 2131 (such = as:

           = When allocating a new address, servers SHOULD check that = the    
           = offered network address is not already in use; e.g., the
           = server may probe the offered address with an ICMP Echo Request.  =
           = Servers SHOULD be implemented so that network administrators
           = MAY choose to disable probes of newly allocated addresses.

).  Does this really need to be restated, or = would a reference back to the "normal" DHCP behaviour as = defined in RFC 2131 be sufficient?


Section 4:

This states that a client SHOULD include this option = in a discover if it's prepared to perform the DISCOVER-ACK = exchange.  Shouldn't that be a MUST since there is that if clause = at the end?


------_=_NextPart_001_01C426F3.DA5B9540-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 20 13: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 NAA07456; Tue, 20 Apr 2004 13:41:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFz1X-0005L0-Hd; Tue, 20 Apr 2004 13:27:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFyn6-0008M9-F7 for dhcwg@optimus.ietf.org; Tue, 20 Apr 2004 13:12:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04999 for ; Tue, 20 Apr 2004 13:12:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFyn4-00017X-I2 for dhcwg@ietf.org; Tue, 20 Apr 2004 13:12:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFym7-00015W-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 13:11:12 -0400 Received: from maillnx-us112.fmr.com ([192.223.198.27]) by ietf-mx with esmtp (Exim 4.12) id 1BFylY-00010u-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 13:10:36 -0400 Received: from virmro111nts.fmr.com (VIRMRO111NTS.fmr.com [172.26.5.99]) by maillnx-us112.fmr.com (Switch-3.1.2/Switch-3.1.0) with SMTP id i3KH9xZE017797 for ; Tue, 20 Apr 2004 13:09:59 -0400 Received: from MSGMROCLA2WIN.dmn1.fmr.com ([172.26.31.91]) by MSGMROIM01WIN.DMN1.FMR.COM with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Apr 2004 13:09:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 content-class: urn:content-classes:message Subject: RE: [dhcwg] Question about 3315id-for-v4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Apr 2004 13:09:55 -0400 Message-ID: Thread-Topic: [dhcwg] Question about 3315id-for-v4 Thread-Index: AcQm+C+dX3kQf2ENRKWOZMnPdYW+7QAAa9YA From: "Situ, Kevin" To: X-OriginalArrivalTime: 20 Apr 2004 17:09:58.0765 (UTC) FILETIME=[4F51B1D0:01C426FA] 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 We are running into an issue with multiple vendors using option 43. We use Lucent DHCP that do not support vender class ID in option 43, which only can store the value without Vendor class ID. We have a work around by having multiples scope in the subnet, But we try to use one template and one scope. Does any have any suggestion Thanks Kevin =20 -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com]=20 Sent: Tuesday, April 20, 2004 11:59 AM To: dhcwg@ietf.org Subject: [dhcwg] Question about 3315id-for-v4 It seems one of the motivations for draft-ietf-dhc-3315id-for-v4 is to specify a way in which a dual-stack host can use the same identifier in DHCPv4 and in DHCPv6. A uniform identifier for both versions of DHCP would be useful in the DHCID RR when detecting and reconciling DNS name clashes. So, is there consensus that draft-ietf-dhc-3315id-for-v4 should be designed to support the consistent identification of a host in a DHCID RR regardless of whether the host uses DHCPv4 or DHCPv6? If the answer is yes, how can that consistent identification be achieved? I think the identifier in the latest revision of draft-ietf-dhc-3315id-for-v4 could be used, if the DHCP server and the client agree to use only the DUID in the DHCID RR. However, I think it would be better to avoid requiring the DHCPv4 server to parse the 3315id-for-v4 client identifier for use in the DHCID RR. Is there some other way in which the use of the DHCID RR can be defined to avoid requiring the parsing of any client identification (either DHCpv4 or DHCPv6)? - 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 Apr 20 14:57:23 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 OAA12644; Tue, 20 Apr 2004 14:57:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG09B-0008Nv-Sn; Tue, 20 Apr 2004 14:39:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG02V-0005cf-J3 for dhcwg@optimus.ietf.org; Tue, 20 Apr 2004 14:32:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10533 for ; Tue, 20 Apr 2004 14:32:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG02S-0006MY-RL for dhcwg@ietf.org; Tue, 20 Apr 2004 14:32:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG01V-0006IY-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 14:31:09 -0400 Received: from smtp814.mail.sc5.yahoo.com ([66.163.170.84]) by ietf-mx with smtp (Exim 4.12) id 1BG00a-0006Ea-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 14:30:13 -0400 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.89.34 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 20 Apr 2004 18:22:20 -0000 Reply-To: From: "Richard Barr Hibbs" To: Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 Date: Tue, 20 Apr 2004 11:30:35 -0700 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: <4.3.2.7.2.20040420111554.01f9f660@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 I support the proposed change to carry a list or servers rather than multiple instances of a single-server-only suboption --Barr > -----Original Message----- > From: Ralph Droms > Sent: Tuesday, 20 April 2004 08:20 > > Ted and I both made the same suggestion about > carrying a list of servers in > one instance of the suboption, rather than > multiple instances of the same > suboption each carrying one server. Is this > change acceptable to the WG > (please respond yes or no)? > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 20 15:09: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 PAA14280; Tue, 20 Apr 2004 15:09:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG0Te-00080d-K9; Tue, 20 Apr 2004 15:00:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG0CE-00012u-Ja for dhcwg@optimus.ietf.org; Tue, 20 Apr 2004 14:42:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11670 for ; Tue, 20 Apr 2004 14:42:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG0CB-0007En-K1 for dhcwg@ietf.org; Tue, 20 Apr 2004 14:42:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG0Ba-0007CS-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 14:41:34 -0400 Received: from smtp812.mail.sc5.yahoo.com ([66.163.170.82]) by ietf-mx with smtp (Exim 4.12) id 1BG0Az-00078I-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 14:40:57 -0400 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.89.34 with login) by smtp812.mail.sc5.yahoo.com with SMTP; 20 Apr 2004 18:40:56 -0000 Reply-To: From: "Richard Barr Hibbs" To: Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 Date: Tue, 20 Apr 2004 11:49:11 -0700 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: <4.3.2.7.2.20040420112046.02f506d0@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 I agree with Bernie's suggestion, but hope that the final text includes BOTH a drawing of the proposed option AND one or two examples. --Barr example: 1 2 4 8 10 +------+-----+----------+----- ... ------+---------+--- ... |Option| Len |Proto Nbr.|Proxy IP Address|Port Nbr.| +------+-----+----------+----- ... ------+---------+--- ... /<-------- First Proxy Tuple -------->/ Option Header: option-code: (TBD), Len: 24 (octets) Proxy for HTTP: Proto: 80, Proxy IP: http-proxy-server-1, Port: 8080 Proxy for HTTP: Proto: 80, Proxy IP: http-proxy-server-2, Port: 8080 Proxy for FTP: Proto: 21, Proxy IP: ftp-proxy-server-1, Port: 21 > -----Original Message----- > From: Ralph Droms > Sent: Tuesday, 20 April 2004 08:21 > > Bernie made a suggestion about the syntax of the > option. Any comment from > the WG? > > - Ralph > > At 01:52 PM 4/12/2004 -0400, Bernie Volz wrote: > >Perhaps this has been discussed in the past and > discarded, but what > >about removing the need for yet-another-list? If > the option where > >changed not to use sub-options at all but > instead carried tuples of: > > 2-octets of well-known protocol number > > 4-octets of proxy server internet address > > 2-octets of proxy server port number > >The option length would then be multiples of 8 bytes. > > > >For example: > > Option Header: TBD-option-code,24-bytes > > Proxy for HTTP: 80,http-proxy-server-1,8080 > > Proxy for HTTP: 80,http-proxy-server-2,8080 > > Proxy for FTP: 21,ftp-proxy-server-1,21 > > > >This avoids the need for future protocols to > have an enumeration and the > >current "getservicename" calls can be used to > find the port numbers. > > > >Otherwise, I recommend moving this draft forward. > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 20 21:03: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 VAA12572; Tue, 20 Apr 2004 21:03:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG5xB-0004Fy-AO; Tue, 20 Apr 2004 20:51:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG5ju-0006lL-QV for dhcwg@optimus.ietf.org; Tue, 20 Apr 2004 20:37:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11227 for ; Tue, 20 Apr 2004 20:37:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG5js-0002Yr-Ih for dhcwg@ietf.org; Tue, 20 Apr 2004 20:37:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG5iw-0002Uc-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 20:36:22 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1BG5i6-0002QU-00 for dhcwg@ietf.org; Tue, 20 Apr 2004 20:35:30 -0400 Received: from [69.136.112.90] (pcp08419874pcs.orovly01.az.comcast.net [69.136.112.90]) by toccata.fugue.com (Postfix) with ESMTP id DDF6F1B238D; Tue, 20 Apr 2004 19:26:51 -0500 (CDT) In-Reply-To: <4.3.2.7.2.20040420115100.01f91588@flask.cisco.com> References: <4.3.2.7.2.20040420115100.01f91588@flask.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: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] Question about 3315id-for-v4 Date: Tue, 20 Apr 2004 17:35:28 -0700 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 Apr 20, 2004, at 8:58 AM, Ralph Droms wrote: > Is there some other way in which the use of the DHCID RR can be > defined to avoid requiring the parsing of any client identification > (either > DHCpv4 or DHCPv6)? No. During the last call both Bernie and Barr expressed a wish that we could do this, and we discussed and rejected a method for doing this. The problem is that the only way to make it so the server doesn't have to parse the identifier is to add an additional identifier option, and if we do that, clients supporting the new identifier style will not interoperate with servers that do not in some cases. The only objection I can think of to the server parsing the client identifier option is that we have historically said the client identifier is opaque. However, there is a good reason to break with this tradition, and I don't see how doing so would create an interoperability problem. So if we try to keep this tradition, we break interoperability with old servers. If we break this tradition, we do not. So I think we have to use the IAID+DUID form of the client identifier option, and not add a separate IAID option. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Apr 21 01:25: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 BAA25392; Wed, 21 Apr 2004 01:25:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGA6Z-0006Nz-8q; Wed, 21 Apr 2004 01:17:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGA53-0005Ye-KZ for dhcwg@optimus.ietf.org; Wed, 21 Apr 2004 01:15:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24522 for ; Wed, 21 Apr 2004 01:15:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGA50-0004Sq-EU for dhcwg@ietf.org; Wed, 21 Apr 2004 01:15:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGA43-0004MN-00 for dhcwg@ietf.org; Wed, 21 Apr 2004 01:14:27 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BGA3C-0004CD-00 for dhcwg@ietf.org; Wed, 21 Apr 2004 01:13:34 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWI00M0H95SLI@mailout2.samsung.com> for dhcwg@ietf.org; Wed, 21 Apr 2004 14:13:04 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWI00AX895LJH@mailout2.samsung.com> for dhcwg@ietf.org; Wed, 21 Apr 2004 14:12:57 +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 <0HWI00GYS95L5K@mmp2.samsung.com> for dhcwg@ietf.org; Wed, 21 Apr 2004 14:12:57 +0900 (KST) Date: Wed, 21 Apr 2004 14:13:23 +0900 From: "S. Daniel Park" Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-rapid-commit-opt-02.txt In-reply-to: To: "'Kostur, Andre'" , dhcwg@ietf.org Message-id: <012601c4275f$5ecee410$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 Thanks Kostur and see my inline comments. >Section 3.1: >The first step says "The client broadcasts a DHCPDISCOVER >mess on its local physical." Physical what? Interface, I presume? To sync current term. we wrote " physical subnet " I guess subnet is omitted... sorry. >The second step talks about using the client identifier or chaddr >plus assigned network address as the identifier for the lease. >I believe this puts it in conflict with RFC 2131 (which talks about using >a subnet address, not necessarily the address of the lease), and >RFC 3046 which adds in the Remote ID. I believe that this draft should >probably reference RFC 3046 on this topic. I am not sure why it occurs confliction with RFC2131. >Come to think of it, it looks like this draft re-iterates a bunch of wording >that is already in RFC 2131... >Does this really need to be restated, or would a reference back to the >"normal" DHCP behaviour as defined in RFC 2131 be sufficient? As stated, I also think it is not significant issue. I am citing Bernie's response as below: I'm pretty neutral on the issue of whether or not to copy text from 2131. When we eventually revise 2131, I believe we'd incorporate this capability (rapid commit) into the revised 2131 text so I don't think it is a significant issue. We could remove the text for those steps where there are no differences (such as step 4 - only) and replace it with "see RFC 2131". But, this may just increase the confusion (or at least complexity of following the flow)? Thought ? or we still need to remove it ? >Section 4: >This states that a client SHOULD include this option in a discover if it's >prepared to perform the DISCOVER-ACK exchange. Shouldn't that be >a MUST since there is that if clause at the end? I thought MUST is too hard, but I have no hard stance to replace it if we agree that. - 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 Apr 21 01:44: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 BAA26788; Wed, 21 Apr 2004 01:44:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGARr-0007XB-8F; Wed, 21 Apr 2004 01:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGAIs-0002xv-KQ for dhcwg@optimus.ietf.org; Wed, 21 Apr 2004 01:29:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26014 for ; Wed, 21 Apr 2004 01:29:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGAIp-0006TJ-IP for dhcwg@ietf.org; Wed, 21 Apr 2004 01:29:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGAI0-0006N2-00 for dhcwg@ietf.org; Wed, 21 Apr 2004 01:28:53 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BGAHS-0006DG-00 for dhcwg@ietf.org; Wed, 21 Apr 2004 01:28:18 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWI007209SBZW@mailout1.samsung.com> for dhcwg@ietf.org; Wed, 21 Apr 2004 14:26:35 +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 <0HWI00LFT9S7A7@mailout1.samsung.com> for dhcwg@ietf.org; Wed, 21 Apr 2004 14:26:31 +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 <0HWI00BQR9S7CE@mmp2.samsung.com> for dhcwg@ietf.org; Wed, 21 Apr 2004 14:26:31 +0900 (KST) Date: Wed, 21 Apr 2004 14:26:57 +0900 From: "S. Daniel Park" To: dhcwg@ietf.org Cc: v6ops@ops.ietf.org Message-id: <012701c42761$43d9ba70$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_yOcJ9pIJDsTS2vNwr0CVGQ)" 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.4 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_FONT_FACE_BAD,HTML_MESSAGE autolearn=no version=2.60 Subject: [dhcwg] [I-D ACTION]:draft-daniel-dhc-ipv6in4-opt-03.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: , This is a multi-part message in MIME format. --Boundary_(ID_yOcJ9pIJDsTS2vNwr0CVGQ) Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT fyi... comments/feedbacks are highly welcome. - Daniel (Soohong Daniel Park) - Mobile Platform Laboratory, SAMSUNG Electronics. > -----Original Message----- > From: i-d-announce-admin@ietf.org > [mailto:i-d-announce-admin@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Wednesday, April 21, 2004 4:49 AM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-daniel-dhc-ipv6in4-opt-03.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : DHCP Option for Configuring IPv6-in-IPv4 Tunnels > Author(s) : P. Kim, S. Park > Filename : draft-daniel-dhc-ipv6in4-opt-03.txt > Pages : 8 > Date : 2004-4-20 > > This document provides a mechanism by which the DHCPv4 > servers can > provide information about the configured IPv6-in-IPv4 tunnel > end-points. The IPv4/IPv6 dual-stack nodes can use this > information to set up a configured tunnel to the tunnel end-point > to obtain IPv6 connectivity. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-03.txt --Boundary_(ID_yOcJ9pIJDsTS2vNwr0CVGQ) Content-type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7BIT [I-D ACTION]:draft-daniel-dhc-ipv6in4-opt-03.txt

fyi... comments/feedbacks are highly welcome.


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

> -----Original Message-----
> From: i-d-announce-admin@ietf.org
> [mailto:i-d-announce-admin@ietf.org] On Behalf Of
> Internet-Drafts@ietf.org
> Sent: Wednesday, April 21, 2004 4:49 AM
> To: i-d-announce@ietf.org
> Subject: I-D ACTION:draft-daniel-dhc-ipv6in4-opt-03.txt
>
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
>
>
>       Title           : DHCP Option for Configuring IPv6-in-IPv4 Tunnels
>       Author(s)       : P. Kim, S. Park
>       Filename        : draft-daniel-dhc-ipv6in4-opt-03.txt
>       Pages           : 8
>       Date            : 2004-4-20
>      
> This document provides a mechanism by which the DHCPv4
> servers can    
> provide information about the configured IPv6-in-IPv4 tunnel    
> end-points.  The IPv4/IPv6 dual-stack nodes can use this    
> information to set up a configured tunnel to the tunnel end-point    
> to obtain IPv6 connectivity.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-03.txt


--Boundary_(ID_yOcJ9pIJDsTS2vNwr0CVGQ)-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Apr 21 02:12: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 CAA10858; Wed, 21 Apr 2004 02:12:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGAsv-00056h-N4; Wed, 21 Apr 2004 02:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGAoZ-0000za-I8 for dhcwg@optimus.ietf.org; Wed, 21 Apr 2004 02:02:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00626 for ; Wed, 21 Apr 2004 02:02:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGAoW-0002X4-31 for dhcwg@ietf.org; Wed, 21 Apr 2004 02:02:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGAnb-0002Sc-00 for dhcwg@ietf.org; Wed, 21 Apr 2004 02:01:32 -0400 Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx with esmtp (Exim 4.12) id 1BGAmq-0002IF-00 for dhcwg@ietf.org; Wed, 21 Apr 2004 02:00:44 -0400 Received: from homerdmz.incognito.com ([206.172.52.116] helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 4.30) id 1BGAmL-0005g9-30; Tue, 20 Apr 2004 23:00:13 -0700 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Apr 2004 22:59:42 -0700 Message-ID: From: "Kostur, Andre" To: "'S. Daniel Park'" , "Kostur, Andre" , dhcwg@ietf.org Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-rapid-commit-opt-02.txt Date: Tue, 20 Apr 2004 22:59:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42765.D283CE10" X-Spam-Score: 2.0 (++) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 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_01C42765.D283CE10 Content-Type: text/plain; charset="iso-8859-1" > From: S. Daniel Park [mailto:soohong.park@samsung.com] > Sent: Tuesday, April 20, 2004 10:13 PM > To: 'Kostur, Andre'; dhcwg@ietf.org > Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-rapid-commit-opt-02.txt > > Thanks Kostur and see my inline comments. > > >The second step talks about using the client identifier or chaddr > >plus assigned network address as the identifier for the lease. > >I believe this puts it in conflict with RFC 2131 (which talks about > using > >a subnet address, not necessarily the address of the lease), and > >RFC 3046 which adds in the Remote ID. I believe that this > draft should > > >probably reference RFC 3046 on this topic. > > I am not sure why it occurs confliction with RFC2131. Maybe "conflict" is too strong of a word... I guess to me specifying the lease address implies that a unique identifier (ClientID/CHADDR + RemoteID) may have multiple leases on the same subnet. By specifying a subnet address instead, this implies that a unique identifier may have only one lease on a subnet. If a client wished to have multiple leases on the same subnet, then it would need to mutate it's client ID, and thus effectively becoming a distinct client (from the DHCP server's point of view). > >Section 4: > >This states that a client SHOULD include this option in a discover if > it's > >prepared to perform the DISCOVER-ACK exchange. Shouldn't that be > >a MUST since there is that if clause at the end? > > I thought MUST is too hard, but I have no hard stance to replace it > if we agree that. I think that SHOULD is too loose in this case. The statement is modified by saying "if the device is prepared to perform the DISCOVER-ACK exchange". With a SHOULD this would imply that the device may be prepared to perform the DISCOVER-ACK exchange, but isn't required to supply the Rapid Commit option. Which would lead to the question of how else would the device inform the server that it is prepared to do Rapid Commit? ------_=_NextPart_001_01C42765.D283CE10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] I-D = ACTION:draft-ietf-dhc-rapid-commit-opt-02.txt

> From: S. Daniel Park [mailto:soohong.park@samsung.com= ]
> Sent: Tuesday, April 20, 2004 10:13 PM
> To: 'Kostur, Andre'; dhcwg@ietf.org
> Subject: RE: [dhcwg] I-D = ACTION:draft-ietf-dhc-rapid-commit-opt-02.txt
> 
> Thanks Kostur and see my inline = comments.
>
> >The second step talks about using the = client identifier or chaddr
> >plus assigned network address as the = identifier for the lease. 
> >I believe this puts it in conflict with RFC = 2131 (which talks about
> using
> >a subnet address, not necessarily the = address of the lease), and
> >RFC 3046 which adds in the Remote ID.  = I believe that this
> draft should
>
> >probably reference RFC 3046 on this = topic.
>
> I am not sure why it occurs confliction with = RFC2131.

Maybe "conflict" is too strong of a = word...

I guess to me specifying the lease address implies = that a unique identifier (ClientID/CHADDR + RemoteID) may have multiple = leases on the same subnet.  By specifying a subnet address = instead, this implies that a unique identifier may have only one lease = on a subnet.  If a client wished to have multiple leases on the = same subnet, then it would need to mutate it's client ID, and thus = effectively becoming a distinct client (from the DHCP server's point of = view).

> >Section 4:
> >This states that a client SHOULD include = this option in a discover if
> it's
> >prepared to perform the DISCOVER-ACK = exchange.  Shouldn't that be
> >a MUST since there is that if clause at the = end?
>
> I thought MUST is too hard, but I have no hard = stance to replace it
> if we agree that.

I think that SHOULD is too loose in this case.  = The statement is modified by saying "if the device is prepared to = perform the DISCOVER-ACK exchange".  With a SHOULD this would = imply that the device may be prepared to perform the DISCOVER-ACK = exchange, but isn't required to supply the Rapid Commit option.  = Which would lead to the question of how else would the device inform = the server that it is prepared to do Rapid Commit?

------_=_NextPart_001_01C42765.D283CE10-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Apr 21 04:01: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 EAA02231; Wed, 21 Apr 2004 04:01:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGCXX-0003FI-5q; Wed, 21 Apr 2004 03:53:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGCW8-0002TZ-O2 for dhcwg@optimus.ietf.org; Wed, 21 Apr 2004 03:51:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01630 for ; Wed, 21 Apr 2004 03:51:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGCW6-0006tf-86 for dhcwg@ietf.org; Wed, 21 Apr 2004 03:51:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGCV6-0006oi-00 for dhcwg@ietf.org; Wed, 21 Apr 2004 03:50:32 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BGCUG-0006ev-00 for dhcwg@ietf.org; Wed, 21 Apr 2004 03:49:40 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWI00704GDY9J@mailout2.samsung.com> for dhcwg@ietf.org; Wed, 21 Apr 2004 16:49:10 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWI002UYGDXLC@mailout2.samsung.com> for dhcwg@ietf.org; Wed, 21 Apr 2004 16:49:09 +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 <0HWI00MCDGDX0X@mmp2.samsung.com> for dhcwg@ietf.org; Wed, 21 Apr 2004 16:49:09 +0900 (KST) Date: Wed, 21 Apr 2004 16:49:35 +0900 From: "S. Daniel Park" Subject: RE: [dhcwg] Design team for automated address management In-reply-to: <4.3.2.7.2.20040420120119.02f474d0@flask.cisco.com> To: "'Ralph Droms'" , dhcwg@ietf.org Message-id: <015301c42775$30eb2430$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 am not sure why we need this option to allocate its required address block in the IPv6 address architecture. It seems to be duplicated with current prefix delegation mechanism (3633) because a requesting router can set its preference for the size of the prefix to be delegated in this mechanism. I don't have a hard stance on the IPv4 at this stage. Particularly, I myself am so curious whether it is a real dhc charter scope or not because it applies to router configuration rather than host configuration as ralph stated previous. I am also suffering from this assumption on the router tunnel auto-configuration. Nevertheless, DT's analysis would be useful for me (us ?) Thanks. - 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: Wednesday, April 21, 2004 1:09 AM > To: dhcwg@ietf.org > Subject: [dhcwg] Design team for automated address management > > > At the WG meeting in Seoul, I promised to "arrange for a discussion to > reconcile this option with DHCPv6 prefix delegation and > earlier ODAP work." > I would like to identify a small team of volunteers to take > up this issue > and review draft-shen-dhc-block-alloc-01, earlier work on > ODAP and DHCPv6 > prefix delegation. The result of this review will include an > analysis of > the similarities and differences between the various proposals, a > description of the automated address management problem space and > recommendations for work on DHCP required in that space. > > I would like to get at least one author from each of the drafts on the > design team and, of course, other volunteers are welcome. > > - 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 Apr 21 10:06: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 KAA22476; Wed, 21 Apr 2004 10:06:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGI8u-0004Mv-7V; Wed, 21 Apr 2004 09:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGI2A-0000rZ-5j for dhcwg@optimus.ietf.org; Wed, 21 Apr 2004 09:45:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20718 for ; Wed, 21 Apr 2004 09:44:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGI28-0000Qz-7N for dhcwg@ietf.org; Wed, 21 Apr 2004 09:45:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGI1E-0000Hv-00 for dhcwg@ietf.org; Wed, 21 Apr 2004 09:44:05 -0400 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 1BGI0b-00007J-00 for dhcwg@ietf.org; Wed, 21 Apr 2004 09:43:25 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 21 Apr 2004 05:53:26 +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 i3LDgq8k010586 for ; Wed, 21 Apr 2004 06:42:52 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-60.cisco.com [10.86.240.60]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHT30598; Wed, 21 Apr 2004 09:42:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20040421091104.02710008@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 21 Apr 2004 09:42:49 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] Question about 3315id-for-v4 In-Reply-To: References: <4.3.2.7.2.20040420115100.01f91588@flask.cisco.com> <4.3.2.7.2.20040420115100.01f91588@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.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: , Ted - I looked back through the last call e-mail and found the specifics: www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg03389.html www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg03283.html www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg03284.html I missed the subtleties of the discussion; others might have, too, as the discussion was pretty brief. Now that we see the tie-in between 3315id-for-v4 and the DHCID RR, I think we need to get a more definitive statement about how a server users 3315id-for-v4 identifiers with the DHCID RR. We also need to get a more detailed evaluation of the backward-compatibility issues, if 3315id-for-v4 will require changes in server behavior (for parsing the IAID+DUID). Are other server vendors comfortable with the effect of 3315id-for-v4 on currently deployed servers? - Ralph At 05:35 PM 4/20/2004 -0700, Ted Lemon wrote: >On Apr 20, 2004, at 8:58 AM, Ralph Droms wrote: >>Is there some other way in which the use of the DHCID RR can be >>defined to avoid requiring the parsing of any client identification (either >>DHCpv4 or DHCPv6)? > >No. During the last call both Bernie and Barr expressed a wish that we >could do this, and we discussed and rejected a method for doing >this. The problem is that the only way to make it so the server doesn't >have to parse the identifier is to add an additional identifier option, >and if we do that, clients supporting the new identifier style will not >interoperate with servers that do not in some cases. > >The only objection I can think of to the server parsing the client >identifier option is that we have historically said the client identifier >is opaque. However, there is a good reason to break with this tradition, >and I don't see how doing so would create an interoperability >problem. So if we try to keep this tradition, we break interoperability >with old servers. If we break this tradition, we do not. So I think we >have to use the IAID+DUID form of the client identifier option, and not >add a separate IAID option. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Apr 21 18:45: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 SAA26740; Wed, 21 Apr 2004 18:45:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQ7B-0000YR-TO; Wed, 21 Apr 2004 18:22:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGPgh-0007Gc-0F for dhcwg@optimus.ietf.org; Wed, 21 Apr 2004 17:55:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19766 for ; Wed, 21 Apr 2004 17:55:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGPge-0001hL-6Y for dhcwg@ietf.org; Wed, 21 Apr 2004 17:55:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGPfs-0001Vs-00 for dhcwg@ietf.org; Wed, 21 Apr 2004 17:54:33 -0400 Received: from smtp812.mail.sc5.yahoo.com ([66.163.170.82]) by ietf-mx with smtp (Exim 4.12) id 1BGPfI-0001JT-00 for dhcwg@ietf.org; Wed, 21 Apr 2004 17:53:56 -0400 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.89.34 with login) by smtp812.mail.sc5.yahoo.com with SMTP; 21 Apr 2004 21:53:53 -0000 Reply-To: From: "Richard Barr Hibbs" To: "Dhcwg" Subject: FW: [dhcwg] Question about 3315id-for-v4 Date: Wed, 21 Apr 2004 15:02:12 -0700 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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 -----Original Message----- From: Richard Barr Hibbs [mailto:rbhibbs@pacbell.net] Sent: Wednesday, 21 April 2004 09:13 To: Ted Lemon Subject: RE: [dhcwg] Question about 3315id-for-v4 comments in-line --Barr > -----Original Message----- > From: Ted Lemon > Sent: Tuesday, 20 April 2004 17:35 > > On Apr 20, 2004, at 8:58 AM, Ralph Droms wrote: > > Is there some other way in which the use of the > > DHCID RR can be defined to avoid requiring the > > parsing of any client identification (either > > DHCpv4 or DHCPv6)? > > No. During the last call both Bernie and Barr > expressed a wish that we could do this, and we > discussed and rejected a method for doing this. > The problem is that the only way to make it so > the server doesn't have to parse the identifier > is to add an additional identifier option, and > if we do that, clients supporting the new > identifier style will not interoperate with > servers that do not in some cases. > ...I'll take another look at the DHCID RR, the DNS update I-D, and the proposed change to the client identifier today to see if we may have been too quick to reject proposed solutions. > The only objection I can think of to the server > parsing the client identifier option is that we > have historically said the client identifier is > opaque. However, there is a good reason to > break with this tradition, and I don't see how > doing so would create an interoperability > problem. So if we try to keep this tradition, > we break interoperability with old servers. If > we break this tradition, we do not. So I > think we have to use the IAID+DUID form of the > client identifier option, and not add a separate > IAID option. > ...I don't believe that we have ever identified a good reason why the client identifier MUST be an opaque value, save that it does simplify one aspect of interoperability: if the value is opaque, it can be changed by the client for any reason, especially convenience, without worrying how a server will react to the change. So, if I may restate the issue, "Do we want a client identifier that contains no data that can be processed by the server to glean any information about the client, such as additional qualification similar to vendor or user class information, or not?" There are really two competing philosophies here: (1) keep the size of the packet (and number of options sent/received) as small as possible by avoiding duplicated or overlapping data; and (2) maintain absolute clarity as to the purpose and interpretation of every option by having one and only one use for each. Both are valid perspectives, but I lean a bit towards the second because of the Law of Unintended Consequences, which in this case would suggest that changing the client identifier will have some as yet unforeseen complication. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Apr 21 20:14:11 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 UAA03353; Wed, 21 Apr 2004 20:14:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGRj7-00035T-Qo; Wed, 21 Apr 2004 20:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDQwz-00011n-U2 for dhcwg@optimus.ietf.org; Tue, 13 Apr 2004 12:39:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20824 for ; Tue, 13 Apr 2004 12:39:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDQww-0001Bf-00 for dhcwg@ietf.org; Tue, 13 Apr 2004 12:39:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDQtl-0000it-00 for dhcwg@ietf.org; Tue, 13 Apr 2004 12:36:34 -0400 Received: from cpcdms-out.usace.army.mil ([140.194.233.246] helo=dms-lcc-cpc-m3.dms.usace.army.mil) by ietf-mx with esmtp (Exim 4.12) id 1BDQp8-0000KH-00 for dhcwg@ietf.org; Tue, 13 Apr 2004 12:31:46 -0400 Received: by dms-lcc-cpc-m3.dms.usace.army.mil with Internet Mail Service (5.5.2657.72) id <26HMX3M8>; Tue, 13 Apr 2004 11:31:09 -0500 Message-ID: From: "Carr, Robert J SAJ Contractor" To: "'dhcwg@ietf.org'" Date: Tue, 13 Apr 2004 11:30:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42174.602AE1C4" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 Subject: [dhcwg] Security help needed 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_01C42174.602AE1C4 Content-Type: text/plain; charset="iso-8859-1" Is there any way to verify a mac address before handing out a DHCP Address in a Windows 2003 environment WITHOUT using reservations???? thanks, Rob Robert Carr Network Administration (Contractor - (CNI) Datacom Sciences) US Army Corp of Engineers / Jacksonville District 701 San Marco Blvd - IM Dept Jacksonville, FL 32207 Ph: (904)232-1625 Cell (904) 673-9645 ------_=_NextPart_001_01C42174.602AE1C4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Security help needed

Is there any way to verify a mac = address before handing out a DHCP Address in a Windows 2003 environment = WITHOUT using reservations????

thanks,

Rob


Robert Carr
Network Administration
(Contractor - (CNI) Datacom = Sciences)
US Army Corp of Engineers / = Jacksonville District
701 San Marco Blvd - IM Dept
Jacksonville, FL 32207
Ph: (904)232-1625 Cell (904) = 673-9645

------_=_NextPart_001_01C42174.602AE1C4-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Apr 21 20:15:55 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 UAA03546; Wed, 21 Apr 2004 20:15:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGRj8-00035l-Bi; Wed, 21 Apr 2004 20:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVpx-0001IZ-N0 for dhcwg@optimus.ietf.org; Tue, 13 Apr 2004 17:52:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11894 for ; Tue, 13 Apr 2004 17:52:53 -0400 (EDT) From: Eric.Luce@nominum.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDVps-0007Jf-00 for dhcwg@ietf.org; Tue, 13 Apr 2004 17:52:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDVad-0005ey-00 for dhcwg@ietf.org; Tue, 13 Apr 2004 17:37:08 -0400 Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx with esmtp (Exim 4.12) id 1BDVO9-0004PU-00 for dhcwg@ietf.org; Tue, 13 Apr 2004 17:24:13 -0400 Received: from yomiko.ddns.nominum.com (dhcp-146.engr.nominum.com [128.177.194.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shell-ng.nominum.com (Postfix) with ESMTP id 7B97656849 for ; Tue, 13 Apr 2004 14:23:35 -0700 (PDT) Received: from yomiko.ddns.nominum.com (localhost [127.0.0.1]) by yomiko.ddns.nominum.com (8.12.10/8.12.10) with ESMTP id i3DLNYtX002319 for ; Tue, 13 Apr 2004 14:23:34 -0700 (PDT) (envelope-from scanner@yomiko.ddns.nominum.com) Message-Id: <200404132123.i3DLNYtX002319@yomiko.ddns.nominum.com> To: dhcwg@ietf.org X-URI: http://www.nominum.com/ X-Face: 6K2.ZvQgQ.NDQLIx.1pW(xRu*">:}&PX-Ad_!!?wU7H4L"wF"0xEwYu=8Or0V+=5?-eO1XL 7-0Hom/|]B2C7Uznyol-NVnvEk:+sod^MyB4v4qVpPDemr;b@pZdRSXu.'Gm^t0?2l,j[&t.kbc[UW x6Lz^e$K$W Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 13 Apr 2004 14:23:34 -0700 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] Reviewing draft-lemon-dhcpv4-to-v6-id-trans.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: , I reviewed the draft draft-lemon-dhcpv4-to-v6-id-trans.txt and I came across three points that either need slight clarification or wording. With these changes I support the advancement of this draft: A minor nit, in "3.1. Do Nothing" there is a small typo: - Once the old lease has expired, these resources (particularly the - client's domain name) will be available for any client to claim. Should probably be: - Once the old lease has expired, these resources (particularly the client's domain name) will be available for any client to claim. In section "3.2. Propose New Identifier in DHCPREQUEST" It discusses sending a DHCPRELEASE followed by DHCPDISCOVER to reclaim the resources associated with the old lease when attempting to move the lease to the new client identifier. Since there is no confirmation on a DHCPRELEASE suceedint and it may take some small but not insignificant time for the server to release the resources (in particular the ddns update) specifying a small delay between the DHCPRELEASE and the DHCPDISCOVER is probably a good idea. In section "3.4. Probe for Leases Under Old Identifier" Where it says "Leases that are acquired during the probing process are never _added_ to the list of leases needing to be converted" perhaps; get rid of the emphasized 'added' and say: "Leases that are acquired during the probing process MUST NOT be added to the list of leases needing to be converted." This makes it a rule requiring explicit conformance. Also, where it says: "The advantage is that it is completely compatible with the solution proposed in section 3.2, which means that the implementor has the option of implementing either proposal" -- you mean implementor of the server, right? The implementation of the client is obviously different between 3.2 and 3.4. -- Scanner (scanner@nominum.com) Nominum, Inc. | www.nominum.com | +1.650.779.6035 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Apr 21 20:25:09 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 UAA04404; Wed, 21 Apr 2004 20:25:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGRwe-0003Pv-U7; Wed, 21 Apr 2004 20:20:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDpyv-0001Gz-Dt for dhcwg@optimus.ietf.org; Wed, 14 Apr 2004 15:23:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17532 for ; Wed, 14 Apr 2004 15:23:31 -0400 (EDT) From: Eric.Luce@nominum.com Message-Id: <200404141923.PAA17532@ietf.org> Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDpyt-0001ql-00 for dhcwg@ietf.org; Wed, 14 Apr 2004 15:23:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDpxs-0001lg-00 for dhcwg@ietf.org; Wed, 14 Apr 2004 15:22:28 -0400 Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx with esmtp (Exim 4.12) id 1BDpwp-0001aT-00 for dhcwg@ietf.org; Wed, 14 Apr 2004 15:21:23 -0400 Received: from shell-ng.nominum.com (localhost.nominum.com [127.0.0.1]) by shell-ng.nominum.com (Postfix) with ESMTP id 9A6B256852 for ; Wed, 14 Apr 2004 12:20:52 -0700 (PDT) To: dhcwg@ietf.org X-URI: http://www.nominum.com/ X-Face: 6K2.ZvQgQ.NDQLIx.1pW(xRu*">:}&PX-Ad_!!?wU7H4L"wF"0xEwYu=8Or0V+=5?-eO1XL 7-0Hom/|]B2C7Uznyol-NVnvEk:+sod^MyB4v4qVpPDemr;b@pZdRSXu.'Gm^t0?2l,j[&t.kbc[UW x6Lz^e$K$W Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 13 Apr 2004 14:23:34 -0700 Resent-To: dhcwg@ietf.org Resent-Date: Wed, 14 Apr 2004 12:20:52 -0700 Resent-From: Eric Scanner Luce Resent-Message-Id: <20040414192052.9A6B256852@shell-ng.nominum.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.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Subject: [dhcwg] Reviewing draft-lemon-dhcpv4-to-v6-id-trans.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: , I reviewed the draft draft-lemon-dhcpv4-to-v6-id-trans.txt and I came across three points that either need slight clarification or wording. With these changes I support the advancement of this draft: A minor nit, in "3.1. Do Nothing" there is a small typo: - Once the old lease has expired, these resources (particularly the - client's domain name) will be available for any client to claim. Should probably be: - Once the old lease has expired, these resources (particularly the client's domain name) will be available for any client to claim. In section "3.2. Propose New Identifier in DHCPREQUEST" It discusses sending a DHCPRELEASE followed by DHCPDISCOVER to reclaim the resources associated with the old lease when attempting to move the lease to the new client identifier. Since there is no confirmation on a DHCPRELEASE suceedint and it may take some small but not insignificant time for the server to release the resources (in particular the ddns update) specifying a small delay between the DHCPRELEASE and the DHCPDISCOVER is probably a good idea. In section "3.4. Probe for Leases Under Old Identifier" Where it says "Leases that are acquired during the probing process are never _added_ to the list of leases needing to be converted" perhaps; get rid of the emphasized 'added' and say: "Leases that are acquired during the probing process MUST NOT be added to the list of leases needing to be converted." This makes it a rule requiring explicit conformance. Also, where it says: "The advantage is that it is completely compatible with the solution proposed in section 3.2, which means that the implementor has the option of implementing either proposal" -- you mean implementor of the server, right? The implementation of the client is obviously different between 3.2 and 3.4. -- Scanner (scanner@nominum.com) Nominum, Inc. | www.nominum.com | +1.650.779.6035 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Apr 21 20:26: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 UAA04539; Wed, 21 Apr 2004 20:26:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGRwf-0003QD-Jq; Wed, 21 Apr 2004 20:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDs2m-0002NU-4Q for dhcwg@optimus.ietf.org; Wed, 14 Apr 2004 17:35:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28934 for ; Wed, 14 Apr 2004 17:35:36 -0400 (EDT) From: Eric.Luce@nominum.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDs2j-0006e4-00 for dhcwg@ietf.org; Wed, 14 Apr 2004 17:35:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDs1q-0006c6-00 for dhcwg@ietf.org; Wed, 14 Apr 2004 17:34:43 -0400 Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx with esmtp (Exim 4.12) id 1BDs16-0006X1-00 for dhcwg@ietf.org; Wed, 14 Apr 2004 17:33:57 -0400 Received: from shell-ng.nominum.com (localhost.nominum.com [127.0.0.1]) by shell-ng.nominum.com (Postfix) with ESMTP id 4DC285686D; Wed, 14 Apr 2004 14:33:26 -0700 (PDT) To: dhcwg@ietf.org Cc: ted.lemon@nominum.com X-URI: http://www.nominum.com/ X-Face: 6K2.ZvQgQ.NDQLIx.1pW(xRu*">:}&PX-Ad_!!?wU7H4L"wF"0xEwYu=8Or0V+=5?-eO1XL 7-0Hom/|]B2C7Uznyol-NVnvEk:+sod^MyB4v4qVpPDemr;b@pZdRSXu.'Gm^t0?2l,j[&t.kbc[UW x6Lz^e$K$W Date: Wed, 14 Apr 2004 14:33:26 -0700 Message-Id: <20040414213326.4DC285686D@shell-ng.nominum.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.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Subject: [dhcwg] Reviewing draft-lemon-dhcpv4-to-v6-id-trans.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: , I reviewed the draft draft-lemon-dhcpv4-to-v6-id-trans.txt and I came across three points that either need slight clarification or wording. With these changes I support the advancement of this draft: A minor nit, in "3.1. Do Nothing" there is a small typo: - Once the old lease has expired, these resources (particularly the - client's domain name) will be available for any client to claim. Should probably be: - Once the old lease has expired, these resources (particularly the client's domain name) will be available for any client to claim. In section "3.2. Propose New Identifier in DHCPREQUEST" It discusses sending a DHCPRELEASE followed by DHCPDISCOVER to reclaim the resources associated with the old lease when attempting to move the lease to the new client identifier. Since there is no confirmation on a DHCPRELEASE suceedint and it may take some small but not insignificant time for the server to release the resources (in particular the ddns update) specifying a small delay between the DHCPRELEASE and the DHCPDISCOVER is probably a good idea. In section "3.4. Probe for Leases Under Old Identifier" Where it says "Leases that are acquired during the probing process are never _added_ to the list of leases needing to be converted" perhaps; get rid of the emphasized 'added' and say: "Leases that are acquired during the probing process MUST NOT be added to the list of leases needing to be converted." This makes it a rule requiring explicit conformance. Also, where it says: "The advantage is that it is completely compatible with the solution proposed in section 3.2, which means that the implementor has the option of implementing either proposal" -- you mean implementor of the server, right? The implementation of the client is obviously different between 3.2 and 3.4. -- Scanner (scanner@nominum.com) Nominum, Inc. | www.nominum.com | +1.650.779.6035 -- Scanner (scanner@nominum.com) Nominum, Inc. | www.nominum.com | +1.650.779.6035 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Apr 21 20:31: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 UAA04899; Wed, 21 Apr 2004 20:31:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGRwg-0003QL-3o; Wed, 21 Apr 2004 20:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE2wm-0008IV-DZ for dhcwg@optimus.ietf.org; Thu, 15 Apr 2004 05:14:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12694 for ; Thu, 15 Apr 2004 05:14:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE2wj-0004ob-00 for dhcwg@ietf.org; Thu, 15 Apr 2004 05:14:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE2vi-0004jt-00 for dhcwg@ietf.org; Thu, 15 Apr 2004 05:13:06 -0400 Received: from bay7-f31.bay7.hotmail.com ([64.4.11.31] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BE2vK-0004gD-00 for dhcwg@ietf.org; Thu, 15 Apr 2004 05:12:42 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 15 Apr 2004 02:12:13 -0700 Received: from 203.123.162.82 by by7fd.bay7.hotmail.msn.com with HTTP; Thu, 15 Apr 2004 09:12:13 GMT X-Originating-IP: [203.123.162.82] X-Originating-Email: [vishweshji@hotmail.com] X-Sender: vishweshji@hotmail.com From: "vishwesh jirgale" To: dhcwg@ietf.org Date: Thu, 15 Apr 2004 09:12:13 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 15 Apr 2004 09:12:13.0791 (UTC) FILETIME=[BD9906F0:01C422C9] 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=CLICK_BELOW autolearn=no version=2.60 Subject: [dhcwg] Simple DHCP Client to get lease time 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: , Hello, Can anybody help me out with simple DHCP Client in java. I just want to query lease time given an ip/mac address. Whenever You Fall Pickup Something - Vishwesh _________________________________________________________________ Need quick cash? http://go.msnserver.com/IN/46923.asp Click here ! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Apr 21 22:31:14 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 WAA10999; Wed, 21 Apr 2004 22:31:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGTnq-0005jB-Aa; Wed, 21 Apr 2004 22:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGTkQ-00034X-U4 for dhcwg@optimus.ietf.org; Wed, 21 Apr 2004 22:15:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10409 for ; Wed, 21 Apr 2004 22:15:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGTkN-0001gD-NO for dhcwg@ietf.org; Wed, 21 Apr 2004 22:15:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGTjR-0001VP-00 for dhcwg@ietf.org; Wed, 21 Apr 2004 22:14:30 -0400 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 1BGTj0-0001Jq-00 for dhcwg@ietf.org; Wed, 21 Apr 2004 22:14:02 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 21 Apr 2004 18:25:22 +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 i3M2DUSu027283; Wed, 21 Apr 2004 19:13:30 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-2-165.cisco.com [10.86.242.165]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHT96423; Wed, 21 Apr 2004 22:13:29 -0400 (EDT) From: "Bernie Volz" To: "'S. Daniel Park'" , "'Kostur, Andre'" , Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-rapid-commit-opt-02.txt Date: Wed, 21 Apr 2004 22:13:29 -0400 Organization: Cisco Message-ID: <000a01c4280f$67482ba0$6b01a8c0@amer.cisco.com> 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.5709 In-Reply-To: <012601c4275f$5ecee410$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: 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 text in rapid-commit draft CAME from RFC 2131. It was essentially = CUT and PASTED from 2131 and then modified to include Rapid Commit related processing. So, the text in step 2 (and 4) is exactly what is in 4 in = 2131. We moved that text into step 2 because the same processing occurs for = Rapid Commit earlier. Step 4 in 2131 says "assigned network address", nothing about "subnet address". And, at the start of section 3.1 in the draft we say "The following is a revised Section 3.1 of [RFC 2131] that includes handling of the Rapid = Commit option." We don't want to revise any other processing in RFC 2131 except for = adding the Rapid Commit processing. Thanks for catching the missing "subnet" word in Step 1. If there are = any other editting erros we've made, please do let us know. But if you have issues with the text in 2131, please let Barr Hibbs know about them as = he's working to capture all the corrections that are needed in 2131. I do think the text in section 4 should use MUST as if a client WANTs to = use this and is configured to allow its use, it *MUST* send the option = otherwise it has no hope of getting the server to do Rapid Commit. So, perhaps we should can the text in Section 4 to: A client MUST include this option in a DHCPDISCOVER message=20 if the client supports and intends to perform the DHCPDISCOVER-DHCPACK message exchange described earlier. =20 Text is thanks to earlier comments by Ralph (regarding section 3 in the = 01 draft). - Bernie > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On=20 > Behalf Of S. Daniel Park > Sent: Wednesday, April 21, 2004 1:13 AM > To: 'Kostur, Andre'; dhcwg@ietf.org > Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-rapid-commit-opt-02.txt >=20 >=20 > =20 > Thanks Kostur and see my inline comments. >=20 > >Section 3.1: > >The first step says "The client broadcasts a DHCPDISCOVER=20 > >mess on its local physical." Physical what? Interface, I presume? >=20 > To sync current term. we wrote " physical subnet "=20 > I guess subnet is omitted... sorry. >=20 > >The second step talks about using the client identifier or chaddr > >plus assigned network address as the identifier for the lease. =20 > >I believe this puts it in conflict with RFC 2131 (which talks about > using > >a subnet address, not necessarily the address of the lease), and > >RFC 3046 which adds in the Remote ID. I believe that this=20 > draft should >=20 > >probably reference RFC 3046 on this topic. >=20 > I am not sure why it occurs confliction with RFC2131. >=20 > >Come to think of it, it looks like this draft re-iterates a bunch of > wording=20 > >that is already in RFC 2131... > >Does this really need to be restated, or would a reference=20 > back to the=20 > >"normal" DHCP behaviour as defined in RFC 2131 be sufficient? >=20 > As stated, I also think it is not significant issue. I am=20 > citing Bernie's response as below: >=20 > I'm pretty neutral on the issue of whether or not to copy=20 > text from 2131. When we eventually revise 2131, I believe=20 > we'd incorporate this capability (rapid commit) into the=20 > revised 2131 text so I don't think it is a significant issue.=20 > We could remove the text for those steps where there are no=20 > differences (such as step 4 - only) and replace it with "see=20 > RFC 2131". But, this may just increase the confusion (or at=20 > least complexity of following the flow)? >=20 > Thought ? or we still need to remove it ? >=20 > >Section 4: > >This states that a client SHOULD include this option in a discover if > it's=20 > >prepared to perform the DISCOVER-ACK exchange. Shouldn't that be > >a MUST since there is that if clause at the end? >=20 > I thought MUST is too hard, but I have no hard stance to=20 > replace it if we agree that. >=20 >=20 >=20 > - Daniel (Soohong Daniel Park) > - Mobile Platform Laboratory, SAMSUNG Electronics.=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Apr 22 17:58:53 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 RAA04811; Thu, 22 Apr 2004 17:58:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlvT-0006DC-5Y; Thu, 22 Apr 2004 17:40:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGkst-0005S8-Dg for dhcwg@optimus.ietf.org; Thu, 22 Apr 2004 16:33:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27466 for ; Thu, 22 Apr 2004 16:33:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGksp-0001gD-1P for dhcwg@ietf.org; Thu, 22 Apr 2004 16:33:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGkrz-0001OQ-00 for dhcwg@ietf.org; Thu, 22 Apr 2004 16:32:27 -0400 Received: from mail.nettera.net ([66.246.92.2] helo=athena.nettera.net) by ietf-mx with smtp (Exim 4.12) id 1BGkqx-0000mQ-00 for dhcwg@ietf.org; Thu, 22 Apr 2004 16:31:23 -0400 Received: (qmail 23259 invoked by uid 2520); 22 Apr 2004 20:30:55 -0000 Received: from jake@nettera.net by athena.nettera.net by uid 2020 with qmail-scanner-1.20rc3 (clamuko: 0.60. spamassassin: 2.60. Clear:RC:1:. Processed in 0.017979 secs); 22 Apr 2004 20:30:55 -0000 Received: from pool-68-237-14-21.ny325.east.verizon.net (HELO ?192.168.0.101?) (68.237.14.21) by brainvisuals.com with SMTP; 22 Apr 2004 20:30:55 -0000 User-Agent: Microsoft-Entourage/10.0.0.1309 Date: Thu, 22 Apr 2004 16:30:55 -0400 From: Jake Howerton To: Message-ID: Mime-version: 1.0 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 Subject: [dhcwg] Option 60 VCI 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 Do all clients transmit option 60? I am trying to separate devices on my network and am looking to find out if linksys and other consumer routers transmit option 60 as well as consumer and enterprise Aps like the Orinoco AP1000. I have my cable modems working with this method. If there are any other effective ways to do this, suggestions are appreciated. Jake Howerton _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Apr 22 18:50:13 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 SAA09548; Thu, 22 Apr 2004 18:50:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmez-0008EA-SV; Thu, 22 Apr 2004 18:27:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmNs-000645-Nj for dhcwg@optimus.ietf.org; Thu, 22 Apr 2004 18:09:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05987 for ; Thu, 22 Apr 2004 18:09:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmNn-0006Lj-Sc for dhcwg@ietf.org; Thu, 22 Apr 2004 18:09:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmMo-00065k-00 for dhcwg@ietf.org; Thu, 22 Apr 2004 18:08:23 -0400 Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx with esmtp (Exim 4.12) id 1BGmLo-0005am-00 for dhcwg@ietf.org; Thu, 22 Apr 2004 18:07:20 -0400 Received: from homerdmz.incognito.com ([206.172.52.116] helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 4.30) id 1BGmLJ-0006yX-Mq; Thu, 22 Apr 2004 15:06:49 -0700 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Apr 2004 15:06:19 -0700 Message-ID: From: "Kostur, Andre" To: "'Jake Howerton'" , dhcwg@ietf.org Subject: RE: [dhcwg] Option 60 VCI Date: Thu, 22 Apr 2004 15:06:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C428B6.09DB1C50" X-Spam-Score: 2.3 (++) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_30_40,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_01C428B6.09DB1C50 Content-Type: text/plain; charset="iso-8859-1" No device is _required_ to send option 60. Also, you don't mention what you're trying to accomplish by "separating your devices". > -----Original Message----- > From: Jake Howerton [mailto:jake@nettera.net] > Sent: Thursday, April 22, 2004 1:31 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Option 60 VCI > > > Do all clients transmit option 60? I am trying to separate > devices on my > network and am looking to find out if linksys and other > consumer routers > transmit option 60 as well as consumer and enterprise Aps > like the Orinoco > AP1000. I have my cable modems working with this method. If > there are any > other effective ways to do this, suggestions are appreciated. ------_=_NextPart_001_01C428B6.09DB1C50 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] Option 60 VCI

No device is _required_ to send option 60.

Also, you don't mention what you're trying to accomplish by "separating your devices".

> -----Original Message-----
> From: Jake Howerton [mailto:jake@nettera.net]
> Sent: Thursday, April 22, 2004 1:31 PM
> To: dhcwg@ietf.org
> Subject: [dhcwg] Option 60 VCI
>
>
> Do all clients transmit option 60?  I am trying to separate
> devices on my
> network and am looking to find out if linksys and other
> consumer routers
> transmit option 60 as well as consumer and enterprise Aps
> like the Orinoco
> AP1000.  I have my cable modems working with this method.  If
> there are any
> other effective ways to do this, suggestions are appreciated.

------_=_NextPart_001_01C428B6.09DB1C50-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Apr 22 19:42:08 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 TAA13078; Thu, 22 Apr 2004 19:42:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGneq-0006Sr-PE; Thu, 22 Apr 2004 19:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGnUR-0003Ai-NT for dhcwg@optimus.ietf.org; Thu, 22 Apr 2004 19:20:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11793 for ; Thu, 22 Apr 2004 19:20:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGnUO-0003QG-4Q for dhcwg@ietf.org; Thu, 22 Apr 2004 19:20:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGnTQ-0003Be-00 for dhcwg@ietf.org; Thu, 22 Apr 2004 19:19:17 -0400 Received: from mail.nettera.net ([66.246.92.2] helo=athena.nettera.net) by ietf-mx with smtp (Exim 4.12) id 1BGnSX-0002iO-00 for dhcwg@ietf.org; Thu, 22 Apr 2004 19:18:21 -0400 Received: (qmail 2084 invoked by uid 2520); 22 Apr 2004 23:17:49 -0000 Received: from jake@nettera.net by athena.nettera.net by uid 2020 with qmail-scanner-1.20rc3 (clamuko: 0.60. spamassassin: 2.60. Clear:RC:1:. Processed in 0.171485 secs); 22 Apr 2004 23:17:49 -0000 Received: from pool-68-237-14-21.ny325.east.verizon.net (HELO ?192.168.0.101?) (68.237.14.21) by greenermedia.com with SMTP; 22 Apr 2004 23:17:49 -0000 User-Agent: Microsoft-Entourage/10.0.0.1309 Date: Thu, 22 Apr 2004 19:17:47 -0400 Subject: Re: [dhcwg] Option 60 VCI From: Jake Howerton To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3165506268_1094818" 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,HTML_FONTCOLOR_BLUE, 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. --B_3165506268_1094818 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Andre, Thanks for the response. Do you know if most devices send this option or most dont? I am trying to capture the packets with ethereal but none of the devices I have at my disposal at this moment currently seem to do it. Unless I am approaching this incorrectly. Someone told me what the cable modems send so I didn't have to go through this discover process with them. My purpose is basically for controlling the network. In conjunction with firewall rules I would basically like to ban certain devices and or limit access for certain devices. This is in residential apartment buildings for instance I don't want people putting consumer wireless routers on their cable modem and opening up holes in the network. Or I want to keep access points on a different subnet so wannabe hackers cant mess with them easily from the subnet that client devices get assigned. Jake On 4/22/04 6:06 PM, "Kostur, Andre" wrote: > No device is _required_ to send option 60. > > Also, you don't mention what you're trying to accomplish by "separating your > devices". --B_3165506268_1094818 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: [dhcwg] Option 60 VCI Andre,

Thanks for the response.  Do you know if most devices send this option= or most dont?  I am trying to capture the packets with ethereal but no= ne of the devices I have at my disposal at this moment currently seem to do = it.  Unless I am approaching this incorrectly.  Someone told me wh= at the cable modems send so I didn't have to go through this discover proces= s with them.

My purpose is basically for controlling the network.  In conjunction w= ith firewall rules I would basically like to ban certain devices and or limi= t access for certain devices.  This is in residential apartment buildin= gs for instance I don't want people putting consumer wireless routers on the= ir cable modem and opening up holes in the network.  Or I want to keep = access points on a different subnet so wannabe hackers cant mess with them e= asily from the subnet that client devices get assigned.

Jake


On 4/22/04 6:06 PM, "Kostur, Andre" <= akostur@incognito.com> wrote:

No device is _requir= ed_ to send option 60.

Also, you don't mention what you're trying to accomplish by = "separating your devices".
--B_3165506268_1094818-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Apr 25 09:00:19 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 JAA26309; Sun, 25 Apr 2004 09:00:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHjBt-0008W9-Cw; Sun, 25 Apr 2004 08:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHj6z-00074N-0v for dhcwg@optimus.ietf.org; Sun, 25 Apr 2004 08:51:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26038 for ; Sun, 25 Apr 2004 08:51:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHj6x-00049x-Lh for dhcwg@ietf.org; Sun, 25 Apr 2004 08:51:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHj5y-0003up-00 for dhcwg@ietf.org; Sun, 25 Apr 2004 08:50:54 -0400 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 1BHj4v-0003U3-00 for dhcwg@ietf.org; Sun, 25 Apr 2004 08:49:49 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 25 Apr 2004 05:01:48 +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 i3PCn7WB013052 for ; Sun, 25 Apr 2004 05:49:16 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-1-20.cisco.com [10.86.240.20]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHV91298; Sun, 25 Apr 2004 08:49:06 -0400 (EDT) From: "Bernie Volz" To: Subject: RE: [dhcwg] Results of WG last call on draft-ietf-dhc-reclassify-options Date: Sun, 25 Apr 2004 08:49:06 -0400 Organization: Cisco Message-ID: <000601c42ac3$b2384d00$6501a8c0@amer.cisco.com> 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.5709 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 In-Reply-To: <4.3.2.7.2.20040420113501.02f34e78@flask.cisco.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.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID 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 just submitted the revised draft that corrects the minor editorial = changes requested: - References RFC 3679 instead of its earlier internet-draft. - Uses the IPR text from RFC 3667. - Changes first sentence in Background section per Ralph's = recommendation. - Updates author's address. - Changed "Relay Agent Option" to "Relay Agent Information Option" (this = was not requested but is appropriate since that is what the option is = called). - Split references (into Informative/Normative). It should show up in a few days. - Bernie Volz > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On=20 > Behalf Of Ralph Droms > Sent: Tuesday, April 20, 2004 11:37 AM > To: dhcwg@ietf.org > Subject: [dhcwg] Results of WG last call on=20 > draft-ietf-dhc-reclassify-options >=20 >=20 > draft-ietf-dhc-reclassify-options passed WG last call, but=20 > requires some minor editorial changes=20 > http://www1.ietf.org/mail-archive/working-groups/dhcwg/current > /msg03411.html > Once a revised version of the I-D has been published, it will=20 > be sent to the IESG for review. >=20 > - Ralph >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 26 09:58: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 JAA20902; Mon, 26 Apr 2004 09:58:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6Uk-0007Fq-Ke; Mon, 26 Apr 2004 09:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6Pr-0005Mk-4z for dhcwg@optimus.ietf.org; Mon, 26 Apr 2004 09:44:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20046 for ; Mon, 26 Apr 2004 09:44:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI6Pp-0007WJ-37 for dhcwg@ietf.org; Mon, 26 Apr 2004 09:44:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI6Or-0007UM-00 for dhcwg@ietf.org; Mon, 26 Apr 2004 09:43:57 -0400 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 1BI6OT-0007SJ-00 for dhcwg@ietf.org; Mon, 26 Apr 2004 09:43:33 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2004 05:55:44 +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 i3QDgxW9023495; Mon, 26 Apr 2004 06:42:59 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-62.cisco.com [10.86.240.62]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHW22240; Mon, 26 Apr 2004 09:42:58 -0400 (EDT) Message-Id: <4.3.2.7.2.20040426094234.02aecd38@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 26 Apr 2004 09:42:56 -0400 To: "Bernie Volz" From: Ralph Droms Subject: RE: [dhcwg] Results of WG last call on draft-ietf-dhc-reclassify-options Cc: In-Reply-To: <000601c42ac3$b2384d00$6501a8c0@amer.cisco.com> References: <4.3.2.7.2.20040420113501.02f34e78@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.2 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID 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. I will submit the new draft to the IESG as soon as it appears. - Ralph At 08:49 AM 4/25/2004 -0400, Bernie Volz wrote: >I just submitted the revised draft that corrects the minor editorial changes >requested: >- References RFC 3679 instead of its earlier internet-draft. >- Uses the IPR text from RFC 3667. >- Changes first sentence in Background section per Ralph's recommendation. >- Updates author's address. >- Changed "Relay Agent Option" to "Relay Agent Information Option" (this was >not requested but is appropriate since that is what the option is called). >- Split references (into Informative/Normative). > >It should show up in a few days. > >- Bernie Volz > > > -----Original Message----- > > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On > > Behalf Of Ralph Droms > > Sent: Tuesday, April 20, 2004 11:37 AM > > To: dhcwg@ietf.org > > Subject: [dhcwg] Results of WG last call on > > draft-ietf-dhc-reclassify-options > > > > > > draft-ietf-dhc-reclassify-options passed WG last call, but > > requires some minor editorial changes > > http://www1.ietf.org/mail-archive/working-groups/dhcwg/current > > /msg03411.html > > Once a revised version of the I-D has been published, it will > > be sent to the IESG for review. > > > > - 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 Apr 26 16:02: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 QAA16378; Mon, 26 Apr 2004 16:02:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBqm-0000i1-9k; Mon, 26 Apr 2004 15:33:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBk2-0008Fk-FT for dhcwg@optimus.ietf.org; Mon, 26 Apr 2004 15:26:10 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13178; Mon, 26 Apr 2004 15:26:07 -0400 (EDT) Message-Id: <200404261926.PAA13178@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 26 Apr 2004 15:26:07 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-reclassify-options-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 : Reclassifying DHCPv4 Options Author(s) : B. Volz Filename : draft-ietf-dhc-reclassify-options-01.txt Pages : 8 Date : 2004-4-26 This document revises RFC 2132 to reclassify DHCPv4 option codes 128 to 223 (decimal) as publicly defined options to be managed by IANA in accordance with RFC 2939. This document directs IANA to make these option codes available for assignment as publicly defined DHCP options for future options. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-reclassify-options-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-reclassify-options-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-reclassify-options-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-4-26150405.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-reclassify-options-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-reclassify-options-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-26150405.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 Apr 27 18:29: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 SAA07364; Tue, 27 Apr 2004 18:29:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIaur-00052N-7Y; Tue, 27 Apr 2004 18:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGksI-0005Dr-PT for dhcwg@optimus.ietf.org; Thu, 22 Apr 2004 16:32:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27407 for ; Thu, 22 Apr 2004 16:32:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGksE-0001QW-RV for dhcwg@ietf.org; Thu, 22 Apr 2004 16:32:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGkrU-00017B-00 for dhcwg@ietf.org; Thu, 22 Apr 2004 16:31:56 -0400 Received: from mail.nettera.net ([66.246.92.2] helo=athena.nettera.net) by ietf-mx with smtp (Exim 4.12) id 1BGkqN-0000hr-00 for dhcwg@ietf.org; Thu, 22 Apr 2004 16:30:47 -0400 Received: (qmail 23206 invoked by uid 2520); 22 Apr 2004 20:30:19 -0000 Received: from jake@capanis.com by athena.nettera.net by uid 2020 with qmail-scanner-1.20rc3 (clamuko: 0.60. spamassassin: 2.60. Clear:RC:1:. Processed in 0.017915 secs); 22 Apr 2004 20:30:19 -0000 Received: from pool-68-237-14-21.ny325.east.verizon.net (HELO ?192.168.0.101?) (68.237.14.21) by capanis.net with SMTP; 22 Apr 2004 20:30:19 -0000 User-Agent: Microsoft-Entourage/10.0.0.1309 Date: Thu, 22 Apr 2004 16:30:19 -0400 From: Jake Howerton To: Message-ID: Mime-version: 1.0 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 Subject: [dhcwg] Option 60 VCI 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 Do all clients transmit option 60? I am trying to separate devices on my network and am looking to find out if linksys and other consumer routers transmit option 60 as well as consumer and enterprise Aps like the Orinoco AP1000. I have my cable modems working with this method. If there are any other effective ways to do this, suggestions are appreciated. Jake Howerton _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 27 18:57:13 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08865; Tue, 27 Apr 2004 18:57:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbOs-0002FQ-Vn; Tue, 27 Apr 2004 18:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbKc-0001Hr-9L for dhcwg@optimus.ietf.org; Tue, 27 Apr 2004 18:45:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08472 for ; Tue, 27 Apr 2004 18:45:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIbKX-0006Wu-6b for dhcwg@ietf.org; Tue, 27 Apr 2004 18:45:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIbJp-0006PU-00 for dhcwg@ietf.org; Tue, 27 Apr 2004 18:44:49 -0400 Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx with esmtp (Exim 4.12) id 1BIbJ5-0006Eo-00 for dhcwg@ietf.org; Tue, 27 Apr 2004 18:44:03 -0400 Received: from homerdmz.incognito.com ([206.172.52.116] helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 4.30) id 1BIbId-0000ON-04; Tue, 27 Apr 2004 15:43:35 -0700 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Apr 2004 15:43:04 -0700 Message-ID: From: "Kostur, Andre" To: "'Jake Howerton'" , dhcwg@ietf.org Subject: RE: [dhcwg] Option 60 VCI Date: Tue, 27 Apr 2004 15:43:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42CA9.00C14DA0" X-Spam-Score: 2.0 (++) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 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_01C42CA9.00C14DA0 Content-Type: text/plain; charset="iso-8859-1" You don't really mention in what way you want to separate your devices. The cable modems are easily identifiable since they are following the DOCSIS specifications, and DOCSIS mandates that option 60 must be of a certain form. As far as I know there is no general requirement. From a DHCP standpoint there is no requirement that option 60 is sent at all. > -----Original Message----- > From: Jake Howerton [mailto:jake@capanis.com] > Sent: Thursday, April 22, 2004 1:30 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Option 60 VCI > > > Do all clients transmit option 60? I am trying to separate > devices on my > network and am looking to find out if linksys and other > consumer routers > transmit option 60 as well as consumer and enterprise Aps > like the Orinoco > AP1000. I have my cable modems working with this method. If > there are any > other effective ways to do this, suggestions are appreciated. ------_=_NextPart_001_01C42CA9.00C14DA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Option 60 VCI

You don't really mention in what way you want to = separate your devices.  The cable modems are easily identifiable = since they are following the DOCSIS specifications, and DOCSIS mandates = that option 60 must be of a certain form.  As far as I know there = is no general requirement.  From a DHCP standpoint there is no = requirement that option 60 is sent at all.

> -----Original Message-----
> From: Jake Howerton [mailto:jake@capanis.com]
> Sent: Thursday, April 22, 2004 1:30 PM
> To: dhcwg@ietf.org
> Subject: [dhcwg] Option 60 VCI
>
>
> Do all clients transmit option 60?  I am = trying to separate
> devices on my
> network and am looking to find out if linksys = and other
> consumer routers
> transmit option 60 as well as consumer and = enterprise Aps
> like the Orinoco
> AP1000.  I have my cable modems working = with this method.  If
> there are any
> other effective ways to do this, suggestions = are appreciated.

------_=_NextPart_001_01C42CA9.00C14DA0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 27 20:16:09 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12933; Tue, 27 Apr 2004 20:16:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIceH-0005I7-Mv; Tue, 27 Apr 2004 20:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIblK-0005Tz-Br for dhcwg@optimus.ietf.org; Tue, 27 Apr 2004 19:13:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09481 for ; Tue, 27 Apr 2004 19:13:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIblG-0001WC-TC for dhcwg@ietf.org; Tue, 27 Apr 2004 19:13:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIbkK-0001Qy-00 for dhcwg@ietf.org; Tue, 27 Apr 2004 19:12:13 -0400 Received: from mail.nettera.net ([66.246.92.2] helo=athena.nettera.net) by ietf-mx with smtp (Exim 4.12) id 1BIbjl-0001Gc-00 for dhcwg@ietf.org; Tue, 27 Apr 2004 19:11:37 -0400 Received: (qmail 25453 invoked by uid 2520); 27 Apr 2004 23:04:28 -0000 Received: from jake@capanis.com by athena.nettera.net by uid 2020 with qmail-scanner-1.20rc3 (clamuko: 0.60. spamassassin: 2.60. Clear:RC:1:. Processed in 0.265103 secs); 27 Apr 2004 23:04:28 -0000 Received: from pool-68-237-66-215.ny325.east.verizon.net (HELO ?192.168.0.101?) (68.237.66.215) by brainvisuals.com with SMTP; 27 Apr 2004 23:04:28 -0000 User-Agent: Microsoft-Entourage/10.0.0.1309 Date: Tue, 27 Apr 2004 19:04:27 -0400 Subject: Re: [dhcwg] Option 60 VCI From: Jake Howerton To: "Kostur, Andre" , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3165937467_26968508" 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,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. --B_3165937467_26968508 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Andre, I am not having trouble seperating the cable modems since as you say they are DOCSIS compatible and are sending option 60. I was looking to put wireless Aps and consumer routers onto separate subnets also. This would allow me to protect the Aps somewhat. And would allow me to ban the use of wireless routers putting holes in my network. For the Aps I can enter the MACs manually into separate pools, but the person who setup the network is long gone. And we have almost 1000 access points. So I was looking for the easy way out. I have not figured out how to identify the consumer wireless routers though. Jake Howerton On 4/27/04 6:43 PM, "Kostur, Andre" wrote: > You don't really mention in what way you want to separate your devices. The > cable modems are easily identifiable since they are following the DOCSIS > specifications, and DOCSIS mandates that option 60 must be of a certain form. > As far as I know there is no general requirement. From a DHCP standpoint > there is no requirement that option 60 is sent at all. > >> > -----Original Message----- >> > From: Jake Howerton [mailto:jake@capanis.com] >> > Sent: Thursday, April 22, 2004 1:30 PM >> > To: dhcwg@ietf.org >> > Subject: [dhcwg] Option 60 VCI >> > >> > >> > Do all clients transmit option 60? I am trying to separate >> > devices on my >> > network and am looking to find out if linksys and other >> > consumer routers >> > transmit option 60 as well as consumer and enterprise Aps >> > like the Orinoco >> > AP1000. I have my cable modems working with this method. If >> > there are any >> > other effective ways to do this, suggestions are appreciated. > --B_3165937467_26968508 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: [dhcwg] Option 60 VCI Andre,

I am not having trouble seperating the cable modems since as you say they a= re DOCSIS compatible and are sending option 60.  I was looking to put w= ireless Aps and consumer routers onto separate subnets also.  This woul= d allow me to protect the Aps somewhat.  And would allow me to ban the = use of wireless routers putting holes in my network.  For the Aps I can= enter the MACs manually into separate pools, but the person who setup the n= etwork is long gone.  And we have almost 1000 access points.  So I= was looking for the easy way out.    I have not figured out = how to identify the consumer wireless routers though.

Jake Howerton

On 4/27/04 6:43 PM, "Kostur, Andre" <akostur@incognito.com>= wrote:

You don't really men= tion in what way you want to separate your devices.  The cable modems a= re easily identifiable since they are following the DOCSIS specifications, a= nd DOCSIS mandates that option 60 must be of a certain form.  As far as= I know there is no general requirement.  From a DHCP standpoint there = is no requirement that option 60 is sent at all.

> -----Original Message-----
> From: Jake Howerton [mailto:jake@capanis.com] > Sent: Thursday, April 22, 2004 1:30 PM
> To: dhcwg@ietf.org
> Subject: [dhcwg] Option 60 VCI
>
>
> Do all clients transmit option 60?  I am trying to separate
> devices on my
> network and am looking to find out if linksys and other=
> consumer routers
> transmit option 60 as well as consumer and enterprise A= ps
> like the Orinoco
> AP1000.  I have my cable modems working with this = method.  If
> there are any
> other effective ways to do this, suggestions are apprec= iated.


--B_3165937467_26968508-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 27 20:41:48 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14064; Tue, 27 Apr 2004 20:41:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BId3Q-0008PP-JW; Tue, 27 Apr 2004 20:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIcys-0007lx-Ka for dhcwg@optimus.ietf.org; Tue, 27 Apr 2004 20:31:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13485 for ; Tue, 27 Apr 2004 20:31:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIcyo-0003Eg-DE for dhcwg@ietf.org; Tue, 27 Apr 2004 20:31:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIcxu-00038J-00 for dhcwg@ietf.org; Tue, 27 Apr 2004 20:30:20 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BIcxM-0002vA-00 for dhcwg@ietf.org; Tue, 27 Apr 2004 20:29:44 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWU00MKRUOM6E@mailout3.samsung.com> for dhcwg@ietf.org; Wed, 28 Apr 2004 09:29:10 +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 <0HWU009QQUFUZ0@mailout3.samsung.com> for dhcwg@ietf.org; Wed, 28 Apr 2004 09:23:55 +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 <0HWU007P1UFUTI@mmp2.samsung.com> for dhcwg@ietf.org; Wed, 28 Apr 2004 09:23:54 +0900 (KST) Date: Wed, 28 Apr 2004 09:24:23 +0900 From: "S. Daniel Park" To: dhcwg@ietf.org Message-id: <009701c42cb7$27fbfec0$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/mixed; boundary="Boundary_(ID_7ClV4nOnBTzAePNc3+2+gA)" 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.4 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_FONT_FACE_BAD,HTML_MESSAGE autolearn=no version=2.60 Subject: [dhcwg] I-D ACTION:draft-daniel-dhc-dhcpv4-tep-conf-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: , This is a multi-part message in MIME format. --Boundary_(ID_7ClV4nOnBTzAePNc3+2+gA) Content-type: multipart/alternative; boundary="Boundary_(ID_h1flsLK/WikQaAKh9FplGA)" --Boundary_(ID_h1flsLK/WikQaAKh9FplGA) Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT fyi comments/feedbacks are highly welcome - Daniel (Soohong Daniel Park) - Mobile Platform Laboratory, SAMSUNG Electronics. > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Configured Tunnel End-Point Configuration using DHCPv4 > Author(s) : S. Park, et al. > Filename : draft-daniel-dhc-dhcpv4-tep-conf-00.txt > Pages : 13 > Date : 2004-4-27 > > The intent of this draft is to provide a solution to automate > tunnel > end-point configuration for a configured IPv6-over-IPv4 > tunnel. This > uses a DHCPv4 option to percolate the tunnel end-point > configuration > information. This is very useful to connect a newly > deployed native > IPv6 cloud to other existing IPv6 networks using IPv4 > backbone as > well as to connect isolated dual-stack IPv4/IPv6 nodes to IPv6 > networks through IPv4. > > A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv4-tep-conf-00. txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-daniel-dhc-dhcpv4-tep-conf-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-daniel-dhc-dhcpv4-tep-conf-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. --Boundary_(ID_h1flsLK/WikQaAKh9FplGA) Content-type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7BIT I-D ACTION:draft-daniel-dhc-dhcpv4-tep-conf-00.txt

fyi

comments/feedbacks are highly welcome


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

> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
>
>
>       Title           : Configured Tunnel End-Point Configuration using DHCPv4
>       Author(s)       : S. Park, et al.
>       Filename        : draft-daniel-dhc-dhcpv4-tep-conf-00.txt
>       Pages           : 13
>       Date            : 2004-4-27
>      
> The intent of this draft is to provide a solution to automate
> tunnel     
>      end-point configuration for a configured IPv6-over-IPv4
> tunnel. This     
>      uses a DHCPv4 option to percolate the tunnel end-point
> configuration     
>      information. This is very useful to connect a newly
> deployed native     
>      IPv6 cloud to other existing IPv6 networks using IPv4
> backbone as
>      well as to connect isolated dual-stack IPv4/IPv6 nodes to IPv6
>      networks through IPv4.
>
> A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv4-tep-conf-00.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.


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-daniel-dhc-dhcpv4-tep-conf-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-daniel-dhc-dhcpv4-tep-conf-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. <<...>> <<...>>

--Boundary_(ID_h1flsLK/WikQaAKh9FplGA)-- --Boundary_(ID_7ClV4nOnBTzAePNc3+2+gA) Content-type: Message/External-body; name=ATT00052.dat Content-transfer-encoding: 7bit Content-disposition: attachment; filename=ATT00052.dat Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-4-27161121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-daniel-dhc-dhcpv4-tep-conf-00.txt --Boundary_(ID_7ClV4nOnBTzAePNc3+2+gA) Content-type: Message/External-body; name=draft-daniel-dhc-dhcpv4-tep-conf-00.txt Content-transfer-encoding: 7bit Content-disposition: attachment; filename=draft-daniel-dhc-dhcpv4-tep-conf-00.txt Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-4-27161121.I-D@ietf.org> --Boundary_(ID_7ClV4nOnBTzAePNc3+2+gA)-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Apr 29 00:46:28 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17768; Thu, 29 Apr 2004 00:46:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ3JB-000154-3K; Thu, 29 Apr 2004 00:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ3FB-0008NN-Bd for dhcwg@optimus.ietf.org; Thu, 29 Apr 2004 00:33:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17283 for ; Thu, 29 Apr 2004 00:33:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ3F5-0003KO-IG for dhcwg@ietf.org; Thu, 29 Apr 2004 00:33:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ3E5-0003Cj-00 for dhcwg@ietf.org; Thu, 29 Apr 2004 00:32:46 -0400 Received: from www.vibes.serc.iisc.ernet.in ([144.16.79.50] helo=serc.iisc.ernet.in ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1BJ3D9-00030P-00; Thu, 29 Apr 2004 00:31:48 -0400 Received: by serc.iisc.ernet.in (Postfix, from userid 604) id 583D61EEE; Thu, 29 Apr 2004 10:03:56 +0530 (IST) Received: from localhost (localhost [127.0.0.1]) by serc.iisc.ernet.in (Postfix) with ESMTP id 4398F1EED; Thu, 29 Apr 2004 10:03:56 +0530 (IST) Date: Thu, 29 Apr 2004 10:03:56 +0530 (IST) From: "T. A. Chandrappa" To: dhcwg-request@ietf.org Cc: dhcwg@ietf.org In-Reply-To: <20040425160002.21167.69677.Mailman@www1.ietf.org> Message-ID: References: <20040425160002.21167.69677.Mailman@www1.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: dhcwg digest, Vol 1 #847 - 1 msg 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: , Pl unsubscribe this hereafter. Thanks On Sun, 25 Apr 2004 dhcwg-request@ietf.org wrote: > Send dhcwg mailing list submissions to > dhcwg@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/dhcwg > or, via email, send a message with subject or body 'help' to > dhcwg-request@ietf.org > > You can reach the person managing the list at > dhcwg-admin@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dhcwg digest..." > > > Today's Topics: > > 1. RE: Results of WG last call on draft-ietf-dhc-reclassify-options (Bernie Volz) > > --__--__-- > > Message: 1 > From: "Bernie Volz" > To: > Subject: RE: [dhcwg] Results of WG last call on draft-ietf-dhc-reclassify-options > Date: Sun, 25 Apr 2004 08:49:06 -0400 > Organization: Cisco > > I just submitted the revised draft that corrects the minor editorial = > changes > requested: > - References RFC 3679 instead of its earlier internet-draft. > - Uses the IPR text from RFC 3667. > - Changes first sentence in Background section per Ralph's = > recommendation. > - Updates author's address. > - Changed "Relay Agent Option" to "Relay Agent Information Option" (this = > was > not requested but is appropriate since that is what the option is = > called). > - Split references (into Informative/Normative). > > It should show up in a few days. > > - Bernie Volz > > > -----Original Message----- > > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On=20 > > Behalf Of Ralph Droms > > Sent: Tuesday, April 20, 2004 11:37 AM > > To: dhcwg@ietf.org > > Subject: [dhcwg] Results of WG last call on=20 > > draft-ietf-dhc-reclassify-options > >=20 > >=20 > > draft-ietf-dhc-reclassify-options passed WG last call, but=20 > > requires some minor editorial changes=20 > > http://www1.ietf.org/mail-archive/working-groups/dhcwg/current > > /msg03411.html > > Once a revised version of the I-D has been published, it will=20 > > be sent to the IESG for review. > >=20 > > - Ralph > >=20 > >=20 > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > >=20 > > > > > --__--__-- > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > > > End of dhcwg Digest > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Apr 29 16:23:49 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26148; Thu, 29 Apr 2004 16:23:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHdi-0005mU-Vr; Thu, 29 Apr 2004 15:56:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHVx-0004An-Vd for dhcwg@optimus.ietf.org; Thu, 29 Apr 2004 15:48:09 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24257; Thu, 29 Apr 2004 15:48:05 -0400 (EDT) Message-Id: <200404291948.PAA24257@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 29 Apr 2004 15:48:05 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-v4-threat-analysis-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: , --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 : Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis Author(s) : R. Hibbs, et al. Filename : draft-ietf-dhc-v4-threat-analysis-02.txt Pages : 15 Date : 2004-4-29 DHCPv4 (RFC 2131) is a stable, widely used protocol for configuration of host systems in a TCP/IPv4 network. It did not provide for authentication of clients and servers, nor did it provide for data confidentiality. This is reflected in the original 'Security Considerations' section of RFC 2131, which identifies a few threats and leaves development of any defenses against those threats to future work. Beginning in about 1995 DHCP security began to attract attention from the Internet community, eventually resulting in the publication of RFC 3118 in 2001. Although RFC 3118 was a mandatory prerequisite for the DHCPv4 Reconfigure Extension, RFC 3203, it has had no known usage by any commercial or private implementation since its adoption. The DHC Working Group has adopted a work item for 2003 to review and modify or replace RFC 3118 to afford a workable, easily deployed security mechanism for DHCPv4. This memo provides a comprehensive threat analysis of the Dynamic Host Configuration Protocol for use both as RFC 2131 advances from Draft Standard to Full Standard and to support our chartered work improving the acceptance and deployment of RFC 3118. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-v4-threat-analysis-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-v4-threat-analysis-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-dhc-v4-threat-analysis-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. --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-4-29154321.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-v4-threat-analysis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-v4-threat-analysis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-29154321.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 Apr 30 06:14:21 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 GAA08065; Fri, 30 Apr 2004 06:14:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJUv6-0000HK-Pz; Fri, 30 Apr 2004 06:07:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJUqH-00087D-4L for dhcwg@optimus.ietf.org; Fri, 30 Apr 2004 06:02:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07457 for ; Fri, 30 Apr 2004 06:01:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJUq9-0004HO-Ta for dhcwg@ietf.org; Fri, 30 Apr 2004 06:01:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJUpM-00046K-00 for dhcwg@ietf.org; Fri, 30 Apr 2004 06:01:05 -0400 Received: from www.vibes.serc.iisc.ernet.in ([144.16.79.50] helo=serc.iisc.ernet.in ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1BJUoi-0003wc-00 for dhcwg@ietf.org; Fri, 30 Apr 2004 06:00:24 -0400 Received: by serc.iisc.ernet.in (Postfix, from userid 604) id 0BA871F18; Fri, 30 Apr 2004 15:32:35 +0530 (IST) Received: from localhost (localhost [127.0.0.1]) by serc.iisc.ernet.in (Postfix) with ESMTP id E33191F14 for ; Fri, 30 Apr 2004 15:32:35 +0530 (IST) Date: Fri, 30 Apr 2004 15:32:35 +0530 (IST) From: "T. A. Chandrappa" To: dhcwg@ietf.org In-Reply-To: <20040429160003.29737.41019.Mailman@www1.ietf.org> Message-ID: References: <20040429160003.29737.41019.Mailman@www1.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: dhcwg digest, Vol 1 #851 - 1 msg 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: , pl UNSUBSCRIBE THIS NEWS LETTER THANKS On Thu, 29 Apr 2004 dhcwg-request@ietf.org wrote: > Send dhcwg mailing list submissions to > dhcwg@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/dhcwg > or, via email, send a message with subject or body 'help' to > dhcwg-request@ietf.org > > You can reach the person managing the list at > dhcwg-admin@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dhcwg digest..." > > > Today's Topics: > > 1. Re: dhcwg digest, Vol 1 #847 - 1 msg (T. A. Chandrappa) > > --__--__-- > > Message: 1 > Date: Thu, 29 Apr 2004 10:03:56 +0530 (IST) > From: "T. A. Chandrappa" > To: dhcwg-request@ietf.org > Cc: dhcwg@ietf.org > Subject: [dhcwg] Re: dhcwg digest, Vol 1 #847 - 1 msg > > Pl unsubscribe this hereafter. > > Thanks > > On Sun, 25 Apr 2004 dhcwg-request@ietf.org wrote: > > > Send dhcwg mailing list submissions to > > dhcwg@ietf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www1.ietf.org/mailman/listinfo/dhcwg > > or, via email, send a message with subject or body 'help' to > > dhcwg-request@ietf.org > > > > You can reach the person managing the list at > > dhcwg-admin@ietf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of dhcwg digest..." > > > > > > Today's Topics: > > > > 1. RE: Results of WG last call on draft-ietf-dhc-reclassify-options (Bernie Volz) > > > > -- __--__-- > > > > Message: 1 > > From: "Bernie Volz" > > To: > > Subject: RE: [dhcwg] Results of WG last call on draft-ietf-dhc-reclassify-options > > Date: Sun, 25 Apr 2004 08:49:06 -0400 > > Organization: Cisco > > > > I just submitted the revised draft that corrects the minor editorial = > > changes > > requested: > > - References RFC 3679 instead of its earlier internet-draft. > > - Uses the IPR text from RFC 3667. > > - Changes first sentence in Background section per Ralph's = > > recommendation. > > - Updates author's address. > > - Changed "Relay Agent Option" to "Relay Agent Information Option" (this = > > was > > not requested but is appropriate since that is what the option is = > > called). > > - Split references (into Informative/Normative). > > > > It should show up in a few days. > > > > - Bernie Volz > > > > > -----Original Message----- > > > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On=20 > > > Behalf Of Ralph Droms > > > Sent: Tuesday, April 20, 2004 11:37 AM > > > To: dhcwg@ietf.org > > > Subject: [dhcwg] Results of WG last call on=20 > > > draft-ietf-dhc-reclassify-options > > >=20 > > >=20 > > > draft-ietf-dhc-reclassify-options passed WG last call, but=20 > > > requires some minor editorial changes=20 > > > http://www1.ietf.org/mail-archive/working-groups/dhcwg/current > > > /msg03411.html > > > Once a revised version of the I-D has been published, it will=20 > > > be sent to the IESG for review. > > >=20 > > > - Ralph > > >=20 > > >=20 > > > _______________________________________________ > > > dhcwg mailing list > > > dhcwg@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dhcwg > > >=20 > > > > > > > > > > -- __--__-- > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > > End of dhcwg Digest > > > > > > --__--__-- > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > > > End of dhcwg Digest > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg