From mailman-owner@ietf.org Mon Jul 1 06:13:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18989 for ; Mon, 1 Jul 2002 06:13:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04601 for ; Mon, 1 Jul 2002 06:14:02 -0400 (EDT) Date: Mon, 1 Jul 2002 06:14:02 -0400 (EDT) Message-Id: <200207011014.GAA04601@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: dhc-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol 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@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@lists.ietf.org From dhcwg-admin@ietf.org Mon Jul 1 06:35:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21559; Mon, 1 Jul 2002 06:35:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17671; Mon, 1 Jul 2002 06:35:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17650 for ; Mon, 1 Jul 2002 06:35:49 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21290; Mon, 1 Jul 2002 06:34:59 -0400 (EDT) Message-Id: <200207011034.GAA21290@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 01 Jul 2002 06:34:59 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-dstm-ports-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --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 : DSTM Ports Option for DHCPv6 Author(s) : M. Shin Filename : draft-ietf-dhc-dhcpv6-opt-dstm-ports-01.txt Pages : 4 Date : 28-Jun-02 The DSTM Ports Option provide DSTM (Dual Stack Transition Mechanism) configuration information to DHCPv6 hosts A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dstm-ports-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-dstm-ports-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-dhcpv6-opt-dstm-ports-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: <20020628141912.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-dstm-ports-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-dstm-ports-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020628141912.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jul 1 15:58:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29799; Mon, 1 Jul 2002 15:58:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07077; Mon, 1 Jul 2002 15:58:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01509 for ; Thu, 27 Jun 2002 18:43:58 -0400 (EDT) Received: from server2.pnx.com (mail.pnx.com [208.192.112.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20887 for ; Thu, 27 Jun 2002 18:43:14 -0400 (EDT) Received: from hopperton (unverified [208.192.114.148]) by server2.pnx.com (Vircom SMTPRS 5.1.202) with SMTP id for ; Thu, 27 Jun 2002 17:53:38 -0500 Message-ID: <000a01c21e2b$068e20c0$9472c0d0@hopperton> From: "Ronald Hopperton" To: Date: Thu, 27 Jun 2002 17:35:08 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C21E00.FBA31F00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Subject: [dhcwg] DHCP alert message Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C21E00.FBA31F00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I recently updated my W 95 Dial-up Networking program with an update = version 1.4 ! Afterwards I now get a message at various times before & = after logging on to the internet that says: This DHCP client was unable to obtain an IP network address = from a DHCP server. Do you want to see future alerts? Then I am asked whether to continue or discontinue future use of this = alert? Since my knowledge is rather weak in how this is routinely used = & what value it has - I have continue to request the alert. What = advice may you offer on what action to take - what parameters do I need to evaluate to - further investigate why this = occurs or just disregard it, thanks? =20 ron ------=_NextPart_000_0007_01C21E00.FBA31F00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I recently updated my W 95 Dial-up = Networking=20 program with an update version 1.4 !   Afterwards I now get a = message=20 at various times before & after logging on to the internet that=20 says:
 
        =20 This DHCP client was unable to obtain an IP network address from a DHCP = server.=20 Do you want to see future alerts?
 
Then I am asked whether to continue or = discontinue=20 future use of this alert?  Since my knowledge is rather weak in how = this is=20 routinely used & what value it has  - I have continue to = request the=20 alert.  What advice may you offer on what action to take=20 -
what parameters do I need to evaluate = to - further=20 investigate why this occurs or just  disregard it, thanks?  
 
       =20             =    =20             =    =20            =20 ron
------=_NextPart_000_0007_01C21E00.FBA31F00-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jul 2 05:41:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29641; Tue, 2 Jul 2002 05:41:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26664; Tue, 2 Jul 2002 05:41:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26627 for ; Tue, 2 Jul 2002 05:41:21 -0400 (EDT) Received: from smtp.jeego.net ([61.129.76.60]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29629 for ; Tue, 2 Jul 2002 05:40:31 -0400 (EDT) Received: From 61.171.25.155 by smtp.jeego.net with AceEmail id 24038 for dhcwg@ietf.org; Tue Jul 2 18:32:08 2002 +0800 Reply-To: ale_duan@ccandc.com.cn From: "AleDuan" To: Date: Tue, 2 Jul 2002 17:41:42 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id FAA26628 Subject: [dhcwg] How to reduce the memory taken by DHCP Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit The memory taken by DHCP is about 10M which is running on the OS of vLinux, The aim of my company is to reduce the memory taken by DHCP to 2~5M.But I don't know how to do.Please tell me how to deal with the task and which section of the DHCP source code I should rewrite. Thanks. Ale Duan 2002.7.2 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jul 2 06:15:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00469; Tue, 2 Jul 2002 06:15:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA28380; Tue, 2 Jul 2002 06:14:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA23596 for ; Tue, 2 Jul 2002 04:49:58 -0400 (EDT) Received: from ruth.salt-ag.com (qmailr@thyr.salt-ag.com [194.180.199.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA28745 for ; Tue, 2 Jul 2002 04:49:10 -0400 (EDT) Received: (qmail 25116 invoked from network); 2 Jul 2002 08:49:55 -0000 Received: from chem.salt-ag.com (HELO chem) (194.180.199.223) by zeus.salt-ag.com with SMTP; 2 Jul 2002 08:49:55 -0000 Received: by localhost with Microsoft MAPI; Tue, 2 Jul 2002 10:49:55 +0200 Message-ID: <01C221B6.33E42770.ralph.zimmermann@salt-ag.com> From: Ralph Zimmermann Reply-To: "ralph.zimmermann@salt-ag.com" To: "'dhcwg@ietf.org'" Date: Tue, 2 Jul 2002 10:49:54 +0200 Organization: SALT AG X-Mailer: Microsoft Internet E-Mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) at SALT AG, Germany. www.salt-ag.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA23597 Subject: [dhcwg] DHCP secure communication Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit Hi, I'm looking for a way to have a secure communication between DHCP server and client. One reason is to prevent visitors to our company from plugging in their laptops (I know, this should never happen, but ...) configured for DHCP and then easily be part of our network. A ssh like add-on to client and server would prevent standart DHCP clients from obtaining an ip address, as they will not know the right keys to talk to it (so it should at least be some shared secret). This would also prevent visitors from sniffing the IP multicasts in plain text. If there's any know solutions to this, please let me know. Many thanks, Ralph Zimmermann _____________________________________________ - Network Administrator - SALT AG Sedanstrasse 23 D-97082 Würzburg Tel: +49 931 3573 - 400 Fax: +49 931 3573 - 409 mailto:ralph.zimmermann@salt-ag.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jul 2 06:31:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01062; Tue, 2 Jul 2002 06:31:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29632; Tue, 2 Jul 2002 06:31:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29590 for ; Tue, 2 Jul 2002 06:31:12 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00880; Tue, 2 Jul 2002 06:30:22 -0400 (EDT) Message-Id: <200207021030.GAA00880@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 02 Jul 2002 06:30:21 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-isnsoption-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --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 Options for Internet Storage Name Service Author(s) : J. Tseng, K. Gibbons Filename : draft-ietf-dhc-isnsoption-01.txt Pages : 9 Date : 01-Jul-02 This document describes the DHCP option to allow iSNS clients devices using DHCP to automatically discover the location of the iSNS server. iSNS provides discovery and management capabilities for iSCSI and Fibre Channel (FCP) storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity as a storage area network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-isnsoption-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-isnsoption-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: <20020701151831.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-isnsoption-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-isnsoption-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020701151831.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 Jul 2 06:56:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02857; Tue, 2 Jul 2002 06:56:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02064; Tue, 2 Jul 2002 06:56:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02038 for ; Tue, 2 Jul 2002 06:56:07 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02815 for ; Tue, 2 Jul 2002 06:55:14 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g62AtWpj010339; Tue, 2 Jul 2002 03:55:32 -0700 (PDT) Received: from JSCHNIZL-W2K1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g62AtUvD016856; Tue, 2 Jul 2002 03:55:31 -0700 (PDT) Message-Id: <4.3.2.7.2.20020702065351.018480b0@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 02 Jul 2002 06:55:27 -0400 To: "ralph.zimmermann@salt-ag.com" From: John Schnizlein Subject: Re: [dhcwg] DHCP secure communication Cc: "'dhcwg@ietf.org'" In-Reply-To: <01C221B6.33E42770.ralph.zimmermann@salt-ag.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org RFC 3118 Authentication for DHCP Messages At 04:49 AM 7/2/2002, Ralph Zimmermann wrote: >I'm looking for a way to have a secure communication between DHCP server >and client. One reason is to prevent visitors to our company from plugging in >their laptops (I know, this should never happen, but ...) configured for DHCP >and then easily be part of our network. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jul 2 10:54:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15244; Tue, 2 Jul 2002 10:54:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25885; Tue, 2 Jul 2002 10:52:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25858 for ; Tue, 2 Jul 2002 10:52:27 -0400 (EDT) Received: from portal.incognito.com (PORTAL.INCOGNITO.COM [207.102.214.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14874 for ; Tue, 2 Jul 2002 10:51:39 -0400 (EDT) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by portal.incognito.com with smtp (Exim 3.33 #1) id 17POl7-0000Cy-00; Tue, 02 Jul 2002 07:36:01 -0700 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id <2ZV84965>; Tue, 2 Jul 2002 07:59:27 -0700 Message-ID: <4FB49E60CFBA724E88867317DAA3D198A66F6A@homer.incognito.com.> From: "Kostur, Andre" To: "'ralph.zimmermann@salt-ag.com'" , "'dhcwg@ietf.org'" Subject: RE: [dhcwg] DHCP secure communication Date: Tue, 2 Jul 2002 07:59:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C221D9.0A753AF0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C221D9.0A753AF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There's a couple of options. One is RFC 3118 as mentioned by John Schnizlein. This would require you to deploy something to every = legitimate client that you have (and have a DHCP server that understands 3118). A second option is to do something like register all of the MAC addresses = of your legitimate devices to your DHCP server. I'm pretty sure most (if = not all) DHCP servers are capable of assigning a particular IP to a = particular MAC. Some servers allow for a little more flexible mechanism where = only certain MACs may request an address, but are still allocated an address dynamically (I know Incognito's can). > -----Original Message----- > From: Ralph Zimmermann [mailto:ralph.zimmermann@salt-ag.com] > Sent: Tuesday, July 2, 2002 1:50 AM > To: 'dhcwg@ietf.org' > Subject: [dhcwg] DHCP secure communication >=20 >=20 > Hi, >=20 > I'm looking for a way to have a secure communication between=20 > DHCP server > and client. One reason is to prevent visitors to our company=20 > from plugging in > their laptops (I know, this should never happen, but ...)=20 > configured for DHCP > and then easily be part of our network. >=20 > A ssh like add-on to client and server would prevent standart=20 > DHCP clients from > obtaining an ip address, as they will not know the right keys=20 > to talk to it (so it > should at least be some shared secret). This would also=20 > prevent visitors from > sniffing the IP multicasts in plain text. >=20 > If there's any know solutions to this, please let me know. >=20 > Many thanks, > Ralph Zimmermann >=20 > _____________________________________________ > - Network Administrator - >=20 > SALT AG > Sedanstrasse 23 > D-97082 W=FCrzburg >=20 > Tel: +49 931 3573 - 400 > Fax: +49 931 3573 - 409 >=20 > mailto:ralph.zimmermann@salt-ag.com >=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 ------_=_NextPart_001_01C221D9.0A753AF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] DHCP secure communication

There's a couple of options.  One is RFC 3118 as = mentioned by John Schnizlein.  This would require you to deploy = something to every legitimate client that you have (and have a DHCP = server that understands 3118).  A second option is to do something = like register all of the MAC addresses of your legitimate devices to = your DHCP server.  I'm pretty sure most (if not all) DHCP servers = are capable of assigning a particular IP to a particular MAC.  = Some servers allow for a little more flexible mechanism where only = certain MACs may request an address, but are still allocated an address = dynamically (I know Incognito's can).

> -----Original Message-----
> From: Ralph Zimmermann [mailto:ralph.zimmermann@sal= t-ag.com]
> Sent: Tuesday, July 2, 2002 1:50 AM
> To: 'dhcwg@ietf.org'
> Subject: [dhcwg] DHCP secure = communication
>
>
> Hi,
>
> I'm looking for a way to have a secure = communication between
> DHCP server
> and client. One reason is to prevent visitors = to our company
> from plugging in
> their laptops (I know, this should never = happen, but ...)
> configured for DHCP
> and then easily be part of our network.
>
> A ssh like add-on to client and server would = prevent standart
> DHCP clients from
> obtaining an ip address, as they will not know = the right keys
> to talk to it (so it
> should at least be some shared secret). This = would also
> prevent visitors from
> sniffing the IP multicasts in plain = text.
>
> If there's any know solutions to this, please = let me know.
>
> Many thanks,
> Ralph Zimmermann
>
> = _____________________________________________
> - Network Administrator -
>
> SALT AG
> Sedanstrasse 23
> D-97082 W=FCrzburg
>
> Tel:  +49 931 3573 - 400
> Fax: +49 931 3573 - 409
>
> mailto:ralph.zimmermann@sal= t-ag.com
>
>
>
> = _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

------_=_NextPart_001_01C221D9.0A753AF0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jul 2 11:05:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16742; Tue, 2 Jul 2002 11:05:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27686; Tue, 2 Jul 2002 11:05:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27597 for ; Tue, 2 Jul 2002 11:05:21 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16646 for ; Tue, 2 Jul 2002 11:04:33 -0400 (EDT) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-101.cisco.com [161.44.150.101]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA28163 for ; Tue, 2 Jul 2002 11:04:49 -0400 (EDT) Message-Id: <4.3.2.7.2.20020702105904.01c47c78@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 02 Jul 2002 11:01:16 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Request for agenda items Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Please forward request for agenda slots to me by Tuesday, 7/9. We have the following items on the agenda: Review of DHCPv6 status and changes based on IESG review Discussion of revised charter - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jul 2 11:05:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16743; Tue, 2 Jul 2002 11:05:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27641; Tue, 2 Jul 2002 11:05:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27602 for ; Tue, 2 Jul 2002 11:05:21 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16645 for ; Tue, 2 Jul 2002 11:04:33 -0400 (EDT) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-101.cisco.com [161.44.150.101]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA28169 for ; Tue, 2 Jul 2002 11:04:50 -0400 (EDT) Message-Id: <4.3.2.7.2.20020702110256.01cb6db8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 02 Jul 2002 11:04:24 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call for "DHCP Lease Query" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Announcing the WG last call for "DHCP Lease Query", . If you have any comments about this I-D, please respond to dhcwg@ietf.org, preferably before the DHC WG meeting in Yokohama on 7/16. The last call discussion will close on Monday, 7/22/2002. - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jul 2 11:07:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16872; Tue, 2 Jul 2002 11:07:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27676; Tue, 2 Jul 2002 11:05:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27604 for ; Tue, 2 Jul 2002 11:05:21 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16647 for ; Tue, 2 Jul 2002 11:04:33 -0400 (EDT) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-101.cisco.com [161.44.150.101]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA28166 for ; Tue, 2 Jul 2002 11:04:50 -0400 (EDT) Message-Id: <4.3.2.7.2.20020702105403.0591af38@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 02 Jul 2002 11:02:50 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call for "Dynamic Host Configuration Protocol (DHCP) Server MIB" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Announcing the WG last call for "Dynamic Host Configuration Protocol (DHCP) Server MIB", . If you have any comments about this I-D, please respond to dhcwg@ietf.org, preferably before the DHC WG meeting in Yokohama on 7/16. The last call discussion will close on Monday, 7/22/2002. - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jul 2 23:49:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02378; Tue, 2 Jul 2002 23:49:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA15460; Tue, 2 Jul 2002 23:49:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26239 for ; Tue, 2 Jul 2002 17:32:52 -0400 (EDT) Received: from mx-relay21.treas.gov (mx-relay21.treas.gov [199.196.132.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16673 for ; Tue, 2 Jul 2002 17:32:02 -0400 (EDT) Received: from TIAS24.net.treas.gov (tias24.treas.gov [199.196.132.24]) by mx-relay21.treas.gov (8.12.3/8.12.3) with SMTP id g62LNH8E003994 for ; Tue, 2 Jul 2002 17:23:18 -0400 (EDT) Received: from mailhub-23.net.treas.gov by TIAS24.net.treas.gov via smtpd (for [199.196.132.5]) with SMTP; 2 Jul 2002 21:32:50 UT Received: from irsbd2.net.treas.gov (localhost [127.0.0.1]) by mailhub-23.net.treas.gov (8.12.3/8.12.3) with SMTP id g62LWn1r022724 for ; Tue, 2 Jul 2002 17:32:49 -0400 (EDT) Received: from no.name.available by irsbd2.net.treas.gov via smtpd (for mailhub.net.treas.gov [10.13.252.13]) with SMTP; 2 Jul 2002 21:28:31 UT Received: by mem0200bh01.msc.irs.gov with Internet Mail Service (5.5.2655.55) id ; Tue, 2 Jul 2002 16:32:48 -0500 Message-ID: From: Hawkes Larry To: "'dhcwg@ietf.org'" Date: Tue, 2 Jul 2002 16:32:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C2220F.FDF5E680" Subject: [dhcwg] CLEANING UP DHCP RESERVATIONS Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_000_01C2220F.FDF5E680 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2220F.FDF5E680" ------_=_NextPart_001_01C2220F.FDF5E680 Content-Type: text/plain; charset="iso-8859-1" We have been using Microsoft DHCP Manager 4.0 and over time have made a number of reservations for servers and printers. Is there any easy way to determine if a reservation is still being used? I know when a device first uses a reserved address from DHCP, DHCP marks the reservation "in use". But if that IP address is no longer used because the device went away for what ever reason, how can we determine that the reserved IP address is no longer in use? DHCP never removes the "in use" label after the initial request from a client to lease that IP address. It would be nice to have DHCP take the "in use" label away if the device lets the lease expire, because the client still follows the lease setup for the scope even though it is using an reserved IP address. Or, be able to specify a individual lease time for a reservation. For example if a reservation is set up with a lease of three months, and three months go by with out the lease being renewed, then the reservation is automatically removed. Third might be if the reservation could keep a time stamp of the last time the lease was renewed. It would then be easier to determine if you might want to delete the reservation if it had an old date. Thanks, Larry Hawkes 801-620-7332 larry.hawkes@irs.gov Fly R/C Airplanes ------_=_NextPart_001_01C2220F.FDF5E680 Content-Type: text/html; charset="iso-8859-1"
We have been using Microsoft DHCP Manager 4.0 and over time have made a number of reservations for servers and printers. Is there any easy way to determine if a reservation is still being used? I know when a device first uses a reserved address from DHCP, DHCP marks the reservation "in use". But if that IP address is no longer used because the device went away for what ever reason, how can we determine that the reserved IP address is no longer in use? DHCP never removes the "in use" label after the initial request from a client to lease that IP address.
It would be nice to have DHCP take the "in use" label away if the device lets the lease expire, because the client still follows the lease setup for the scope even though it is using an reserved IP address. Or, be able to specify a individual lease time for a reservation. For example if a reservation is set up with a lease of three months, and three months go by with out the lease being renewed, then the reservation is automatically removed. Third might be if the reservation could keep a time stamp of the last time the lease was renewed. It would then be easier to determine if you might want to delete the reservation if it had an old date.

Thanks, Larry Hawkes 801-620-7332 larry.hawkes@irs.gov

Fly R/C Airplanes

 
------_=_NextPart_001_01C2220F.FDF5E680-- ------_=_NextPart_000_01C2220F.FDF5E680 Content-Type: image/jpeg; name="avistar.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="avistar.jpg" Content-ID: <231261121@02072002-1e7f> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD//gASQWRvYmUgSW1hZ2VSZWFkef/sABFEdWNreQABAAQAAABG AAD/7gAmQWRvYmUAZMAAAAABAwAVBAMGCg0AAAhMAAANYQAAFJYAAB2T/9sAhAAEAwMDAwMEAwME BgQDBAYHBQQEBQcIBgYHBgYICggJCQkJCAoKDAwMDAwKDAwNDQwMEREREREUFBQUFBQUFBQUAQQF BQgHCA8KCg8UDg4OFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU FBQUFBT/wgARCACmAPoDAREAAhEBAxEB/8QA5wABAAIDAQEBAAAAAAAAAAAAAAUGAgQHAwEIAQEA AwEBAQAAAAAAAAAAAAAAAwQFAgEGEAACAwABAgYCAwEAAAAAAAABAgADBAURBiAwQBITFBBwUCEx JBEAAQIEAwMICAIJBQAAAAAAAQIDABEhBDESIkFREzBhcZGhMkIUIIGxwdFSYiNjJEBw8OGSojNT BfGCQxUlEgACAQMDAgQHAAAAAAAAAAAAIQEwETEQQCIgAnBBYRJQgFGRodEjEwEAAQMCBQMEAwEB AAAAAAABEQAhMUFRYXGBkaEwsdEgQPDBEHDh8VD/2gAMAwEAAhEDEQAAAe/gAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAr/ADZ3eq0mAAAAAeB5 A2TMAAAAAAGJxH577PsH0PxkgAAAACC4t8ZofZeObLLy5u9zXtFrMsNqjL3YPQAAA+FW4u7fMMrJ BTqe1r1ub3rY+wAAAAAYkJSvVLM2qVT36zNrzWdn2vzBt+5gTu3n73vnsAAa/nVLqasXU787E0tL Wt1nJ2vfPYAAAAAAxKtBr0ap9JSaf0WWd1ZqeLctT5af+hx93vnV68helk8eJWebevDNnBJYrEMT Stx8U2d+C52sWSPoAAAAABgVaDZ5xT+jp1LZs9CCUkz5jrM27ObNaOfGWpfdxbpam0AAAAAAAACG gsx89ajdOq8uQPeIerRDpe9L6mRq6+MGj7VOZWtnzUmVPS5MvoU5zRzd63X2OvPoAAAAAANTnrgV a7Ur1Dpkctu4vc6z/oKXS6kZ8rol/M6JaqRsGxUa29Vqe0x/ZKnUSNieravo/nbTqYfv42D2MgAA AACF565/17NR6MZWuzVevK282YtQeZIAA0opILO04DM06F79VAS6/RtT4vo+h8PgSfnuwAAAAAfC I4l+dxS5kAYmkczOtgAGJARaGv53YJszZAAAAAABSuZOEd8fqzzwACNPzH6/V3gAAAAAAAAAACHK L66l4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA//9oACAEBAAEFAv0tyPKU4XzF3byzbWs+zRPtZ4GVvPJChGPNcxkHSvyu UXk2p3aO4qDxr7dFicryAzJzFyGjnRKuTzWRXV/Ju5/Dnuq5bJaV0UvO5trV5uPoow00jpV5ZAIs 4jC419uXfV56jRXdXfbXKeS9szcnM/Ke6JsUxbEfxW003rq7YwNMvH8nTfqs43LsxX3W3LqEFtbe cQGGrt3i9U19o6q5fi2Ymr23VzNzPSUb6boltgC65s5bPiSju3hbz9osGteaOWzpM9mvVbj7cNSt wfGsH7dZY3H9w0SrkOUzmu24+eyq41du8ZpnLcAOKpq5BTKeV00JX3EZVztDyy7jNorup9uvE+yZ uMqEqpqrHotlzZbOW5zNxSjvO5rq9NdlfdnDc5y91uK7Hq18n8Opd2BwKFsjLpzFN2hZXzFqyrnZ TzIMTmkETkKWVb6nn++fqzprz8zhvrprC+/iE7kwX7Od4/HN/N28nHwW32VcWRMHbNxmfismdNPb nF6Jp7QtEs4LlKnPG1Z5Vn/o/PUaeR01HByi3kW2CDRBchgIPmX3Z8xycco7i5Li25AV9sceiU8B Qq1cLlSLlzIis2c+CzJmtOrgqNJ1cTuzDU3M0lneydphmssNdcWu62JUqeYQCM/SpsVH/OAB4CAw 931hT39x93IeEgNNPCcZqmDhU45q6K6vP7o3DjeM43kuXxbPDyGdteDiO2uXt5L0/J8bn5bFxPZW bj9P61//2gAIAQIAAQUC/S3X+Ad/c/lnrCWll5WHQev2mn20i3I3ldYGB/Fz+1c9ft856VeHMQ1N bIGQGNRFusribFPktUpiUFDYF6iwH0JQGGqFY1KmBbK5XtiuGnXw9Z16yusrCgMOZJ8DCKW9CUBh qj1z4ek62ifZcRdqQaKzP9nt9Ix6eL2iFBPbCsNKmfXnW5Z9txF2Az5kgPX0KH8lgI9/SfNAjNBU B+CghpjKVnzExmn+istXKLS3omXrDSCPqp0SpU8bKGn1Un0jPgCwf1KvXlQYq9P3P//aAAgBAwAB BQL9LLWW/gOnw1eXV7OtVedpbUghyJ1OMRsziFCPKFLEGth+MlfVtFhc+at7iV7B7srKQa41EsyR 6GHkA9IuphLLEYVCxlsrCj0FeuxJXyQiWpZDUDLMgMsykQidPCKjGCrLdBeDRYJ9qfJSY1SH0Ney 1InJAxHrsj51YtgEbCYcriGthEf2xn6+kUdfEmixZXssi60gKvDUI2UGNhEbFPqtDWw9CJYPzXmd 4mFRCqrGuAjWkzrE2WrE5ODbUZ85aM8/ox86NL83s9FTf8c+8/VtbmM5bxhiJXqZImlGlfwNPaBO T/r0B89NFiS7Q1voAf2v/9oACAECAgY/AvDaIqLW3mY0U1vdOZrM90D0R+xqkpLztHpxOcCoOb6r ukezcF4kUj7RxYzv3opMjgwZ2VqigdjzFMD2q62JDm5j5Cf/2gAIAQMCBj8C8Fr/AE+AetTmcbGC wql4MaXnEHpXv3GarZhnt7YRZzP42OTlAppMjTI4gcWOM/fY5HBm/Vja26uMnKBoT3F9cHJi6MnK DJxgdjE6J7LF6n9LitpGwvXUkX8vGf8A/9oACAEBAQY/Av1LMMGZuLgybQkZjC1KM9nKVVHe7DHf ETSZjm5cqNAKmF3qpm3ScjI/DT8YJ3nkx/1vDz+Lie798HzanWhvSJJ60wtxV06EtjHNOvrg3S+G pkGhIkojCElaMhOGKDGvqUPeIqcpjSZ8jwHcza/xElCesiJBQJ+kgxpWPZCbBg/mLvTTY34vhAYB HHlqSMYT+2PKSNRCwhvglzvFvTDdtarC20KE81CUiEBbaktJTjLTM88aVU3GsatPRURRU+iO/Ppr GoS5xURpVP0sjyEuI3KE4K7VarRf0maOoxw3HW1221xOPUY81cukvgZWmBIqSOjZ6443BabtzsJz uqPPKKp6qxRXLSImN0E8LhL+ZrT2YRmtHA8PlVpV8I++0po7/wB8V1e2JEy5lRqoYmhcx1xrT1Rn cbeUPw21L9kZONwnPleHD9sTQKHA4xNSpDqhYZ+84kTn4a4V+EXCyshnKUso2V29MAB5TYxWMc3q Pvj+llV86DkP8sona3zrfMuSx7o+063cDpKT2xlvbJ4bEqZGZPtjCfTFeWyqExuMEhvhLPibp2Qb ty4T5VOM6KruiVqsJHy/6wFLNT3QMZRrEc/MYAuW0ODZxEBXtgJQU5RQAUpBHmCEFOXJ4YAcUFUA M8KRo2fobVwT+WP23huzYK90DMhTzy+4hGHrOyAPLpS3Lupm4Z9NPZCVjxCcoDrCm3LRr+lag5VD eTOhMN2/+SbXbZiM+YVyTqRvjylklFzbNiQDqZLTLw5hLCAHELZdOPDPGR2yPtj8u8h36Z5FdSpR rC2+yO9Ppis/UYqr+KN/RGrDfAVMZTtEUVFOXctnO44kpMOOcR1dzmSh61SkqQstjvc1I8u0RnWm iEKzTJ2CLdq8HGs3BIy1FoD5jElvZ1/22tRhIZs28rZzNuPJDigd4nQQXHdSzugTGWdBvM4CnEhp O9dVfw/GMkuJPHPXswiYb4St7dInavhX0rpGRTND456YHmrkIWcEIE1R9pNyrnXlQO2JF5pI+Ur1 dkSSFEbwnOmFJdcQ2sYA6D2xjMRURjFOUcfWQ2fGo7hFx/km2MtmtoKt3Msk8VXelEhdutD+2O51 UjLrW785+ESKSVfMr4RNWrsgtpaSEqooSxgIdM2jRtw7PpV7j78fQzLbTmGCpVgEuLCR/wAc9Jj/ AM1lnnPiiVzxUdg7ImtRV01i5MzlSlIA2VMazKeA2n1RRPDRvX3ur4xvO88pI4QbBdUgZmJ7W93+ 3DqhC3FqdK0pVqlSY5gIoJehI1BxEHiK/LivEV4R9R3c8C04CxarWG0XUxtMplOwev0pETETcYAV 8ydJh3yzp4bspzE1CW4xNI1nFZqrr5fzoo+hxIYUMQpVD/LOLZ/zzjzRdQ2WCtSkqbWZYGmGHpXN qg5VvtLbSrcVJlDdrc2jjLSHAp95QkjKkzorAz2S/SHLG6nwnNqe8CKgiG7m5uVXZYOZhspyISd8 pmZH6tv/2gAIAQEDAT8h/pZO7z2RBPAvlpycAG1/Uxx0v7UlmP4bUMx3pPeiYG8p9dyYajoFH1cq iNThk1xQI5FvTANbGdzTZS9xYgdMI81KpxF3OEiIHSjBWEDjBgtej4XoZBwZirMTP4j9lRpzC5+d KCkzwZ9BYF22o4qsLbsKnHmP83xWtB0bvNXX3xtR191ZNMUJOVRfcn3eoiETI3KJyKIcrRjGu1TU Km/CptParQ+DVxfZoVkx5ZVoF4/Y1jYhq5jpkpAWcFrvnvQxOKDHy217fU7eMmHmmMqguP54So8H djI23nnFR6pikaAspuqpsR6w9AVYcr0mzHGx+qxhOzZ8+s8MtlXGs2e+8/DSpT8NLPkVEQuGIMbC 3mniUDVt3FTRKeB5x3qOLvUrlhbZ5psXN3+n5qys5xvNEeai5tvve3zUEaKZYI6kUoYJdiw61xRL 57nM81JA0WByQs0RvrSOmwoHNOLxoSmDrFd8HiknY3zB5puQ+il0keavOqApneI+KgznwhOpaiYM HX1kI3yEnmuPpjLw8Up8gM8MC4rXXjcrzPhUC8ZV1Id6x4TiT5KzQHIPmiBq4KOyrAZLIBYAoqQV RuWLsPCgd+NS1+WiIRwH4+zXzJtZPE3c6jcyR9E9g9XhSQQ2QXZMYik6Vg8CTQf1vLk3Vc7FjVSA 8soVDgXCpuM75LZOrS7OawYkEH4sNDxmsfg7gtRhXSZHw1oLlfEVi/ce9Y7fAR5vUIkcTH2qAm96 OYw1NmwYqx1Qlyk4euFvPAnCcRuUdbNzYyhtAPKKM4YPK59eE1YtsowXBDFgFqeEP+mljq0hZlIf CXHekrk3QH69imwUwGpYAZVr8MEgMdRTFPW2umDtUjJdb2YqRMaDLufFG+CIet/yndWBNy18Vos3 uxv8UkfiqR/VS77Mq6wNRa3mSzwdHCbNz5r5cra3OsgHl6luh06ac9qfDCTeGWrExzasoOFRfO95 q/25h7RiuNwuI5D4pKFWx+2ezRiqsFnHfrSBXFyU2E/64dX0gKW0B1KzfJlOcEUJIWzHQJ70x6Ce W2nJTu33U6kZKwWcdKPE1xCcBd6U5PV5cjjq6Vv/AD9+Dp6iIJVkcJQz+Xff3atOSh3a50goYnOa w9yfQ4MFCXEaZy1sjFeE8nXejs8BBMSBKut0afUdC2EmlFN/EKgV2YrjwNdRp5m7lOa9vXv4htys lxHZSGi2G3ISDInQLfUG9HMJFe9Kd32JlrMIlczj7gprBmheSZuJUbXLtFW5BcJ0/rb/2gAIAQID AT8h/pZB/wCBGt7+PVB81Hxlqz46KgyE4ULmTpTsXO3pQpaBJ/gZqUf4xt8+tHIuUpSZKURhmsmU nFVmybfKrXf8d6EST0M6VgsalLC40p7J3vRf7Fl0pzCsBarou3xWjBxPigpcnCoVP0QqUo6Vrke1 Z8GtBblUj3E0D4n2TQ4/gCeQNacef4Vu7v8A7WoPKsaetvem2zRuv9pYOmtFR9C2StO1wI0eiuBV ZpfnCjHT596MefFak96ItHO1Bgz9gk05L0/hn+EHgpnis9bnXGv4XpWw0VKTyvWvetqHZ5S+1SRe 23mt0mjFScQjz9hFDW4qISlFgy8axD5+sSBJUBbLfPvSjf8AD+NBhanM/YFrevlChx+wStPrn7mf 62//2gAIAQMDAT8h/pYpGMv/AAGx1e/qbpHCtQOefNEhG/CrHmaTl+64pWePSgxPJKIlRUVzKeul SDo9aAvMb3qUK7tSaBPmgaJoH+BT60UlqtVGWKW+Fl3/ADhV9OQgVH2GGkbN6TpcS9BWn82/jNMr D0pn+EVH82GEsce1ADWb705a0Y3rfHO9E87xRntL0fVH6+xwEjZv/tAYnx81pVdvFQoMVoqHhrjV ZArm051pcLfaGXVp8fU1Ccs1BsPhpWDz47lHXFF/wTNKQxTpU5CUifYKGaFtw/xZzWCgbtquC6LF YwFYq9cGoYyWrfXO/wDtf5Pw/NHzZw1o1KbuK3R5S+1G+dLeayFusU0Eo7+32F21JFFo8WtLytG3 +0/sbVln68MpWGh4xenLv1p6l7+aMAigDer9hd7vXzj7+9G2eT7CJvinMf2t/9oADAMBAAIRAxEA ABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACIAAAAAbKAAAAAAAE8AAAAAMebYAAADX3EAAAAAQOQ1eAADIOdAAAAAAC06p5kZlLkxgAAAAAAU No8HggAAAAAAAAbQs3755sEAAAAAAAK+CFB4WgczSAAAAAAwKtUADmrOHAAAAAAbgASoAADtAAAA AAAaAACIAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/2gAIAQEDAT8Q/pZwSLoREKEg6m1Hzyq2qVgLaHqM IdMil2lXlAgUgwnkO4KIvmCDueuWNQUAJVeAUX1UlMJB3JObVpIncgDyPponGq6gEI55nCgA0pJ9 SlBhHZKdiZ8IRonpGF5SjVoRRRTBXxN5KzpNJN/gT1APRU6z4gryQFpv3xKHOMegbooFQK22C7U0 Gh+DbMbzQsrSBU3Lp6Go0XaHkeBFaaCNWnRhxBBRLhkIaCGUkTeaMLR6/wDT1DCnBxB0RzTwonJJ SSXgr0M1j6+QAu7cU8VzPjSALw1KhwVjC8BudGlS9rcubudJpAMjJ7yHSaGCwv7Yg0VFGHOdo9pr vxMd6Hx9X6QIqw0oUWBzLIVCc84LUQS6kx7jC0zfe8ITea4IqVh840l5EDRBaJlA93YpoJDF+6Qf WAksKAdEbNEQmsgct4LqIXbhdtVKJ/ad5QyEcqPBYkx8v3UbGhKQ7ZXRQ0YAmBe6PRoUjfOlknir UW647lCt8xI5iHWhKwge7sQ1WmcZAUiQETDNPROqgBlbIObSs+TCBBQ7E4406YGNJ9E6lVsgoYHw 0jUnCKeDRugyQ01SlenhUn/ljN5tih5JiGQ0Rqy1k9eIyoLuI1rLUki5NFIRyptgQ2DIPBgnt6ww vg5x3AjSrN6wvEqakl3UVUC6GApYygeBeWkqAmQsMgBFpQjehJoZT7vhpQGmvhItMPmR5mRWlCTT g0wAAIApnCGwlbYmXbabcTiBfanEL3XUizQa4A4YDSFjp9WMeq/ZNWcI9oeIHahtBAIWlcNmQuIp IELkevYBJYcRdq8+OCbII4RGRpbBIoJMAmQWkATQh2RCAKhIJhneokwhhpJ+BKxTYxSKcjiK2dLm qypW65aLmgM2BWclscqRLA2BeslQMONYnYz5pLJ258EKXhe9O6k7VHt2iPgtDiNWmRUXTz+aAFc8 T3JKOgbik8evLKUzR8lCTRKBhL1POyRIRcKXsbhMwINU3S2WjprQR+TymgDBESUHOUWJDRHbajoA oFEaAQYCktjodVVgQES4onuGIzRkEIBaWh0zDEMbojqFIDRC5+z0JcaeVZKgzxvXanc07K7Y6X1V AABrlKEUXMr2IWVYpC8PBvC0bLIELszC0RpQUoGK1Sgl9MpIzaDFGETYDyunvUcHOkPF/eobK6D9 klDybuh9vUhRxXHKJC6BOGYq2QYwMtCS2gDBTVCEAfUJF4uhM6ZI07DZ7vGpwUW7f8HVUN1xs02R Pacqh4nDTaNJ6lJUUlUCpVVYTtX0CDZxUg9EAptJE1i4o5jrXmkoIMAB0gB6mloz54jYPdUJD1r3 TSFxqmkiYGM6WokHO2EU5KIHa4cDdZ5NDRE+sdAA6A9QA50YUEIjkaEWVQtCM7lI43MrBXdx704S yZzcaPgDgD2+hL7iQBCI2RKOMgmLVI4BZrY3pFOBgj8IDIbksh9KlSyYPRoAis65rMTxQgOyzbcm oroKmhT1pY4LbHr6nrwBMFJSdzIRZGH1oeksBtiI+pRLComgCwMmCgWOaWWB3LmSxT7eLkSIWigB G4iSIilQqZZGrPKLoC7RH9a//9oACAECAwE/EP6WQBy4p9SKiofsYnshIMWcdDV6FPp2sJ41qw5Y 8UTPKa7VC4gnImJ3EoUwbK3/AGOpREyOr2qKB2N3mKj0U2FilrQ0m9DJJSBUpDVfB+3Zp6yWwCWf h61KLJA2h0v/AMqYVOa3MtWjjuWazl1We9MyXmHb/VRYPE/DvFTIEdT60GzQOp+daALy3Lj0341K AnJonSTWM3rAPhCiLi9R6+YIeFqJnPOiosdyt0e52pCWHUPN1AzODU65HSaj83rv+daSoCUE4qKi kpjSg3DeCbmeZeil1AaOWvtXmsKVcL4k9ooGbTRQ6jU8EXT9l2o+wzBDwtSZJ96kt1P9opYvzSJ6 1pR4BXnb3UEs8Qj4Ui3IgHi/imoA/hooyRJGjbxURfKDli8c/tGfJfLpQn+Y1airTxxRch5KflHz FOt3ysIPI/NKcyOp5VYieKfNTcdIX+yosQeEfCaeFEuL3UNJDgz7fYEEa10K3Ln+W/gBA61nm/C9 ameT2rHkvH4q42fxir+kt34pBIcVl4crV/pU7YDZLsUSBwZbXX/tJbm4E70YpI6vJ+6EYhlAfzrQ cohENpdWoqKj1UDNTcqfWPar4Dcalph3Q9NPegoMd2/dU/U1M2iUvXrRhyupMi6E+WfFbRzSfN6A gHIRS3Hb+V9W94fnCp+uPrwRUnuqfXZLZoJl9eEfcq/rb//aAAgBAwMBPxD+lo3IJSwffgrBQ3IB Lrd8YKfT3Ly/M6cqCAJsnw/SibPyPa9NtPPIWmN6AZbcu7DSFgHD4rInpRgHiHsM1AkcRpRRv+AQ /fSmZGLC0eNPqoqZwLHn9VISAxkC8G8d6mwNxOHJvWeK0WfergEPb/GlcSUow5qPqlircYoSweOe 5+5pegaP+7dKhevFk7tdoDVqhdwNQm7ztypRUesKMlR4hcF5udGrGr5Ls3966cHXuvRERFCz4fk9 qm28/Py9LwIalU6UZqKDQq5We0Z4IkzGaQwWFzOAxtDO2mWiad4OHTHKrCMbQ900wjosv3QsIbgP tfxQ8PBcRdKPrijJUaQXBd/lUc48M9R+k1cRPjLpY0kmGS4naeHflS7png/NZv6nxWIKZxo2MIB2 InE8/FOMYyvG7N3hSz9nzkeKM9X6ptRSUFTFEoPodmaJ5N8h7VbWuCfI8xU2K4I1pNaUdvisVDl+ FZgnOtsnZ/TemSZKsiR9gpDSlBLEvPlx95pKEnVpG9XZuQvl6FFyVt/0PinmwbfNJxd4Y71YZhsf Oamwrcs1Zxnb93yocdZ0GIk3CdGj3o1nDUD4eaSejBf081AkZufufui5iuMvaYoRKTKEDrRsx64k XOxUK7falZXbvY39qtVy3/X5ipAJtD3c+1PZjbTt9ZKGOgsdqKQM6hDk/wCV4kmerXsUUTTZfZdR kFyEUFgSCxewa9fsHHd7t+vvNPrWYhssO0qKDKVxEzGTpp9gWsVnl/maiLLj/a3/2Q== ------_=_NextPart_000_01C2220F.FDF5E680-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jul 7 12:53:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26236; Sun, 7 Jul 2002 12:53:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14776; Sun, 7 Jul 2002 12:52:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06543 for ; Thu, 4 Jul 2002 15:36:12 -0400 (EDT) Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23428 for ; Thu, 4 Jul 2002 15:35:22 -0400 (EDT) Received: from miki2 (151.26.169.95) by smtp1.libero.it (6.5.015) id 3CFC3E5B00D347A1 for dhcwg@ietf.org; Thu, 4 Jul 2002 21:35:41 +0200 Message-ID: <001201c22392$5472c400$5fa91a97@miki2> From: "Michele Dapporto" To: Date: Thu, 4 Jul 2002 21:38:06 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C223A3.15223540" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [dhcwg] questions about dhcp Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C223A3.15223540 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable my name is Michele Dapporto and I'm a student in engineering at the university of Bologna, in Italy. I'm preparing my graduation thesis on DHCP, and while I was looking for information about this protocol I found RFC 2131 on www.ietf.org. It has been very useful for me and I've found a lot of info on it. Now I'm writing you to ask you some other information. I'd like to find some historical information about when DHCP was born, = and about who has worked to produce it. It would be a very important part of my thesis. If you can't give me this informations, I'd like to know where I can find something about it. I thank you in advance for the time that you'll spend for me. Thank you. Michele Dapporto. ------=_NextPart_000_000F_01C223A3.15223540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
my name is Michele Dapporto and I'm a = student in=20 engineering at the
 university of Bologna, in Italy.
I'm = preparing my=20 graduation thesis on DHCP, and while I was looking=20 for
information
 about this protocol I found RFC 2131 on = www.ietf.org.
It has been very = useful for me=20 and I've found a lot of info on it.
Now I'm writing you to ask you = some other=20 information.
I'd like to find some historical information about when = DHCP was=20 born, and
 about who has worked to produce it. It would be a = very=20 important part
 of my thesis.
If you can't give me this = informations,=20 I'd like to know where I can
 find something about it.
I = thank you in=20 advance for the time that you'll spend for me.
Thank you.
Michele=20 Dapporto.

------=_NextPart_000_000F_01C223A3.15223540-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jul 7 13:21:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27164; Sun, 7 Jul 2002 13:21:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15847; Sun, 7 Jul 2002 13:21:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11871 for ; Sun, 7 Jul 2002 12:07:49 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23778; Sun, 7 Jul 2002 12:06:55 -0400 (EDT) Message-Id: <200207071606.MAA23778@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Sun, 07 Jul 2002 12:06:55 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-csr-07.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The Classless Static Route Option for DHCP Author(s) : T. Lemon, S. Cheshire, B. Volz Filename : draft-ietf-dhc-csr-07.txt Pages : Date : 05-Jul-02 This document defines a new DHCP option which is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client. The network destinations in these routes are classless - each routing table entry includes a subnet mask. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-csr-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-csr-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-csr-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: <20020705141442.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-csr-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-csr-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020705141442.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jul 7 13:22:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27187; Sun, 7 Jul 2002 13:22:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15879; Sun, 7 Jul 2002 13:21:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11826 for ; Sun, 7 Jul 2002 12:07:46 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23768; Sun, 7 Jul 2002 12:06:53 -0400 (EDT) Message-Id: <200207071606.MAA23768@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Sun, 07 Jul 2002 12:06:53 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-concat-04.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --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 : Encoding Long Options in DHCPv4 Author(s) : T. Lemon, S. Cheshire Filename : draft-ietf-dhc-concat-04.txt Pages : Date : 05-Jul-02 This document specifies the processing rules for DHCPv4 options that appear multiple times in the same message. Multiple instances of the same option are generated when an option exceeds 255 octets in size (the maximum size of a single option) or when an option needs to be split apart in order to take advantage of DHCP option overloading. When multiple instances of the same option appear in the options, file and/or sname fields in a DHCP packet, the contents of these options are concatenated together to form a single option prior to processing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-concat-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-concat-04.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-concat-04.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: <20020705141432.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-concat-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-concat-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020705141432.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jul 8 09:12:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13168; Mon, 8 Jul 2002 09:12:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15127; Mon, 8 Jul 2002 09:10:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15043 for ; Mon, 8 Jul 2002 09:10:44 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12981 for ; Mon, 8 Jul 2002 09:09:50 -0400 (EDT) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-101.cisco.com [161.44.150.101]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA18681 for ; Mon, 8 Jul 2002 09:10:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20020702121157.00b3a1b8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 08 Jul 2002 08:15:00 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call for "DHCP Lease Query" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Announcing the WG last call for "DHCP Lease Query", . If you have any comments about this I-D, please respond to dhcwg@ietf.org, preferably before the DHC WG meeting in Yokohama on 7/16. The last call discussion will close on Monday, 7/22/2002. - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jul 8 09:12:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13191; Mon, 8 Jul 2002 09:12:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15074; Mon, 8 Jul 2002 09:10:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15033 for ; Mon, 8 Jul 2002 09:10:43 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12980 for ; Mon, 8 Jul 2002 09:09:50 -0400 (EDT) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-101.cisco.com [161.44.150.101]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA18678 for ; Mon, 8 Jul 2002 09:10:11 -0400 (EDT) Message-Id: <4.3.2.7.2.20020702121118.00b3a1b8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 08 Jul 2002 08:11:00 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call for "Dynamic Host Configuration Protocol (DHCP) Server MIB" (reminder) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Announcing the WG last call for "Dynamic Host Configuration Protocol (DHCP) Server MIB", . If you have any comments about this I-D, please respond to dhcwg@ietf.org, preferably before the DHC WG meeting in Yokohama on 7/16. The last call discussion will close on Monday, 7/22/2002. - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jul 8 09:12:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13214; Mon, 8 Jul 2002 09:12:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15094; Mon, 8 Jul 2002 09:10:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15035 for ; Mon, 8 Jul 2002 09:10:43 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12979 for ; Mon, 8 Jul 2002 09:09:50 -0400 (EDT) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-101.cisco.com [161.44.150.101]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA18675 for ; Mon, 8 Jul 2002 09:10:11 -0400 (EDT) Message-Id: <4.3.2.7.2.20020702110124.01cb6db8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 08 Jul 2002 08:04:00 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Request for agenda items (reminder) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Please forward request for agenda slots to me by Tuesday, 7/9. We have the following items on the agenda: Review of DHCPv6 status and changes based on IESG review Discussion of revised charter - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jul 8 09:15:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13428; Mon, 8 Jul 2002 09:15:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15557; Mon, 8 Jul 2002 09:16:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15536 for ; Mon, 8 Jul 2002 09:16:07 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13395 for ; Mon, 8 Jul 2002 09:15:14 -0400 (EDT) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-101.cisco.com [161.44.150.101]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA18951 for ; Mon, 8 Jul 2002 09:15:35 -0400 (EDT) Message-Id: <4.3.2.7.2.20020708091458.01da83a0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 08 Jul 2002 09:15:30 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Request for agenda items (reminder) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Please forward request for agenda slots to me by Tuesday, 7/9. We have the following items on the agenda (updated): Review of DHCPv6 status and changes based on IESG review Discussion of revised charter DHCP Option for CableLabs Client Configuration - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jul 10 05:14:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25460; Wed, 10 Jul 2002 05:14:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA09492; Wed, 10 Jul 2002 05:13:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA09467 for ; Wed, 10 Jul 2002 05:13:55 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25433; Wed, 10 Jul 2002 05:13:01 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-114.cisco.com [10.82.240.114]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id FAA24599; Wed, 10 Jul 2002 05:13:23 -0400 (EDT) Message-Id: <4.3.2.7.2.20020710050616.00bb0558@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 10 Jul 2002 05:13:18 -0400 To: dhcwg@ietf.org From: Ralph Droms Cc: agenda@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Agenda for WG meeting in Yokohama Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Here is the tentative agenda for the DHC WG meeting in Yokohama: DHC WG status report DHCPv6 status and update draft-ietf-dhc-dhcpv6-26.txt DHCP Option for CableLabs Client Configuration draft-ietf-dhc-packetcable-02.txt RFC 2563 deprecation draft-droms-rfc2563-deprecate-00.txt DHCP Server MIB last call draft-ietf-dhc-server-mib-06.txt DHCP Lease Query last call draft-ietf-dhc-leasequery-03.txt IPv6 Prefix Options for DHCPv6 draft-troan-dhcpv6-opt-prefix-delegation-01.txt DNS Configuration options for DHCPv6 draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt NIS Configuration Options for DHCPv6 draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Time Configuration Options for DHCPv6 draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt DSTM Options for DHCP draft-ietf-dhc-dhcpv6-opt-dstm-01.txt Discussion of revised WG charter --- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jul 14 18:32:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19170; Sun, 14 Jul 2002 18:32:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09507; Sun, 14 Jul 2002 18:29:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09479 for ; Sun, 14 Jul 2002 18:29:15 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19077 for ; Sun, 14 Jul 2002 18:28:20 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-251.cisco.com [10.82.240.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA23544 for ; Sun, 14 Jul 2002 18:28:44 -0400 (EDT) Message-Id: <4.3.2.7.2.20020711054826.03391d98@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 14 Jul 2002 10:35:17 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Re: WG last call for "DHCP Lease Query" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org RIch and Kim, The items in this bullet list are more substantive, while the remaining items are mostly editorial and listed in order of appearance in the draft... * This draft proposes extending and overloading the Requested IP Address option to carry IP addresses in leasequery messages. Now that the pressure on new option codes in DHCPv4 has eased up, we should consider defining a new option (we could even assign it the unused failover option code) rather than reusing the existing option. * I would prefer to see all the messages used with leasequery transactions renamed to uniformly use the prefix DHCPLEASE. This isn't as silly as it might sound; using names like DHCPLEASEKNOWN would point out relationship among the messages, and leave us room for the name for another message about knowing something in DHCP (DHCP * Details in Section 5, Protocol Overview, are repeated in section 6. It would be better to leave the details out of section 5 to avoid potential confusing or contradictory specification. For example, the first bullet item in Section 5 could be edited to: o Query by IP address: For this query, the requester supplies 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. The DHCP server replies with a DHCPKNOWN or DHCPACTIVE message if the IP address in the DHCPLEASEQUERY message corresponds to an IP address about which the server has definitive information (i.e., it is authorized to lease this IP address). The server replies with a DHCPUNKNOWN message if the server does not have definitive location information concerning address in the DHCPLEASEQUERY message. Section 1, last paragraph: What do DHCPKNOWN and DHCPUNKNOWN do? Section 2, definition of "reservation": clarify by inserting the following sentence before the last sentence in the definition: A reservation defines a mapping between a client and an IP address but doesn't establish or record a lease for the address. Section 3, third paragraph: why is "DHCPACTIVE" not mentioned in the parenthetical phrase? Perhaps simply drop the parenthetical? Section 5, paragraph 4: why is "(and are expected to)" included after SHOULD? Can you give guidance about when a server might send the DHCPUNIMPLEMENTED message instead of silently discarding the DHCPLEASEQUERY message. Also, for consistency, in the same sentence replace "Servers which do not support..." with "Servers that do not implement..." Section 5, last paragraph: why is saving the Relay Agent Information option called out specifically here? Shouldn't this be a MUST for the specific use by access concentrators in reconstructing location information? Also in this paragraph, why is the vendor-class-identifier option mentioned? I don't see it mentioned elsewhere in the document. Section 6.1, in the first numbered list change "three" to "four" in item 1. Section 6.2, 1st bullet list, 2nd bullet: under what circumstances will a requester not include a parameter request list option? What will be the consequences if the option is not included - will the server return no options, all options, a subset of options the server thinks is interesting? Section 6.2, next to last paragraph: what does ""ciaddr" field mentioned in the DHCPLEASEQUERY message [...] is a local subnet of the interface specified for the client" mean? Section 6.3, last paragraph: any reason not to simply write: The 'giaddr' field MUST contain a valid IP address assigned to the relay agent that sent the DHCPLEASEQUERY message. Section 6.4, DHCPKNOWN bullet: the first paragraph says the R bit MAY be set, the second paragraph says the R bit MUST be set and the third paragraph says the R bit "is set"; those three statements seem contradictory. The three paragraphs also contain significant repeated information. Section 6.4: I think the last paragraph of section 6.4 should be moved to be the first paragraph of 6.4.1. The paragraph in question specifically addresses the topic of 6.4.1 - determining which IP address to respond to. Section 6.4.1, paragraph 7: add "address" after the first occurrence of "IP". Section 6.4.2, paragraph 6: what does "set from the client" mean? "Set to the MAC address belonging to the client"? Section 6.4.2, paragraph 7: replace "DHPC" with "DHCP" Section 6.4.2, paragraph 8: here, as well as elsewhere, the document mentions "IP [BTW, insert "address" here] has been accessed by the client". What does "accessed by the client" mean? The address has been involved in a DHCP message exchange? And, *please*, don't use "IP" for "IP address" (shudder). Section 6.4.2, paragraph 9: doesn't the use of DHCPKNOWN and DHCPACTIVE differentiate whether there is a valid lease for the client? Section 6.4.2, paragraph 10: the first sentence says "if the R bit is set in the DHCPLEASEQUERY", while earlier, section 6.4.1 says "the Reservations bit (the R bit) has no meaning in the DHCPLEASEQUERY message."; these two bits of text seem contradictory. Section 6.5, the explanations of the contents of the various messages are redundant and could be elided (e.g., the first sentence of the first paragraph). In the second paragraph, perhaps I'm being dense or it's late or I'm still recovering from flying to Japan - how does an access concentrator use DHCPKNOWN to accomplish the good stuff in the last sentence? And is caching the DHCP server information a SHOULD? Why would the access concentrator use that information and under what circumstances would it not cache the information? Section 6.5,, paragraph 4: add "does" between "server" and "not" in the first paragraph. Section 7: I thought I read at one point, but can't find it now, a suggestion that a DHCP server be configured with the addresses of the relay agents from which it would accept DHCPLEASEQUERY messages as a security measure. My apologies if the text is in the draft and I missed it; if I'm hallucinating, would the suggestion make any practical and useful sense? Section 11: Some of this information is stale (mea culpa for taking so long to do the last call)... _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jul 14 19:04:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20142; Sun, 14 Jul 2002 19:04:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11527; Sun, 14 Jul 2002 19:02:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11506 for ; Sun, 14 Jul 2002 19:02:17 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20043 for ; Sun, 14 Jul 2002 19:01:21 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-251.cisco.com [10.82.240.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA24366 for ; Sun, 14 Jul 2002 19:01:46 -0400 (EDT) Message-Id: <4.3.2.7.2.20020714183621.03a7c3a8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 14 Jul 2002 19:01:40 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Re: Revised charter for DHC WG Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Here's a summary of comments received about the draft charter for the DHC WG. We're going to discuss the charter at the DHC WG meeting in Yokohama, Tue 7/16 9AM JST. Please review the comments and, if you don't plan to be at Tuesday's meeting, respond either to the mailing list or to me privately, so we can get your input foe the WG discussion. -Ralph Dynamic Host Configuration (dhc) Description of Working Group: This working group has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCP is currently a "Draft Standard" (RFC2131, RFC2132). The working group now has the following primary objectives: * Develop additional authentication protocols within the framework defined in RFC3118, along with other mechanisms to mitigate the threat of attacks on DHCP clients and servers: - New RFC3118 protocols to address improved key management and improved scalability Should the charter be more specific here. What new protocols are needed? What problems need to be solved? The above is just a blank check to do unspecified work (not good). - Provide security for messages passed between relay agents and servers - Consider solutions for specific threats such as use of nonce identifier to defend against DoS attacks through FORCERENEW from off-path attackers This might be good, but it seems like a prerequisite is to have a documented threat analysis. What are the primary threats to DHCP? Which ones are the ones that are important to address? Only then does it make sense to think about specific solutions. * Complete the specification of DHCP for IPv6 (DHCPv6): - Gain acceptance and publication of current Internet Draft as Proposed Standard - Encourage independent implementations and conduct interoperability testing Does this needs to be called out in the charter? WGs don't do interoperability testing per se. But interoperability reports are needed for advancing documents along the standards track. On the other hand, it may well be in the WG charter to publicize the status of new standards and encourage interoperability testing. Finally, there was a third opinion that organization of interoperability testing outside the IETF is a measure of interest in the protocol. If interoperability testing doesn't take place without encouragement, there may not be widespread interest in the protocol. - Revise specification and publish for acceptance as Draft Standard by 6/30/2002 - Develop extensions to DHCPv6 for prefix delegation, DNS configuration, etc. - (Additional item) Determine the requirements for DHCP to support the dynamic renumbering of networks using fast path delegation as CPE front end between ISP and Private Networks. Is the development of IPv6 functions in DHCP a good thing for the DHC WG to take on in its charter?. Should the WG stick with its core expertise, which is the DHC core protocols, and review options motivated from outside the WG from the perspective of being consistent with standard DHC operating practice. Does defining new options require significant input AND MOTIVATION from the customers of the option? In the case of Prefix delegation, that seems like a broader problem, where a DHC solution might well be appropriate. But I don't think this should be driven by the DHC WG, since the problem is not inherently a DHC problem. Does the DHC WG really have the expertise to do the prefix delegation work? The WG members do have expertise to review any options once it is determined what the prefix delegation solution requires. Perhaps better charter wording would say that the WG will review options whose impetus comes from other WGs. A number of the specific options mentioned above are really motivated by other WGs. * Revise and submit the DHCP specification for acceptance as a Full Standard If there is no realistic plan for doing this, it should be left out of the charter. The charter should not be a kitchen sink of all possible work items. It should capture the priority items the WG will work on over the next 12 months. One can easily recharter if something interesting pops up that should get attention. There was another opinion expressed that if moving to Full Standard is not in the charter, it won't happen. (Note from WG chair - this *draft* charter is intended as a starting point for discussion; it's expected that the WG will drop some items and perhaps add others to this draft.) * Complete the specification and publish work in progress as standards: - Failover protocol - DHCP/DDNS interaction - SNMP MIB What is the MIB item? Do we really need it? The WG has been polled several times about this item, and every time has expressed the desire to continue work on the DHCP server MIB specification. - Other client and relay agent options * Review new options for DHCP, as deemed appropriate by the working group chair and/or the Internet area directors _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jul 14 19:07:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20240; Sun, 14 Jul 2002 19:07:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11711; Sun, 14 Jul 2002 19:05:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23456 for ; Tue, 9 Jul 2002 06:54:50 -0400 (EDT) Received: from gausv056.nibweb.co.za (gausv056.nib.co.za [163.201.45.25] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19149 for ; Tue, 9 Jul 2002 06:53:53 -0400 (EDT) Received: from gausv050.nibweb.co.za (unverified) by gausv056.nibweb.co.za (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Tue, 9 Jul 2002 12:54:07 +0200 Received: by gausv050.nib.co.za with Internet Mail Service (5.5.2653.19) id <3NZPWJGH>; Tue, 9 Jul 2002 12:54:07 +0200 Message-ID: <7A79245938D9D511BADB00B0D020B5A801B8C477@gausv050.nib.co.za> From: "Serra S. (Steven)" To: dhcwg@ietf.org Date: Tue, 9 Jul 2002 12:54:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [dhcwg] Intresting but painful Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hi, I have the following issue... 2 locations, 2 different networks each with their own dhcp server.. loc1 is 194.217.0.0 loc2 is 163.201.0.0 Mobile users travelling between the 2 sites are getting error mesaages about not been able to renew lease, now this is ovious as once pc has moved to another network initial server that issued ip cannopt be reached...my question is this, surely after the attempt at retrieving renewal from the server that issued the ip, the client should broadcast thru its local interface on the network for a dhcp server get a nack and then go into discover mode, getting a new ip on the new network. This is not happening, server is not issueing an ip, user's pc lands up doing the randon ip thing and of course nothing works.....Anyone that can help !!!! Thanks Me. EMAIL DISCLAIMER : THIS E-MAIL AND THE INFORMATION THAT IT CONTAINS MAY BE CONFIDENTIAL,LEGALLY PRIVILEGED AND PROTECTED BY LAW. ACCESS BY THE INTENDED RECIPIENT ONLY IS AUTHORIZED. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and attachments created by us belongs to Nedcor Investment Bank Limited. Any views expressed in this communication are those of the individual sender except where the sender specifically states them to be the views of Nedcor Investment Bank Limited. Except as required by law, Nedcor Investment Bank Limited does not represent, warrant and/or guarantee that the integrity of this communication has been maintained nor that the communication is free of errors, virus, interception or interference. Nedcor Investment Bank Limited is a registered bank and is regulated by the Banks A! ct of 1990. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jul 15 23:08:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26977; Mon, 15 Jul 2002 23:08:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA16687; Mon, 15 Jul 2002 23:07:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA16662 for ; Mon, 15 Jul 2002 23:06:58 -0400 (EDT) Received: from snowmass.tci.com (coral.tci.com [198.178.8.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26941 for ; Mon, 15 Jul 2002 23:06:01 -0400 (EDT) Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id g6G36siA025747; Mon, 15 Jul 2002 21:06:55 -0600 (MDT) Received: from 147.191.89.201 by mms01-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Mon, 15 Jul 2002 21:06:47 -0600 X-Server-Uuid: 90826C58-91B0-45EB-95A5-46B6D42E456F Received: by entexchimc02.tci.com with Internet Mail Service ( 5.5.2653.19) id <3S6CBDVV>; Mon, 15 Jul 2002 21:06:47 -0600 Message-ID: <518E23226CAFD211858C0008C7F9548E19C3B699@neexch01.broadband.att.com> From: "Woundy, Richard" To: dhcwg@ietf.org cc: "Ralph Droms" , "Doug Jones (E-mail)" , "Woundy, Richard" Subject: RE: [dhcwg] WG last call for "Dynamic Host Configuration Protocol (DHCP) Server MIB" (reminder) Date: Mon, 15 Jul 2002 21:06:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 112D524D1250326-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Here are some MIB-related comments on draft-ietf-dhc-server-mib-06.txt. I am willing to work with the draft authors to address these issues. While I am not a MIB doctor, I have had a little previous experience with getting a MIB published by the IETF in the last few years. 1. This draft needs to conform to the boilerplate for IETF MIBs, . Note that the boilerplate includes a mandatory SNMP Management Framework section and mandatory References items. 2. This draft needs an updated Security Considerations section, to conform with the Security Guidelines for IETF MIBs . It looks like this section text did conform to these guidelines when the MIB included read-write/read-create objects, but since all objects have been redefined to be read-only, the boilerplate text is not quite correct. 3. The MIB doctor is likely to insist that this MIB avoid the use of the "DisplayString" SYNTAX (e.g. "DhcpLabel" and "serverSystemDescr"). They recommend the use of the "SnmpAdminString" SYNTAX as defined in RFC 2571. 4. The MIB doctor will likely strongly urge that this MIB avoid the use of the "IpAddress" SYNTAX (e.g. "serverSubnet" and "serverSubnetMask"). They recommend the use of the "InetAddress" and "InetAddressType" SYNTAX as defined in RFC 3291 (which obsoletes RFC 2851). Note that the textual conventions in RFC 3291 apply even to MIBs with IPv4 specific tables, such as this MIB. You should consider using the new "InetAddressPrefixLength" SYNTAX for the subnet mask objects (e.g. "serverSubnetMask" and "serverRangeSubnetMask"). You should add new objects with the InetAddressType syntax that provide context for the InetAddress objects -- note that this activity will impact the indexing of several tables, e.g. serverSubnetTable and serverRangeTable. Finally, you should add compliance statements to clarify that the IP address objects in this MIB are expected only to be IPv4 addresses; for example: somethingCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement of the something MIB." MODULE -- this module MANDATORY-GROUPS { somethingGroup } OBJECT somethingAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT somethingAddress SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." ::= { somewhere 2 } 5. The MIB doctor is likely to insist that this MIB include DHC working group information in the CONTACT-INFO clause in the MODULE-IDENTITY: working group mailing list information, how to subscribe, where the archives are kept, working group chair, and his contact information. In the case of this MIB, you might add this text: IETF DHC Working Group General Discussion: dhcwg@ietf.org Subscribe: http://www1.ietf.org/mailman/listinfo/dhcwg Archive: http://www1.ietf.org/mailman/listinfo/dhcwg Chair: Ralph Droms, rdroms@cisco.com 6. The MIB doctor is likely to insist that this MIB include a REVISION clause, which is defined in RFC 2578. For example: REVISION "200202141126Z" -- use same timestamp as LAST-UPDATED; I assume GMT ("Z") DESCRIPTION "Initial Version, published as RFC xxxx." -- RFC Editor assigns xxxx On a related note, the timestamp in the LAST-UPDATED clause of the current MIB draft needs to be put into the correct format (as above); see RFC 2578. 7. There are unexplained gaps in the OID numbering of objects in this MIB. In particular, the MIB numbering skips from dhcpCountLeaseQueries, { dhcpCounters 6 }, to dhcpCountOffers, { dhcpCounters 11 }. Are there objects with these OIDs that have been previously implemented but dropped from this MIB draft? If so, perhaps those objects should be added back to the MIB with an obsolete STATUS, to prevent the OIDs from accidental reuse in the future. Otherwise, you might want to renumber the OIDs again. Far worse, I see some OID conflicts. In particular, dhcpCountAcks has OID { dhcpCounters 12 } and dhcpCountNacks has OID { dhcpCounters 13 } -- but dhcpCountKnowns also has OID { dhcpCounters 12 } and dhcpCountUnknowns also has OID { dhcpCounters 13 }. Probably the last two objects should have OIDs { dhcpCounters 15 } and { dhcpCounters 16 }. 8. Has the MIB been compiled with a (picky) SNMP MIB compiler such as SMICng? (Unfortunately, I am still waiting for my present employer to purchase a SMICng license, for my other IETF-related work. Otherwise I would have already volunteered.) 9. I think two DHCP Lease Query-related MIB objects need to be added for the DHCPACTIVE and DHCPUNIMPLEMENTED messages. Note that there are some Lease Query last-call comments (from Ralph) that should be reflected in this MIB as well, e.g. if the DHCP message name changes from DHCPKNOWN to DHCPLEASEKNOWN, then the MIB object name should change from dhcpCountKnowns to dhcpCountLeaseKnowns. The latest draft is draft-ietf-dhc-leasequery-03.txt, by the way. 10. Your reference to draft-ietf-dhc-pv4-reconfigure-06.txt should be updated to RFC 3203. You should also note in the MIB that the value for DHCP option 53 (DHCP message type) to indicate a DHCPFORCERENEW message is 9. 11. One of my motivations for reviewing this MIB (besides the fact that I have lots of deployed DHCP servers in support of cable modem services), is that there are concerted efforts to specify/deploy embedded DHCP servers in cable modems. The folks at CableLabs have a project called "CableHome", -- I am hoping the CDP MIB will leverage this DHCP server MIB in particular. It would be very helpful if the DHCP Server MIB had some read-create tables, since we would need mechanisms to configure a few hundred thousand embedded DHCP servers sometime in the future. If you did add back this capability to the MIB (not sure if there is time or consensus), perhaps the read-create functions would be strictly optional in this MIB (via more compliance statements). -- Rich -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Monday, July 08, 2002 8:11 AM To: dhcwg@ietf.org Subject: [dhcwg] WG last call for "Dynamic Host Configuration Protocol (DHCP) Server MIB" (reminder) Announcing the WG last call for "Dynamic Host Configuration Protocol (DHCP) Server MIB", . If you have any comments about this I-D, please respond to dhcwg@ietf.org, preferably before the DHC WG meeting in Yokohama on 7/16. The last call discussion will close on Monday, 7/22/2002. - 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 Jul 16 05:58:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15566; Tue, 16 Jul 2002 05:58:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17484; Tue, 16 Jul 2002 05:54:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17456 for ; Tue, 16 Jul 2002 05:54:54 -0400 (EDT) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15476 for ; Tue, 16 Jul 2002 05:53:56 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g6G9sqA17396 for ; Tue, 16 Jul 2002 02:54:52 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 16 Jul 2002 02:54:51 -0700 Received: from [133.93.77.116] (vpn-gh-566.apple.com [17.254.138.53]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id g6G9soT18321 for ; Tue, 16 Jul 2002 02:54:50 -0700 (PDT) Message-Id: <200207160954.g6G9soT18321@scv3.apple.com> Date: Tue, 16 Jul 2002 02:54:50 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "DHCP discussion list" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: [dhcwg] Review of Service-Discovery-Type options in DHCP Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org At the Yokohama meeting I pointed out that many DHCP options carry information that might be better served via an explicit service discovery mechanism. Thomas Narten pointed out that the IETF community has not arrived at an undisputed consensus about how to do service discovery. I agree with this in the broad sense, but for simple service discovery the world does seem to have arrived at an ad-hoc) solution -- functional hostnames in DNS. Common practice is that most companies have a hostname of the form "www.company.com." which resolves to the address of the company's web server. Similar examples are: ntp.company.com. (NTP Time Server) mail.company.com. (Incoming mail) smtp.company.com. (SMTP relay for outgoing mail) pop.company.com. (POP mailbox host) imap.company.com. (IMAP mail access) This is an ugly solution for two reasons: 1. It is a misuse of DNS host names to name things that are logical services, not hosts. 2. The names are not standardized -- is it "ntp.company.com.", or "time.company.com." ? Fortunately, DNS already has a solution that addresses these two deficiencies: SRV records 1. SRV records explicitly names services, not hosts, and 2. SRV records have a formalized naming convention -- the name of the SRV record for NTP service at "company.com." is "_ntp._udp.company.com." The only missing piece of information that the client need to learn is the "company.com." component of the service names it should be looking up. Perhaps the existing DHCP "Domain Name" option (option code 15) meets this need. If you bring your laptop to Apple, and boot it using DHCP, then the DHCP "Domain Name" option will say, "apple.com.", and you can find: 1. A time server by looking up SRV record "_ntp._udp.apple.com." 2. An SMTP relay by looking up SRV record "_smtp._tcp.apple.com." The people at the Apple offices in Europe get a DHCP "Domain Name" option which says, "euro.apple.com.", and they find services by looking up names like: "_ntp._udp.euro.apple.com." and "_smtp._tcp.euro.apple.com." If not the existing "Domain Name" option, perhaps the "Domain Search List", or something like it, is the right answer. That way, a single DHCP option points you to the place in the DNS name space where all your SRV records can be found, instead of every service having to have yet-another-separate-option-of-its-own in DHCP. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jul 16 06:22:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16017; Tue, 16 Jul 2002 06:22:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA18717; Tue, 16 Jul 2002 06:20:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA18693 for ; Tue, 16 Jul 2002 06:20:46 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15914 for ; Tue, 16 Jul 2002 06:19:48 -0400 (EDT) Received: from green.bisbee.fugue.com (dechen.dyn.ietf54.wide.ad.jp [133.93.74.182]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g6GAKYd04954; Tue, 16 Jul 2002 10:20:35 GMT Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g6GAKgXU001224; Tue, 16 Jul 2002 19:20:42 +0900 (JST) Date: Tue, 16 Jul 2002 19:20:41 +0900 Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "DHCP discussion list" To: Stuart Cheshire From: Ted Lemon In-Reply-To: <200207160954.g6G9soT18321@scv3.apple.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit What you propose is perfectly workable, but I don't see how it's *better* than what DHCP already provides. That is, we have something that works now. Why is the DNS a better choice as a resource discovery server? I can think of some reasons, but I'm not sure why you think this makes sense, so I'm grasping at straws a bit - the reasons I can think of in favor of DNS are ones you have stated, and I don't have a real problem with them, but I don't find them particularly compelling either. DNS is better: 1. I already have to have a DNS server. With IPv6, I don't have to have a DHCP server. So this is one less thing I have to configure/deploy. 2. DNS servers understand administrative domains, and administrative domains are a good way to determine which clients should use which servers. DHCP is better: 1. DHCP already solves the problem of locating services, so we don't have to kludge something into the DNS namespace. 2. DHCP servers understand the network topology, and topology is a good way to determine which clients should use which servers. 3. You have to have a DHCP server anyway - how are you going to get the IP address of your DNS server? Arguments (1) are true, although I don't find argument 1 for DNS particularly compelling. The other arguments aren't true - they're just opinions, and not necessarily even particularly valid opinions. My feeling here is that using DNS as a server location protocol is chancy at best, and so I don't want to switch from DHCP to DNS, but I can't prove that I'm right on this. Can you come up with a really compelling argument for using one over the other? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jul 16 07:38:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17675; Tue, 16 Jul 2002 07:38:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA22152; Tue, 16 Jul 2002 07:34:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA22128 for ; Tue, 16 Jul 2002 07:34:19 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17621 for ; Tue, 16 Jul 2002 07:33:20 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g6GBXihI013890; Tue, 16 Jul 2002 04:33:44 -0700 (PDT) Received: from JSCHNIZL-W2K1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g6GBXhBL028926; Tue, 16 Jul 2002 04:33:44 -0700 (PDT) Message-Id: <4.3.2.7.2.20020716072110.0183d6e8@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Jul 2002 07:30:09 -0400 To: Stuart Cheshire From: John Schnizlein Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP Cc: "DHCP discussion list" In-Reply-To: <200207160954.g6G9soT18321@scv3.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org At 05:54 AM 7/16/2002, Stuart Cheshire wrote: >At the Yokohama meeting I pointed out that many DHCP options carry >information that might be better served via an explicit service discovery >mechanism. Yes, but where host configuration should be managed by the network operator, DHCP is an appropriate mechanism. Why make it more complicated? >Common practice is that most companies have a hostname of the form >"www.company.com." which resolves to the address of the company's web >server. > >Similar examples are: > >ntp.company.com. (NTP Time Server) >mail.company.com. (Incoming mail) >smtp.company.com. (SMTP relay for outgoing mail) >pop.company.com. (POP mailbox host) >imap.company.com. (IMAP mail access) > >This is an ugly solution for two reasons: >1. It is a misuse of DNS host names to name things that are logical >services, not hosts. >2. The names are not standardized -- >is it "ntp.company.com.", or "time.company.com." ? This is not just common practice it is BCP 17 - RFC 2219, which documents a "sensible set of defaults which may be used as an aid in determining the hosts which offer particular services for a given domain name." John _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jul 16 19:57:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03382; Tue, 16 Jul 2002 19:57:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29989; Tue, 16 Jul 2002 19:57:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29964 for ; Tue, 16 Jul 2002 19:56:58 -0400 (EDT) Received: from manta.infocus.com (moray.infocus.com [209.84.97.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03288 for ; Tue, 16 Jul 2002 19:56:00 -0400 (EDT) Received: by manta.infocus.com (Postfix, from userid 5) id AF22127F77; Tue, 16 Jul 2002 16:56:55 -0700 (PDT) Received: from sonata.infocus.com(200.1.10.70), claiming to be "sonata.infocuscorp.com" via SMTP by manta.infocus.com, id smtpdAAA0rFjQo; Tue Jul 16 16:56:51 2002 Received: by sonata with Internet Mail Service (5.5.2653.19) id <30ZG7K64>; Tue, 16 Jul 2002 16:52:22 -0700 Message-ID: From: Chris Pearson To: "'Ted Lemon'" , Stuart Cheshire Cc: DHCP discussion list Subject: RE: [dhcwg] Review of Service-Discovery-Type options in DHCP Date: Tue, 16 Jul 2002 16:54:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org More DNS is better: 3. DHCP provides no mechanism for a client to request configuration options without also requesting address lease renewal. Lease renewal would be a highly undesirable side-effect of service discovery. 4. Service discover is often initiated by applications (rather than by the IP stack). DNS is an application-level, request-response, protocol that is supported by established APIs. DHCP, on the other hand, is an integral part of the IP stack -- DHCP implementations that I know of don't provide an API. 5. DHCP client requests (DHCPREQUEST) must be subnet-broadcast and perhaps relayed, while DNS queries are unicast. I have to agree that DNS SRV doesn't address topology-based server assignment. -- CCP -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Tuesday, July 16, 2002 3:21 AM To: Stuart Cheshire Cc: DHCP discussion list Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP What you propose is perfectly workable, but I don't see how it's *better* than what DHCP already provides. That is, we have something that works now. Why is the DNS a better choice as a resource discovery server? I can think of some reasons, but I'm not sure why you think this makes sense, so I'm grasping at straws a bit - the reasons I can think of in favor of DNS are ones you have stated, and I don't have a real problem with them, but I don't find them particularly compelling either. DNS is better: 1. I already have to have a DNS server. With IPv6, I don't have to have a DHCP server. So this is one less thing I have to configure/deploy. 2. DNS servers understand administrative domains, and administrative domains are a good way to determine which clients should use which servers. DHCP is better: 1. DHCP already solves the problem of locating services, so we don't have to kludge something into the DNS namespace. 2. DHCP servers understand the network topology, and topology is a good way to determine which clients should use which servers. 3. You have to have a DHCP server anyway - how are you going to get the IP address of your DNS server? Arguments (1) are true, although I don't find argument 1 for DNS particularly compelling. The other arguments aren't true - they're just opinions, and not necessarily even particularly valid opinions. My feeling here is that using DNS as a server location protocol is chancy at best, and so I don't want to switch from DHCP to DNS, but I can't prove that I'm right on this. Can you come up with a really compelling argument for using one over the other? _______________________________________________ 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 Jul 16 20:33:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05037; Tue, 16 Jul 2002 20:33:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02723; Tue, 16 Jul 2002 20:34:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02700 for ; Tue, 16 Jul 2002 20:33:58 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04989 for ; Tue, 16 Jul 2002 20:33:00 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-697.cisco.com [10.82.242.185]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA24832; Tue, 16 Jul 2002 20:33:19 -0400 (EDT) Message-Id: <4.3.2.7.2.20020716202112.0396d470@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Jul 2002 20:33:12 -0400 To: Stuart Cheshire From: Ralph Droms Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP Cc: "DHCP discussion list" In-Reply-To: <200207160954.g6G9soT18321@scv3.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I'm going to pick a small item out of the middle of Stuart's message that caught my attention... At 02:54 AM 7/16/2002 -0700, Stuart Cheshire wrote: >The only missing piece of information that the client need to learn is >the "company.com." component of the service names it should be looking up. > >Perhaps the existing DHCP "Domain Name" option (option code 15) meets >this need. > >If you bring your laptop to Apple, and boot it using DHCP, then the DHCP >"Domain Name" option will say, "apple.com.", and you can find: I have always thought of the "Domain Name" option as specifying the domain name that the client should attach to its hostname to form its FQDN. Stuart suggests a somewhat different definition - the "Domain Name" option simply identifies the domain name for the network to which the client is attached. The client can then use that information in any way it wants: to form an FQDN if it needs one, to form service names. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jul 16 22:38:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09439; Tue, 16 Jul 2002 22:38:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10870; Tue, 16 Jul 2002 22:38:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05012 for ; Tue, 16 Jul 2002 11:46:25 -0400 (EDT) Received: from styx.uwaterloo.ca (styx.uwaterloo.ca [129.97.105.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22237 for ; Tue, 16 Jul 2002 11:45:27 -0400 (EDT) Received: from localhost (bmukherj@localhost) by styx.uwaterloo.ca (8.11.6/8.11.0) with ESMTP id g6GFivL17765; Tue, 16 Jul 2002 11:45:00 -0400 Date: Tue, 16 Jul 2002 11:44:57 -0400 (EDT) From: Roop Mukherjee To: Ted Lemon cc: Stuart Cheshire , DHCP discussion list Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org It seems that the problem of service discovery, probably better termed as server discovery, at the moment is simply that of locating a server for a service that a end-node may desire. Locating the address of a server (for time, ftp etc.) is a naming function. That being the case, locating the names of servers seems more up the alley of DNS than DHCP. -- Roop __________________________________ On Tue, 16 Jul 2002, Ted Lemon wrote: > What you propose is perfectly workable, but I don't see how it's *better* > than what DHCP already provides. That is, we have something that works > now. Why is the DNS a better choice as a resource discovery server? I > can think of some reasons, but I'm not sure why you think this makes sense, > so I'm grasping at straws a bit - the reasons I can think of in favor of > DNS are ones you have stated, and I don't have a real problem with them, > but I don't find them particularly compelling either. > > DNS is better: > > 1. I already have to have a DNS server. With IPv6, > I don't have to have a DHCP server. So this is > one less thing I have to configure/deploy. > 2. DNS servers understand administrative domains, > and administrative domains are a good way to > determine which clients should use which servers. > > DHCP is better: > > 1. DHCP already solves the problem of locating services, > so we don't have to kludge something into the DNS > namespace. > 2. DHCP servers understand the network topology, and > topology is a good way to determine which clients > should use which servers. > 3. You have to have a DHCP server anyway - how are you > going to get the IP address of your DNS server? > > Arguments (1) are true, although I don't find argument 1 for DNS > particularly compelling. The other arguments aren't true - they're just > opinions, and not necessarily even particularly valid opinions. My > feeling here is that using DNS as a server location protocol is chancy at > best, and so I don't want to switch from DHCP to DNS, but I can't prove > that I'm right on this. > > Can you come up with a really compelling argument for using one over the > other? > > > _______________________________________________ > 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 Jul 16 23:26:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09438; Tue, 16 Jul 2002 22:38:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10866; Tue, 16 Jul 2002 22:38:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26373 for ; Tue, 16 Jul 2002 18:46:32 -0400 (EDT) Received: from fed1mtao03.cox.net (fed1mtao03.cox.net [68.6.19.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01767 for ; Tue, 16 Jul 2002 18:45:35 -0400 (EDT) Received: from cx369209c ([68.4.132.72]) by fed1mtao03.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020716224557.JHBT1378.fed1mtao03.cox.net@cx369209c> for ; Tue, 16 Jul 2002 18:45:57 -0400 Message-ID: <000701c22d1a$8d65bdd0$48840444@cx369209c> From: "carrslem" To: Date: Tue, 16 Jul 2002 15:45:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Dynamic Address Renewal Failure Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Can someone on this list tell me if there is available a utility which can be run on a DHCP client to log packets addressed to and received from a DHCP server and, if so, where I might obtain it? Or is there, buried somewhere in Windows, a command to do this? I'm running under Win 2000 Pro SP2 and I'm experiencing a consistent, daily failure of the IP address lease renewal (it fails repeatedly until the server-binding timer times out, then succeeds). My ISP is Cox Communication (cable) and so far they have not been helpful. Thank you very much for any help on this. Carroll Slemaker _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jul 17 01:39:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12586; Wed, 17 Jul 2002 01:39:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28861; Wed, 17 Jul 2002 01:39:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28839 for ; Wed, 17 Jul 2002 01:39:06 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12573 for ; Wed, 17 Jul 2002 01:38:07 -0400 (EDT) Received: from green.bisbee.fugue.com (dechen.dyn.ietf54.wide.ad.jp [133.93.74.182]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g6H5cud07602; Wed, 17 Jul 2002 05:38:56 GMT Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g6H5d4XU002318; Wed, 17 Jul 2002 14:39:04 +0900 (JST) Date: Wed, 17 Jul 2002 14:39:04 +0900 Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: DHCP discussion list , Stuart Cheshire To: Chris Pearson From: Ted Lemon In-Reply-To: Message-Id: <811578E2-9947-11D6-8431-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > 3. DHCP provides no mechanism for a client to request configuration > options without also requesting address lease renewal. Lease > renewal would be a highly undesirable side-effect of service > discovery. Not true. DHCPv4 provides DHCPINFORM. DHCPv6 provides Information Request. > 4. Service discover is often initiated by applications (rather than > by the IP stack). DNS is an application-level, request-response, > protocol > 4a. that is supported by established APIs. > 4b. DHCP, on the other > hand, is an integral part of the IP stack -- > 4c. DHCP implementations > that I know of don't provide an API. You are actually making four points here. I agree with (4), (4a) and (4b) , but not (4c). There is no reason not to have an API for DHCP, and there' s no particular sense in which such an API would be more or less good than the common DNS API which, BTW, is not a standard. My reason for disagreeing with (4c), btw, is that in fact every operating system out there except one puts the DHCP client at the application level, not in the stack, and indeed it's an application-layer protocol - it's layered on top of UDP. Ironically, the one operating system where it's easy to use DHCPINFORM is the one where DHCP is in the stack, because a DHCPINFORM client can do a DHCPINFORM without running into the problem of competing with the userland DHCP client in binding to port 68. > 5. DHCP client requests (DHCPREQUEST) must be subnet-broadcast and > perhaps relayed, while DNS queries are unicast. Again, this is almost completely untrue. The _only_ DHCPREQUEST that is ever broadcast is the first one, when the DHCP client has no IP address. Every subsequent DHCPREQUEST is unicast, unless something is wrong (e.g., the DHCP server hasn't responded to unicast renewals for a long time). So I would say that the only substantive argument you've advanced is the lack of an API for DHCP, which I agree is a problem. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jul 17 01:40:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12654; Wed, 17 Jul 2002 01:40:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29026; Wed, 17 Jul 2002 01:40:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29003 for ; Wed, 17 Jul 2002 01:40:55 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12645 for ; Wed, 17 Jul 2002 01:39:56 -0400 (EDT) Received: from green.bisbee.fugue.com (dechen.dyn.ietf54.wide.ad.jp [133.93.74.182]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g6H5eld07611; Wed, 17 Jul 2002 05:40:47 GMT Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g6H5euXU002321; Wed, 17 Jul 2002 14:40:56 +0900 (JST) Date: Wed, 17 Jul 2002 14:40:55 +0900 Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: Stuart Cheshire , "DHCP discussion list" To: Ralph Droms From: Ted Lemon In-Reply-To: <4.3.2.7.2.20020716202112.0396d470@funnel.cisco.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > I have always thought of the "Domain Name" option as specifying the domain > name that the client should attach to its hostname to form its FQDN. > Stuart suggests a somewhat different definition - the "Domain Name" option > simply identifies the domain name for the network to which the client is > attached. The client can then use that information in any way it wants: > to form an FQDN if it needs one, to form service names. > I think Stuart's definition is more generally correct. The only time when the domain name option specifies the client's domain name is when the client doesn't have a domain name that it cares to assert. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jul 17 02:31:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04656; Wed, 17 Jul 2002 02:31:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15199; Wed, 17 Jul 2002 02:32:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15168 for ; Wed, 17 Jul 2002 02:32:19 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04309 for ; Wed, 17 Jul 2002 02:31:22 -0400 (EDT) Received: from green.bisbee.fugue.com (dechen.dyn.ietf54.wide.ad.jp [133.93.74.182]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g6H6WBd08178; Wed, 17 Jul 2002 06:32:11 GMT Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g6H5TcXU002315; Wed, 17 Jul 2002 14:29:38 +0900 (JST) Date: Wed, 17 Jul 2002 14:29:37 +0900 Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: Stuart Cheshire , DHCP discussion list To: Roop Mukherjee From: Ted Lemon In-Reply-To: Message-Id: <2F7FCD64-9946-11D6-8431-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > It seems that the problem of service discovery, probably better termed as > server discovery, at the moment is simply that of locating a server for a > service that a end-node may desire. Locating the address of a server (for > time, ftp etc.) is a naming function. > > That being the case, locating the names of servers seems more up the alley > of DNS than DHCP. This seems to be a statement of opinion. I was looking more for logical arguments - that is, you present *reasons* why you believe that DNS is a better choice than DHCP. I don't see any reasons here - just opinions. I am not saying you are definitely wrong. I just don't see how this statement helps us to decide what to do. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jul 17 07:47:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13365; Wed, 17 Jul 2002 07:47:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA01726; Wed, 17 Jul 2002 07:47:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA01707 for ; Wed, 17 Jul 2002 07:47:10 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13325 for ; Wed, 17 Jul 2002 07:46:11 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g6HBkci21071; Wed, 17 Jul 2002 06:46:38 -0500 (CDT) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g6HBkcV00065; Wed, 17 Jul 2002 06:46:38 -0500 (CDT) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 17 Jul 2002 06:46:38 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D6FF@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Ted Lemon'" , Ralph Droms Cc: Stuart Cheshire , DHCP discussion list Subject: RE: [dhcwg] Review of Service-Discovery-Type options in DHCP Date: Wed, 17 Jul 2002 06:46:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22D87.7574D612" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C22D87.7574D612 Content-Type: text/plain; charset="ISO-8859-1" For service/server discovery via DNS, might not the DNS search list make more sense? In the simplest case, Domain Name = DNS Search List, but in more complex networks that is not the case. Domain name might be division.company.com wereas search list might be division.company.com and company.com. In this case, you'd locate the service whether it was at the division level or corporate level. A mail server might be at the division level. An NTP server might be at the corporate level. This point seems to have little to do directly with DHCP? - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Wednesday, July 17, 2002 1:41 AM To: Ralph Droms Cc: Stuart Cheshire; DHCP discussion list Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP > I have always thought of the "Domain Name" option as specifying the domain > name that the client should attach to its hostname to form its FQDN. > Stuart suggests a somewhat different definition - the "Domain Name" option > simply identifies the domain name for the network to which the client is > attached. The client can then use that information in any way it wants: > to form an FQDN if it needs one, to form service names. > I think Stuart's definition is more generally correct. The only time when the domain name option specifies the client's domain name is when the client doesn't have a domain name that it cares to assert. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C22D87.7574D612 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Review of Service-Discovery-Type options in = DHCP

For service/server discovery via DNS, might not the = DNS search
list make more sense? In the simplest case, Domain = Name =3D DNS
Search List, but in more complex networks that is = not the case.

Domain name might be division.company.com wereas = search list
might be division.company.com and company.com. In = this case,
you'd locate the service whether it was at the = division level
or corporate level. A mail server might be at the = division level.
An NTP server might be at the corporate = level.

This point seems to have little to do directly with = DHCP?

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com]<= /FONT>
Sent: Wednesday, July 17, 2002 1:41 AM
To: Ralph Droms
Cc: Stuart Cheshire; DHCP discussion list
Subject: Re: [dhcwg] Review of = Service-Discovery-Type options in DHCP


> I have always thought of the "Domain = Name" option as specifying the domain
> name that the client should attach to its = hostname to form its FQDN. 
> Stuart suggests a somewhat different definition = - the "Domain Name" option
> simply identifies the domain name for the = network to which the client is
> attached.  The client can then use that = information in any way it wants:
> to form an FQDN if it needs one, to form = service names.
>

I think Stuart's definition is more generally = correct.   The only time when
the domain name option specifies the client's domain = name is when the
client doesn't have a domain name that it cares to = assert.


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

------_=_NextPart_001_01C22D87.7574D612-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jul 17 07:52:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13500; Wed, 17 Jul 2002 07:52:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA01943; Wed, 17 Jul 2002 07:51:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA01924 for ; Wed, 17 Jul 2002 07:51:44 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13453 for ; Wed, 17 Jul 2002 07:50:46 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g6HBpEi22136; Wed, 17 Jul 2002 06:51:14 -0500 (CDT) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g6HBpDf14357; Wed, 17 Jul 2002 06:51:13 -0500 (CDT) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 17 Jul 2002 06:51:13 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D700@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Ted Lemon'" , Roop Mukherjee Cc: Stuart Cheshire , DHCP discussion list Subject: RE: [dhcwg] Review of Service-Discovery-Type options in DHCP Date: Wed, 17 Jul 2002 06:51:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22D88.3EB979B0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C22D88.3EB979B0 Content-Type: text/plain; charset="iso-8859-1" Yes, but the presumes everyone wants to name their service/server the same name. The point of using DHCP is that you don't need to do that since either the DNS name or IP address is provided. Of course, if DHCP isn't available (or the option is configured in DHCP), you might be forced to use a default service name. Also, with a single DNS name, you have less control over what various users use and are forced to use alternative solutions such as load balancing. - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Wednesday, July 17, 2002 1:30 AM To: Roop Mukherjee Cc: Stuart Cheshire; DHCP discussion list Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP > It seems that the problem of service discovery, probably better termed as > server discovery, at the moment is simply that of locating a server for a > service that a end-node may desire. Locating the address of a server (for > time, ftp etc.) is a naming function. > > That being the case, locating the names of servers seems more up the alley > of DNS than DHCP. This seems to be a statement of opinion. I was looking more for logical arguments - that is, you present *reasons* why you believe that DNS is a better choice than DHCP. I don't see any reasons here - just opinions. I am not saying you are definitely wrong. I just don't see how this statement helps us to decide what to do. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C22D88.3EB979B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Review of Service-Discovery-Type options in = DHCP

Yes, but the presumes everyone wants to name their = service/server the same
name.

The point of using DHCP is that you don't need to do = that since either
the DNS name or IP address is provided. Of course, = if DHCP isn't available
(or the option is configured in DHCP), you might be = forced to use a
default service name.

Also, with a single DNS name, you have less control = over what various
users use and are forced to use alternative = solutions such as load
balancing.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com]<= /FONT>
Sent: Wednesday, July 17, 2002 1:30 AM
To: Roop Mukherjee
Cc: Stuart Cheshire; DHCP discussion list
Subject: Re: [dhcwg] Review of = Service-Discovery-Type options in DHCP


> It seems that the problem of service discovery, = probably better termed as
> server discovery, at the moment is simply that = of locating a server for a
> service that a end-node may desire. Locating = the address of a server (for
> time, ftp etc.) is a naming function.
>
> That being the case, locating the names of = servers seems more up the alley
> of DNS than DHCP.

This seems to be a statement of opinion.   = I was looking more for logical
arguments - that is, you present *reasons* why you = believe that DNS is a
better choice than DHCP.   I don't see any = reasons here - just opinions.

I am not saying you are definitely wrong.  I = just don't see how this
statement helps us to decide what to do.


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

------_=_NextPart_001_01C22D88.3EB979B0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jul 17 08:01:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13796; Wed, 17 Jul 2002 08:01:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03029; Wed, 17 Jul 2002 08:01:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03001 for ; Wed, 17 Jul 2002 08:01:40 -0400 (EDT) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13780 for ; Wed, 17 Jul 2002 08:00:42 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g6HC1cA02305 for ; Wed, 17 Jul 2002 05:01:38 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 17 Jul 2002 05:01:37 -0700 Received: from [133.93.77.116] (vpn-gh-1074.apple.com [17.254.140.49]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id g6HC1KT00380 for ; Wed, 17 Jul 2002 05:01:24 -0700 (PDT) Message-Id: <200207171201.g6HC1KT00380@scv2.apple.com> Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP Date: Wed, 17 Jul 2002 05:01:22 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "DHCP discussion list" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org >What you propose is perfectly workable, but I don't >see how it's *better* than what DHCP already provides. My belief is that one of the benefits of IPv6 is that it does automatic address allocation without needing a DHCP server. This is good. This means that your network operations people have one less server to install and configure and maintain. If we make our IPv6 hosts dependent on DHCPv6 servers for lots of critical information that they cannot operate without, then we still need to run a DHCP server and we have lost that IPv6 benefit. Since (a) hosts still need to find out information like "Where's my time server", and (b) in an all-IPv6 world we still plan to run DNS servers anyway, then if we can put information (a) into DNS (b), we can eliminate the burden of also having to install and configure and maintain a DHCP server. Instead of having to communicate arbitrary bootstrap configuration information to hosts, we now just have to communicate the name server address(es) and the default domain, which is a nice simple constrained problem that can be solved in any number of simple ways -- e.g. add that information to Router Advertisement packets. [Of course, I am well aware that this point of view will not be popular with all the people working so hard for so long on DHCPv6. Also, if you have a company that sells a DHCP server, then eliminating the need for DHCP servers is not in your company's best interest. I understand that.] Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jul 17 08:16:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14265; Wed, 17 Jul 2002 08:16:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03646; Wed, 17 Jul 2002 08:16:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03621 for ; Wed, 17 Jul 2002 08:16:30 -0400 (EDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14243 for ; Wed, 17 Jul 2002 08:15:31 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g6HCGSk27253 for ; Wed, 17 Jul 2002 05:16:28 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 17 Jul 2002 05:16:27 -0700 Received: from [133.93.77.116] (vpn-gh-554.apple.com [17.254.138.41]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id g6HCGPT03537 for ; Wed, 17 Jul 2002 05:16:25 -0700 (PDT) Message-Id: <200207171216.g6HCGPT03537@scv2.apple.com> Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP Date: Wed, 17 Jul 2002 05:16:26 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "DHCP discussion list" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org >What you propose is perfectly workable, but I don't >see how it's *better* than what DHCP already provides. My belief is that one of the benefits of IPv6 is that it does automatic address allocation without needing a DHCP server. This is good. This means that your network operations people have one less server to install and configure and maintain. If we make our IPv6 hosts dependent on DHCPv6 servers for lots of critical information that they cannot operate without, then we still need to run a DHCP server and we have lost that IPv6 benefit. Since (a) hosts still need to find out information like "Where's my time server", and (b) in an all-IPv6 world we still plan to run DNS servers anyway, then if we can put information (a) into DNS (b), we can eliminate the burden of also having to install and configure and maintain a DHCP server. Instead of having to communicate arbitrary bootstrap configuration information to hosts, we now just have to communicate the name server address(es) and the default domain, which is a nice simple constrained problem that can be solved in any number of simple ways -- e.g. add that information to Router Advertisement packets. [Of course, I am well aware that this point of view will not be popular with all the people working so hard for so long on DHCPv6. Also, if you have a company that sells a DHCP server, then eliminating the need for DHCP servers is not in your company's best interest. I understand that.] Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jul 17 08:59:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15090; Wed, 17 Jul 2002 08:59:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06262; Wed, 17 Jul 2002 08:58:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06198 for ; Wed, 17 Jul 2002 08:58:52 -0400 (EDT) Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15064 for ; Wed, 17 Jul 2002 08:57:53 -0400 (EDT) Received: from chitha.india.hp.com (chitha.india.hp.com [15.10.43.31]) by atlrel7.hp.com (Postfix) with ESMTP id CC52C8052DF; Wed, 17 Jul 2002 08:58:13 -0400 (EDT) Received: (from jitesh@localhost) by chitha.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id SAA07672; Wed, 17 Jul 2002 18:09:32 +0530 (IST) From: Jitesh N Verma Message-Id: <200207171239.SAA07672@chitha.india.hp.com> Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP To: Bernie.Volz@am1.ericsson.se Date: Wed, 17 Jul 2002 18:09:31 +0530 (IST) Cc: Ted.Lemon@nominum.com, bmukherj@shoshin.uwaterloo.ca, cheshire@apple.com, dhcwg@ietf.org In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D700@EAMBUNT705> from Bernie Volz at Jul "17," 2002 "06:51:11" am X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hi all, Around a year back, I had sent a mail to this mailing list citing that other working groups (like Stateless Autoconfiguration, DNS etc.) are trying to hijack DHCP working group's agenda. Now, I am seeing that fear becoming realty. I just want to raise one point against DNS implementing server location. DNS name resolution is hitting perfomance bottleneck due to large size of database. Sometimes name resolution takes lot of time in larger administrative domain. Customers are craving for better performance. I am sure the load on DNS server will increase in future when number of computing nodes increase. DNS guys are looking for ways to improve performance. Several schemes like database cache, load-balancing have been used in DNS. My point is why to increase load to already overloaded DNS server with extra features (which are already available in DHCP)? Cheers, Jitesh -- ----------------------------------------------------------------------- ~ ~ *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* ^ Jitesh N. Verma Tel. 91-80-225 1554 Ext. 1424 ^ ^ HEWLETT PACKARD Fax. 91-80-220 0196 ^ ^ INDIA SOFTWARE OPERATIONS Email. jitesh@india.hp.com ^ ^ 29, CUNNINGHAM ROAD Pager. 9624-263608 ^ ^ BANGALORE 560 052 __ Telnet. 847-1424 ^ ^ / / ^ ^ / /___ _____ ^ ^ / __ // __ / ^ ^ / / / // /_/ / ^ ^ /_/ /_// ____/ ^ ^ / / ^ ^ /_/ ^ *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jul 17 09:21:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15697; Wed, 17 Jul 2002 09:21:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07966; Wed, 17 Jul 2002 09:20:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27423 for ; Wed, 17 Jul 2002 06:29:59 -0400 (EDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11664 for ; Wed, 17 Jul 2002 06:29:02 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA10126; Wed, 17 Jul 2002 03:29:25 -0700 (PDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g6HATOb25033; Wed, 17 Jul 2002 12:29:24 +0200 (MEST) Date: Wed, 17 Jul 2002 12:28:43 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field To: DHCP discussion list cc: Stuart Cheshire Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Folks, Here's my take on this topic. --- DHCP and DNS are reasonably equivalent for the purpose of service discovery. * DHCP associates a type of service (ie. an option id) with an address. * DNS SRV RRs associate a server name with a host name, and that name, using an A RR, with an address. Both DHCP and DNS are centrally administered, so neither is 'more natural' a place to administer service type to service location mappings, inside a single enterprise. In the Internet as a whole, however, DNS SRV RRs clearly supply a function which DHCP lacks - namely, obtaining the locations of services *in other administrative domains.* --- In dynamic environments, it would be nice if the *availability* of the service would imply its discoverability. SLP achieves this by requiring an agent to 'register' the service when the service is available. When the service goes down, the agent can deregister it, or let the soft-state registration expire. With multicast SLP, agents respond directly - potentially one 'agent' per service (running in a thread of the service process, even). Other possibilities include: * An agent registering the service with an LDAP server using LDAP. * An agent registering the service with DNS using DNS dynamic update of an SRV RR. * A management framework (SNMP, CIM/WBEM, JINI, etc) which allows service information to be made available. The network management protocol can then be used to generate a map of which services are available where, and push this information to clients, somehow. * An agent could respond to 'stateless DHCPv6' requests, as per draft-droms-dhcpv6-stateless-guide-00.txt * An agent could respond to multicast DNS requests for SRV RRs, as per Stuart Cheshire's suggestions (drafts expired) OR draft-ietf-dnsext-opcode-discover-00.txt OR draft-ietf-dnsext-mdns-10.txt In summary, neither DNS nor DHCP have any standard mechanism for supporting dynamic registration of services based upon their availability. One could standardize such a mechanism and the basic mechanisms to support this are already under discussion. --- Other mechanisms, such as LDAP or SLP allow service information to be obtained by a client on the basis of *attributes* and not simply by an id # or service name. For applications which require 'locate-by-characteristic' service discovery instead of 'locate-by-type', DHCP and DNS are not sufficient. Examples of these types of service (for which SLP has *actually been used*) are: * Management agents (which can be managed by a particular kind of manager) * Printers with distinguishing characteristics * File services exported with distinguishing characteristics * Databases with distinguishing characteristics (only certain users or groups can access them) * Coarse grain dynamic load balancing applications (see RFC 3049) --- Using DHCPINFORM, a client can request a particular option. Note however, the DHCPINFORM cannot set the 'lease expiration time.' See RFC 2131, Section 4.3.5. This is unfortunate, as it is useful to tag a cache timeout for service location information. This can be done with DNS SRV RRs (TTL) and SLP (lifetime) or in an LDAP entry (for example, with a 'valid until' timestamp attribute). A DHCP server could use RECONFIGURE to signal DHCP clients to request new service information when necessary, but this only partially makes up for the lack of a time limit on server address options. --- Summary: My feeling is there are many approaches to service discovery being pursued and this is not a service to the user and administrator communities. I believe that while no approach has all the features that everyone wants, we should try to rally arround a single approach. Proposal: Many working groups create DHCP options for service discovery. Others are specifying use of DNS SRV RRs. What if we specify a simple mapping between the two and create a registration process: IETF Standards Track Service => DHCP Option # and DNS SRV Name As far as the consistency of the list of service locations which DHCP and DNS servers assign to clients - that could be solved by tighter integration of DNS and DHCP. This has long been considered for the relationship between A and PTR records for DHCP assigned addresses. We could start a parallel effort to consider the relationship between SRV RRs and DHCP assigned server options - so they are the same list. This would be especially useful when 'Stateless DHCPv6' and 'multicast DNS' mature as standards and are supported on the same host. Should I write this proposal up as an internet draft? --- Best regards, Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jul 17 09:21:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15720; Wed, 17 Jul 2002 09:21:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07981; Wed, 17 Jul 2002 09:20:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00989 for ; Wed, 17 Jul 2002 02:12:44 -0400 (EDT) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21207 for ; Wed, 17 Jul 2002 02:11:44 -0400 (EDT) Received: from antigen.bucknell.edu (antigen.bucknell.edu [134.82.9.20]) by mail.bucknell.edu (8.11.6/8.11.6) with ESMTP id g6H6Cfd01843 for ; Wed, 17 Jul 2002 02:12:41 -0400 (EDT) Received: from uucp2.netcore.co.in ([202.162.229.11]) by antigen.bucknell.edu (8.12.4/8.12.4) with ESMTP id g6H6Bc2q028226 for ; Wed, 17 Jul 2002 02:11:43 -0400 (EDT) Received: from netcore.co.in ([202.149.212.198]) by uucp2.netcore.co.in (8.11.0/8.8.7) with ESMTP id g6H64DU20240 for ; Wed, 17 Jul 2002 11:34:13 +0530 Message-ID: <3D350D2D.2090004@netcore.co.in> Date: Wed, 17 Jul 2002 11:52:37 +0530 From: Mandar Deodhar User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dhcp-v4@bucknell.edu Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean Content-Transfer-Encoding: 7bit Subject: [dhcwg] subscribe Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jul 17 09:21:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15744; Wed, 17 Jul 2002 09:21:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08101; Wed, 17 Jul 2002 09:20:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08076 for ; Wed, 17 Jul 2002 09:20:29 -0400 (EDT) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15657 for ; Wed, 17 Jul 2002 09:19:30 -0400 (EDT) Received: from chitha.india.hp.com (chitha.india.hp.com [15.10.43.31]) by palrel10.hp.com (Postfix) with ESMTP id AA5AAC00EE6; Wed, 17 Jul 2002 06:19:55 -0700 (PDT) Received: (from jitesh@localhost) by chitha.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id SAA07724; Wed, 17 Jul 2002 18:19:26 +0530 (IST) From: Jitesh N Verma Message-Id: <200207171249.SAA07724@chitha.india.hp.com> Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP To: cheshire@apple.com Date: Wed, 17 Jul 2002 18:19:24 +0530 (IST) Cc: dhcwg@ietf.org In-Reply-To: <200207171201.g6HC1KT00380@scv2.apple.com> from Stuart Cheshire at Jul "17," 2002 "05:01:22" am X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hi, What do you mean by one less server to maintain? Do you recommend a single server daemon for all the services (dhcpd,bind,ftpd,telnetd,ntpd...). There are several OS companies who supplys DNS and DHCP both to their customers. So, the other point also is not valid. Cheers, Jitesh > >What you propose is perfectly workable, but I don't > >see how it's *better* than what DHCP already provides. > > My belief is that one of the benefits of IPv6 is that it does automatic > address allocation without needing a DHCP server. This is good. This > means that your network operations people have one less server to install > and configure and maintain. > > If we make our IPv6 hosts dependent on DHCPv6 servers for lots of > critical information that they cannot operate without, then we still need > to run a DHCP server and we have lost that IPv6 benefit. > > Since (a) hosts still need to find out information like "Where's my time > server", and (b) in an all-IPv6 world we still plan to run DNS servers > anyway, then if we can put information (a) into DNS (b), we can eliminate > the burden of also having to install and configure and maintain a DHCP > server. Instead of having to communicate arbitrary bootstrap > configuration information to hosts, we now just have to communicate the > name server address(es) and the default domain, which is a nice simple > constrained problem that can be solved in any number of simple ways -- > e.g. add that information to Router Advertisement packets. > > [Of course, I am well aware that this point of view will not be popular > with all the people working so hard for so long on DHCPv6. Also, if you > have a company that sells a DHCP server, then eliminating the need for > DHCP servers is not in your company's best interest. I understand that.] > > Stuart Cheshire > * Wizard Without Portfolio, Apple Computer > * Chairman, IETF ZEROCONF > * www.stuartcheshire.org > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > -- ----------------------------------------------------------------------- ~ ~ *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* ^ Jitesh N. Verma Tel. 91-80-225 1554 Ext. 1424 ^ ^ HEWLETT PACKARD Fax. 91-80-220 0196 ^ ^ INDIA SOFTWARE OPERATIONS Email. jitesh@india.hp.com ^ ^ 29, CUNNINGHAM ROAD Pager. 9624-263608 ^ ^ BANGALORE 560 052 __ Telnet. 847-1424 ^ ^ / / ^ ^ / /___ _____ ^ ^ / __ // __ / ^ ^ / / / // /_/ / ^ ^ /_/ /_// ____/ ^ ^ / / ^ ^ /_/ ^ *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jul 17 09:36:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16131; Wed, 17 Jul 2002 09:36:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09500; Wed, 17 Jul 2002 09:36:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09433 for ; Wed, 17 Jul 2002 09:35:14 -0400 (EDT) Received: from styx.uwaterloo.ca (styx.uwaterloo.ca [129.97.105.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16108 for ; Wed, 17 Jul 2002 09:34:14 -0400 (EDT) Received: from localhost (bmukherj@localhost) by styx.uwaterloo.ca (8.11.6/8.11.0) with ESMTP id g6HDXvn02969; Wed, 17 Jul 2002 09:33:57 -0400 Date: Wed, 17 Jul 2002 09:33:57 -0400 (EDT) From: Roop Mukherjee To: Ted Lemon cc: Roop Mukherjee , Stuart Cheshire , DHCP discussion list Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP In-Reply-To: <2F7FCD64-9946-11D6-8431-00039317663C@nominum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Not using imperatives, does not imply that the text expresses opinion. Let me try to make it simple. The technical point I was trying to make was: Distinguish between the configuration probelm from the naming problem. The naming problem is that of finding the address of an entity in the network. If there is a name server, like DNS, then nodes can querry it for names without having any other association with it. This is important becuae one may have non-DHCP hosts wanting to discover names. The configuration problem is finding your own address, and that of some other essential entities. Insisting that the general naming function be performed as part of the configuration(DHCP) server is just globbing functionality together. As the internet grows, the naimg problem will likely need something better than DNS. At the least keeping it disinct from other problems will help. Cheers, -- Roop ______________________________________________ On Wed, 17 Jul 2002, Ted Lemon wrote: > > It seems that the problem of service discovery, probably better termed as > > server discovery, at the moment is simply that of locating a server for a > > service that a end-node may desire. Locating the address of a server (for > > time, ftp etc.) is a naming function. > > > > That being the case, locating the names of servers seems more up the alley > > of DNS than DHCP. > > This seems to be a statement of opinion. I was looking more for logical > arguments - that is, you present *reasons* why you believe that DNS is a > better choice than DHCP. I don't see any reasons here - just opinions. > > I am not saying you are definitely wrong. I just don't see how this > statement helps us to decide what to do. > > > _______________________________________________ > 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 Jul 17 09:47:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16387; Wed, 17 Jul 2002 09:47:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10316; Wed, 17 Jul 2002 09:46:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10291 for ; Wed, 17 Jul 2002 09:46:53 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16335 for ; Wed, 17 Jul 2002 09:45:54 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g6HDkJhI025142; Wed, 17 Jul 2002 06:46:19 -0700 (PDT) Received: from JSCHNIZL-W2K1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g6HDkH0m012562; Wed, 17 Jul 2002 06:46:18 -0700 (PDT) Message-Id: <4.3.2.7.2.20020717094514.01a2eb20@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 17 Jul 2002 09:46:15 -0400 To: Erik Guttman From: John Schnizlein Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP Cc: DHCP discussion list , Stuart Cheshire In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org What is the problem your proposal intends to solve? At 06:28 AM 7/17/2002, Erik Guttman wrote: >... >Proposal: > >Many working groups create DHCP options for service discovery. >Others are specifying use of DNS SRV RRs. What if we specify a >simple mapping between the two and create a registration process: > > IETF Standards Track Service => DHCP Option # and DNS SRV Name _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jul 17 09:58:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16759; Wed, 17 Jul 2002 09:58:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11114; Wed, 17 Jul 2002 09:58:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11029 for ; Wed, 17 Jul 2002 09:57:54 -0400 (EDT) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16705 for ; Wed, 17 Jul 2002 09:56:54 -0400 (EDT) Received: from antigen.bucknell.edu (antigen.bucknell.edu [134.82.9.20]) by mail.bucknell.edu (8.11.6/8.11.6) with ESMTP id g6HDvqd09987 for ; Wed, 17 Jul 2002 09:57:52 -0400 (EDT) Received: from wind.netissat.bg (qmailr@wind.netissat.bg [212.72.193.60]) by antigen.bucknell.edu (8.12.4/8.12.4) with SMTP id g6HDv52q021747 for ; Wed, 17 Jul 2002 09:57:07 -0400 (EDT) Received: (qmail 31448 invoked from network); 17 Jul 2002 13:57:01 -0000 Received: from teatime.netissat.bg (HELO netissat.bg) (1000@212.72.192.22) by wind.netissat.bg with SMTP; 17 Jul 2002 13:57:01 -0000 Message-ID: <3D35782B.1000200@netissat.bg> Date: Wed, 17 Jul 2002 16:59:07 +0300 From: Svilen Stanoev User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: bg, en-us MIME-Version: 1.0 To: dhcp-v4@bucknell.edu Content-Type: multipart/alternative; boundary="------------050302000709010700040307" X-MailScanner: Found to be clean Subject: [dhcwg] DHCPD and the "Include" Directive .. Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --------------050302000709010700040307 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Hello there, I need to import some different conf-files in only one (dhcpd.conf). I need to edit them separately and independent one from another. Is there standard directive like "include", "require" or "import" which the dhcp daemon recognizes? Thanks in advance -- *======================* * Svilen Stanoev* * NET IS SAT Ltd.* *======================* --------------050302000709010700040307 Content-Type: text/html; charset=windows-1251 Content-Transfer-Encoding: 8bit Hello there,
I need to import some different  conf-files in only one (dhcpd.conf).
I need to edit them separately and independent one from another.
Is there standard directive like "include", "require" or "import" which
the dhcp daemon recognizes?

Thanks in advance
--
none
======================
               Svilen Stanoev
             NET IS SAT Ltd.
======================

--------------050302000709010700040307-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jul 17 10:25:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17575; Wed, 17 Jul 2002 10:25:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13385; Wed, 17 Jul 2002 10:25:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13348 for ; Wed, 17 Jul 2002 10:25:30 -0400 (EDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17527 for ; Wed, 17 Jul 2002 10:24:30 -0400 (EDT) Received: from [192.168.4.146] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id A9263137F02; Wed, 17 Jul 2002 07:24:57 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 17 Jul 2002 07:24:58 -0700 Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP From: David Conrad To: Jitesh N Verma , Cc: Ted Lemon , , , dhcpwg Message-ID: In-Reply-To: <200207171239.SAA07672@chitha.india.hp.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Jitesh, On 7/17/02 5:39 AM, "Jitesh N Verma" wrote: > Hi all, > Around a year back, I had sent a mail to this mailing list citing > that other working groups (like Stateless Autoconfiguration, DNS etc.) > are trying to hijack DHCP working group's agenda. Now, I am seeing that fear > becoming realty. Lots of folks have hammers for all those things they think look like nails... :-) > I just want to raise one point against DNS implementing server location. > DNS name resolution is hitting perfomance bottleneck due to large size of > database. No it isn't. Particular implementations are hitting bottlenecks for various reasons, however I know of a couple of implementations that can do wire speed on 100 Mbps without breaking a sweat. There is empirical evidence the DNS scales to hundreds of millions of zones or tens of millions of names in a zone while responding to tens of thousands of queries per second. I am skeptical that any service location use of DNS would add significantly to the scaling requirements. However, if you want to talk about scaling, how many DHCP servers out there can do more than (say) 30,000 lease allocations or even renewals per second? > My point is why to increase load to already overloaded DNS server > with extra features (which are already available in DHCP)? DNS, in particular the SRV record, was specifically designed to provide information on where to find a particular service. Since SRV contains both a priority and a preference field, I believe it can provide more flexibility to clients attempting to locate a service than DHCP can. In any event, I personally believe having multiple tools in a toolbox is a good thing. I can imagine scenarios in which either DHCP or DNS or SLP are better suited to the service location function than the others. Where it would be wrong to go would be to twist the protocol to meet a particular requirement that one of the other protocols already meets. Rgds, -drc _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jul 17 14:14:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25468; Wed, 17 Jul 2002 14:14:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19480; Wed, 17 Jul 2002 14:14:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19457 for ; Wed, 17 Jul 2002 14:14:35 -0400 (EDT) Received: from manta.infocus.com (moray.infocus.com [209.84.97.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25432 for ; Wed, 17 Jul 2002 14:13:37 -0400 (EDT) Received: by manta.infocus.com (Postfix, from userid 5) id 7CD4F27A31; Wed, 17 Jul 2002 11:14:32 -0700 (PDT) Received: from sonata.infocus.com(200.1.10.70), claiming to be "sonata.infocuscorp.com" via SMTP by manta.infocus.com, id smtpdAAA00G4i2; Wed Jul 17 11:14:31 2002 Received: by sonata with Internet Mail Service (5.5.2653.19) id <30ZG7YA3>; Wed, 17 Jul 2002 11:10:00 -0700 Message-ID: From: Chris Pearson To: "'Ted Lemon'" Cc: DHCP discussion list , Stuart Cheshire Subject: RE: [dhcwg] Review of Service-Discovery-Type options in DHCP Date: Wed, 17 Jul 2002 11:12:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Thanks for the corrections. A few more comments. > Every subsequent DHCPREQUEST is unicast RFC2131 para. 3.2 shows DHCPREQUEST for address reuse being broadcast. That may just be the example chosen, but it's certainly misleading. > every operating system out there except one puts the DHCP client at > the application level, not in the stack, and indeed it's an > application-layer protocol - it's layered on top of UDP. Agreed. However, I meant that DNS is an "application-level protocol" in the sense that it is designed specifically to provide a service to applications while DHCP primarily provides a service to the OS. > the common DNS API ... is not a standard. Of course not. My point is simply that applications already interface with DNS (minimally, gethostbyname), suggesting that DNS might be a more natural choice to support application-driven service location requests. Also, DNS dynamic update offers the potential to track low-frequency changes in service availability -- how would DHCP support that? -- CCP -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Tuesday, July 16, 2002 10:39 PM To: Chris Pearson Cc: DHCP discussion list; Stuart Cheshire Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP > 3. DHCP provides no mechanism for a client to request configuration > options without also requesting address lease renewal. Lease > renewal would be a highly undesirable side-effect of service > discovery. Not true. DHCPv4 provides DHCPINFORM. DHCPv6 provides Information Request. > 4. Service discover is often initiated by applications (rather than > by the IP stack). DNS is an application-level, request-response, > protocol > 4a. that is supported by established APIs. > 4b. DHCP, on the other > hand, is an integral part of the IP stack -- > 4c. DHCP implementations > that I know of don't provide an API. You are actually making four points here. I agree with (4), (4a) and (4b) , but not (4c). There is no reason not to have an API for DHCP, and there' s no particular sense in which such an API would be more or less good than the common DNS API which, BTW, is not a standard. My reason for disagreeing with (4c), btw, is that in fact every operating system out there except one puts the DHCP client at the application level, not in the stack, and indeed it's an application-layer protocol - it's layered on top of UDP. Ironically, the one operating system where it's easy to use DHCPINFORM is the one where DHCP is in the stack, because a DHCPINFORM client can do a DHCPINFORM without running into the problem of competing with the userland DHCP client in binding to port 68. > 5. DHCP client requests (DHCPREQUEST) must be subnet-broadcast and > perhaps relayed, while DNS queries are unicast. Again, this is almost completely untrue. The _only_ DHCPREQUEST that is ever broadcast is the first one, when the DHCP client has no IP address. Every subsequent DHCPREQUEST is unicast, unless something is wrong (e.g., the DHCP server hasn't responded to unicast renewals for a long time). So I would say that the only substantive argument you've advanced is the lack of an API for DHCP, which I agree is a problem. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jul 17 21:22:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05464; Wed, 17 Jul 2002 21:22:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14346; Wed, 17 Jul 2002 21:21:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14326 for ; Wed, 17 Jul 2002 21:21:49 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05406 for ; Wed, 17 Jul 2002 21:20:49 -0400 (EDT) Received: from green.bisbee.fugue.com (dechen.dyn.ietf54.wide.ad.jp [133.93.74.182]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g6I1Ldd10015; Thu, 18 Jul 2002 01:21:39 GMT Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g6I1LpXU002519; Thu, 18 Jul 2002 10:21:51 +0900 (JST) Date: Thu, 18 Jul 2002 10:21:48 +0900 Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: Ralph Droms , Stuart Cheshire , DHCP discussion list To: "Bernie Volz (EUD)" From: Ted Lemon In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D6FF@EAMBUNT705> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit If you use the domain name search list as a resource discovery search list as well, then this constrains your use of the domain name search list in a way that makes me uncomfortable. Likewise with the domain name. If a mechanism like this is the right way to go (and I don't agree that it is), then it would have to be another search list - it should not be overloaded. TBF, I would rather use SLP than either DHCP or DNS, if it worked. My interest in promoting the use of DHCP options for this is not that I think it's the right solution in the end, but that I think it's useful now. It also provides a useful upgrade path for non-SLP-compliant devices - you have the DHCP server do the SLP request on behalf of the client. This allows SLP and non-SLP clients to coexist in a way that is not obnoxious for the network administrator. Non-SLP clients might get different results, because of the weaknesses of DHCP as a service location protocol, but they will get results. I see a lot of pushback on using DHCP for service location, and I wonder if some of this is motivated by a wish to eliminate competition for SLP, so that SLP has a chance to get deployed. If so, perhaps I've described a way that everybody can win. It's definitely not my intention to prevent deployment of SLP to benefit DHCP. I just want something that works, and I think that having two solutions that solve the problem in different ways is likely to produce the right results. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jul 17 21:29:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05644; Wed, 17 Jul 2002 21:29:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14822; Wed, 17 Jul 2002 21:29:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14795 for ; Wed, 17 Jul 2002 21:29:28 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05606 for ; Wed, 17 Jul 2002 21:28:29 -0400 (EDT) Received: from green.bisbee.fugue.com (dechen.dyn.ietf54.wide.ad.jp [133.93.74.182]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g6I1THd10062; Thu, 18 Jul 2002 01:29:17 GMT Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g6I1TUXU002522; Thu, 18 Jul 2002 10:29:30 +0900 (JST) Date: Thu, 18 Jul 2002 10:29:29 +0900 Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "DHCP discussion list" To: Stuart Cheshire From: Ted Lemon In-Reply-To: <200207171201.g6HC1KT00380@scv2.apple.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Stuart, let's be careful here. My motivation for being involved in DHCPv6 is that I think people will want it. IPv6 provides a completely functional alternative to DHCPv6, so the _only_ reason that DHCPv6 will ever be deployed is if people want it. The idea that you want fewer network servers strikes me as a red herring - if you have the right administrative interface, it doesn't *matter* how many ports you are listening on, or what format the packets have. The impact on the end user is the same - hopefully nil, or nearly nil. I can tell you quite frankly that although I am quite skeptical that DHCP is going to go away with IPv6, I would be very happy to get out of the DHCP business and hack on DNS or something else. And I think that whichever way the market goes, my company is going to do fine, so I'm not worried about it from that perspective. So let's not make this a discussion about which way is better. Let's let the market determine that. Let's instead figure out how we can win whichever way the market goes. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jul 17 21:36:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05856; Wed, 17 Jul 2002 21:36:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15667; Wed, 17 Jul 2002 21:36:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15637 for ; Wed, 17 Jul 2002 21:36:25 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05837 for ; Wed, 17 Jul 2002 21:35:26 -0400 (EDT) Received: from green.bisbee.fugue.com (dechen.dyn.ietf54.wide.ad.jp [133.93.74.182]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g6I1aHd10074; Thu, 18 Jul 2002 01:36:17 GMT Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g6I1aTXU002525; Thu, 18 Jul 2002 10:36:29 +0900 (JST) Date: Thu, 18 Jul 2002 10:36:29 +0900 Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: Stuart Cheshire , DHCP discussion list To: Roop Mukherjee From: Ted Lemon In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > Let me try to make it simple. The technical point I was trying to make > was: > Distinguish between the configuration probelm from the naming problem. I'm sorry, but this is not a technical argument. It is a statement of opinion. You are saying that there are two separate problems - configuration and naming. You then describe what you think these problems are. Nowhere do you explain why you think this way of framing the problem is correct - you simply assert that it is correct and then explain the problem as you see it in more detail. This is not constructive. Let me make two observations: 1. There is more than one functional way to state the problem. 2. We don't have to pick only one solution. It is quite possible that your statement of what the problem is is a functional one. The mere fact that this is so, if it is so, does not mean that the way the DHCPv6 group has been framing the problem is *not* a functional one. So advancing this as a reason not to support service location options in DHCPv6 doesn't work. If you think this is the right way to solve the problem, go off and write up some drafts, and try to advance them in the DNSEXT working group. But don't say to us, "you must stop trying to solve this problem, because I am trying to solve it and my way is better." When you say that, you are simply stating your opinion, and that is not a valid reason for us to stop doing what we are doing, unless we happen to agree with you without needing to be convinced. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jul 17 21:41:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05950; Wed, 17 Jul 2002 21:41:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15923; Wed, 17 Jul 2002 21:41:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15898 for ; Wed, 17 Jul 2002 21:41:28 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05940 for ; Wed, 17 Jul 2002 21:40:24 -0400 (EDT) Received: from green.bisbee.fugue.com (dechen.dyn.ietf54.wide.ad.jp [133.93.74.182]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g6I1eSd10083; Thu, 18 Jul 2002 01:40:28 GMT Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g6I1eeXU002532; Thu, 18 Jul 2002 10:40:40 +0900 (JST) Date: Thu, 18 Jul 2002 10:40:40 +0900 Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: DHCP discussion list , Stuart Cheshire To: Chris Pearson From: Ted Lemon In-Reply-To: Message-Id: <5DA9C5D3-99EF-11D6-8431-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > RFC2131 para. 3.2 shows DHCPREQUEST for address reuse being broadcast. > That > may just be the example chosen, but it's certainly misleading. Right, this happens once when you power on your computer, not every time the lease is renewed. > Also, DNS dynamic update offers the potential to track low-frequency > changes in service availability -- how would DHCP support that? It's true that DHCP provides no way to do this without operator intervention, but you are ignoring the key management problem with DNS. You can't do ad-hoc service registration with DNS using dynamic updates, because the thing that's registering has no security association with the DNS server. :'/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jul 18 18:33:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14165; Thu, 18 Jul 2002 18:33:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16447; Thu, 18 Jul 2002 18:33:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12466 for ; Wed, 17 Jul 2002 10:07:11 -0400 (EDT) Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17075 for ; Wed, 17 Jul 2002 10:06:11 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07436; Wed, 17 Jul 2002 08:07:06 -0600 (MDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g6HE73b03037; Wed, 17 Jul 2002 16:07:03 +0200 (MEST) Date: Wed, 17 Jul 2002 16:06:22 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field To: John Schnizlein cc: Erik Guttman , DHCP discussion list , Stuart Cheshire Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP In-Reply-To: <4.3.2.7.2.20020717094514.01a2eb20@wells.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > >Proposal: > > > >Many working groups create DHCP options for service discovery. > >Others are specifying use of DNS SRV RRs. What if we specify a > >simple mapping between the two and create a registration process: > > > > IETF Standards Track Service => DHCP Option # and DNS SRV Name On Wed, 17 Jul 2002, John Schnizlein wrote: > What is the problem your proposal intends to solve? Rather than consider 'which is better' I believe DHCP and DNS are pretty equivalent for this function. Why not facilitate this equivalence and provide for making responses from DHCP consistent with those from DNS? It would be nice if dhcp option numbers assigned could be paired with well known names to be used in DNS SRV records. This would facilitate DNS and DHCP giving out the same information. This will be particularly useful if stateless DHCPv6 and multicast DNS become pervasive. A stateless DHCP and multicast DNS server might use the same database to answer a request for a particular service type. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jul 18 20:08:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16321; Thu, 18 Jul 2002 20:08:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA20168; Thu, 18 Jul 2002 20:07:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA20146 for ; Thu, 18 Jul 2002 20:07:34 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16304 for ; Thu, 18 Jul 2002 20:06:37 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-792.cisco.com [10.21.99.24]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA08030; Thu, 18 Jul 2002 20:07:03 -0400 (EDT) Message-Id: <4.3.2.7.2.20020718195757.03afcbd8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Jul 2002 20:06:58 -0400 To: dhcwg@ietf.org From: Ralph Droms Cc: nrussell@cisco.com, paduffy@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] DHCP Option for CableLabs Client Configuration Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org The DHC WG reviewed "DHCP Option for CableLabs Client Configuration" at the WG meeting in Yokohama. This document is a revision of a spec that has been in front of the WG for a while. CableLabs wants to publish the spec as an RFC and obtain an IANA-assigned option code. Although the WG has seen this specification before, the current draft had not been sufficiently reviewed to go to WG last call. There are several changes in the spec that bring it into line with standard DHCP practice for the definition of options and sub-options. Note that this spec defines a slightly different model for assigning sub-option codes than is used for other options. This model is defined to coordinate with the CableLabs standards process. Please read the draft and send comments to the WG mailing list. I expect to start a WG last call on the document next Wednesday (7/24). - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jul 21 23:38:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15629; Sun, 21 Jul 2002 23:38:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA08293; Sun, 21 Jul 2002 23:37:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA08263 for ; Sun, 21 Jul 2002 23:37:34 -0400 (EDT) Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15618 for ; Sun, 21 Jul 2002 23:36:30 -0400 (EDT) Received: from galadriel (mickey110.cwc.nus.edu.sg [172.16.2.134]) by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with SMTP id LAA01767 for ; Mon, 22 Jul 2002 11:35:58 +0800 (SGT) Message-ID: <00d901c23130$777961b0$860210ac@galadriel> From: "Raymond Jayaraj" To: "DHCP discussion list" References: Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP Date: Mon, 22 Jul 2002 11:32:54 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hi, Just my take on this DHCP vs DNS problem, coming from a 'performance' perspective (i.e. number of bits, messages). I'm not too sure if DNS doesn't support multiple queries in a message, but if it doesn't, then you'd have to do 'pointed' queries to find out if services exist, and where they are located, e.g.: MN AR DNS -+- -+- -+- |address/dn config |<=====>| | | where's NTP? | |-------------->| | at ::X |<-------------- | where's POP? |--------------> | no such record |<-------------- | where's BIND |--------------> | at ::Y |<-------------- On the other hand, using DHCP(v6) extensions, you can do a 'hailing' type of query: MN AR DHC -+- -+- -+- |addr conf. | |<=====>| | |Okay, which of these services have you got - NTP,POP,BIND |-------------->| |NTP's at ::X, BIND's at ::Y. I don't have POP though. |<--------------| Of course, if DNS do allow multiple queries in a message, or if it is enhanced to support this, then this argument has no base. Also, bitwise, DHCP permits the most optimised performance by allowing the sending of IPv6 addresses of services in raw. Cheers, Raymond Jayaraj ICR, Singapore. ----- Original Message ----- From: "Ted Lemon" To: "Roop Mukherjee" Cc: "Stuart Cheshire" ; "DHCP discussion list" Sent: Thursday, July 18, 2002 9:36 AM Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP > > Let me try to make it simple. The technical point I was trying to make > > was: > > Distinguish between the configuration probelm from the naming problem. > > I'm sorry, but this is not a technical argument. It is a statement of > opinion. You are saying that there are two separate problems - > configuration and naming. You then describe what you think these problems > are. Nowhere do you explain why you think this way of framing the problem > is correct - you simply assert that it is correct and then explain the > problem as you see it in more detail. This is not constructive. > > Let me make two observations: > > 1. There is more than one functional way to state the problem. > 2. We don't have to pick only one solution. > > It is quite possible that your statement of what the problem is is a > functional one. The mere fact that this is so, if it is so, does not mean > that the way the DHCPv6 group has been framing the problem is *not* a > functional one. So advancing this as a reason not to support service > location options in DHCPv6 doesn't work. If you think this is the right > way to solve the problem, go off and write up some drafts, and try to > advance them in the DNSEXT working group. But don't say to us, "you must > stop trying to solve this problem, because I am trying to solve it and my > way is better." When you say that, you are simply stating your opinion, > and that is not a valid reason for us to stop doing what we are doing, > unless we happen to agree with you without needing to be convinced. > > > _______________________________________________ > 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 Jul 22 12:28:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12109; Mon, 22 Jul 2002 12:28:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15249; Mon, 22 Jul 2002 12:26:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15182 for ; Mon, 22 Jul 2002 12:26:05 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11622 for ; Mon, 22 Jul 2002 12:25:02 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g6MGPel02920; Mon, 22 Jul 2002 11:25:40 -0500 (CDT) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g6MGPde11573; Mon, 22 Jul 2002 11:25:40 -0500 (CDT) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 22 Jul 2002 11:25:39 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D710@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Cc: nrussell@cisco.com, paduffy@cisco.com Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration Date: Mon, 22 Jul 2002 11:25:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2319C.6A4873AC" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C2319C.6A4873AC Content-Type: text/plain; charset="ISO-8859-1" Ralph: A few likely minor comments regarding this draft: 1. In section 6, it says: It should be noted that, although the CCC option will be initially deployed to support PacketCable VOIP applications, the CCC option will also be used to support various non VOIP applications. Use of the CCC option does not necessarily mean that the service provider is a TSP. Should something be said as to how the DHCP server could distinguish the various applications so that it only provides the options required for that particular application (or applications)? I'm primarily concerned here with the size of the packets and also with the DHCP server providing unnecessary information (or potentially leaking undesired information) to other clients. 2. There is basically no information on how clients and servers should use this option. It says: 9. Typical use of the CableLabs Client Configuration Option Specific usage of the CableLabs Client Configuration option is described in [7]. While this document may be publicly available, I think the draft should indicate some basic rules as to when a client requests this option and when a server sends it (such as only if requested). Perhaps material from the referenced document can be extracted? 3. As this option could carry a lot of data, it might be good for the I-D to reference the concatenation handling (draft-ietf-dhc-concat-04.txt). 4. While I have no particular issue with how these suboption numbers are assigned (by CableLabs), it does seem a bit odd to have two registries of this information. The following text in 12 seems somewhat contradictory? IANA is requested to register codes for future CableLabs Client Configuration Sub-options with an "Expert Review" approval policy as described in RFC 2434 [3]. Future proposed sub-options will be assigned a numeric code chosen by CableLabs, which will be documented in the Internet Drafts that describe the sub-options. The code assignment will be reviewed by a designated expert from the IETF prior to publication in an RFC. IANA is really just keeping the record of assigned numbers and not doing the registry process. This also likely will mean some numbers will be used without any Internet-Drafts/RFCs ever existing (since CableLabs can assign numbers without the existence of these documents). It might be best to just remove IANA's roll here? If an ID or RFC exists, it documents the suboptions? - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, July 18, 2002 8:07 PM To: dhcwg@ietf.org Cc: nrussell@cisco.com; paduffy@cisco.com Subject: [dhcwg] DHCP Option for CableLabs Client Configuration The DHC WG reviewed "DHCP Option for CableLabs Client Configuration" at the WG meeting in Yokohama. This document is a revision of a spec that has been in front of the WG for a while. CableLabs wants to publish the spec as an RFC and obtain an IANA-assigned option code. Although the WG has seen this specification before, the current draft had not been sufficiently reviewed to go to WG last call. There are several changes in the spec that bring it into line with standard DHCP practice for the definition of options and sub-options. Note that this spec defines a slightly different model for assigning sub-option codes than is used for other options. This model is defined to coordinate with the CableLabs standards process. Please read the draft and send comments to the WG mailing list. I expect to start a WG last call on the document next Wednesday (7/24). - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2319C.6A4873AC Content-Type: text/html; charset="ISO-8859-1" RE: [dhcwg] DHCP Option for CableLabs Client Configuration

Ralph:

A few likely minor comments regarding this draft:

1. In section 6, it says:

   It should be noted that, although the CCC option will be initially
   deployed to support PacketCable VOIP applications, the CCC option
   will also be used to support various non VOIP applications. Use of
   the CCC option does not necessarily mean that the service provider is
   a TSP.

Should something be said as to how the DHCP server could distinguish the
various applications so that it only provides the options required for
that particular application (or applications)? I'm primarily concerned
here with the size of the packets and also with the DHCP server providing
unnecessary information (or potentially leaking undesired information) to
other clients.

2. There is basically no information on how clients and servers should
use this option. It says:
   
   9.   Typical use of the CableLabs Client Configuration Option 
   
   Specific usage of the CableLabs Client Configuration option is
   described in [7].    

While this document may be publicly available, I think the draft should
indicate some basic rules as to when a client requests this option and when
a server sends it (such as only if requested). Perhaps material from the
referenced document can be extracted?

3. As this option could carry a lot of data, it might be good for the I-D
to reference the concatenation handling (draft-ietf-dhc-concat-04.txt).

4. While I have no particular issue with how these suboption numbers are
assigned (by CableLabs), it does seem a bit odd to have two registries of
this information. The following text in 12 seems somewhat contradictory?

   IANA is requested to register codes for future CableLabs Client
   Configuration Sub-options with an "Expert Review" approval policy as
   described in RFC 2434 [3]. Future proposed sub-options will be
   assigned a numeric code chosen by CableLabs, which will be
   documented in the Internet Drafts that describe the sub-options. The
   code assignment will be reviewed by a designated expert from the
   IETF prior to publication in an RFC.

IANA is really just keeping the record of assigned numbers and not doing
the registry process. This also likely will mean some numbers will be used
without any Internet-Drafts/RFCs ever existing (since CableLabs can assign
numbers without the existence of these documents).

It might be best to just remove IANA's roll here? If an ID or RFC exists,
it documents the suboptions?

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, July 18, 2002 8:07 PM
To: dhcwg@ietf.org
Cc: nrussell@cisco.com; paduffy@cisco.com
Subject: [dhcwg] DHCP Option for CableLabs Client Configuration


The DHC WG reviewed "DHCP Option for CableLabs Client Configuration"
<draft-ietf-dhc-packetcable-02.txt> at the WG meeting in Yokohama.  This
document is a revision of a spec that has been in front of the WG for a
while.  CableLabs wants to publish the spec as an RFC and obtain an
IANA-assigned option code.

Although the WG has seen this specification before, the current draft had
not been sufficiently reviewed to go to WG last call.  There are several
changes in the spec that bring it into line with standard DHCP practice for
the definition of options and sub-options.

Note that this spec defines a slightly different model for assigning
sub-option codes than is used for other options.  This model is defined to
coordinate with the CableLabs standards process.

Please read the draft and send comments to the WG mailing list. I expect to
start a WG last call on the document next Wednesday (7/24).

- Ralph


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

------_=_NextPart_001_01C2319C.6A4873AC-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jul 23 19:38:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07459; Tue, 23 Jul 2002 19:38:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25634; Tue, 23 Jul 2002 19:39:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA01542 for ; Thu, 18 Jul 2002 23:42:32 -0400 (EDT) Received: from sun-pdt-3.oregontrail.net (sun-pdt-3.oregontrail.net [66.201.128.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20682 for ; Thu, 18 Jul 2002 23:41:32 -0400 (EDT) Received: from dotcomasus (lag-83-95.oregontrail.net [12.46.83.95]) by sun-pdt-3.oregontrail.net (8.11.3/8.11.3/OTI-MX-RBL-Dec-16-01 UCE Prohibited) with SMTP id g6J3g4t23505 for ; Thu, 18 Jul 2002 20:42:10 -0700 (PDT) From: "Dan Clemens" To: Date: Thu, 18 Jul 2002 20:41:48 -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.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1050 Content-Transfer-Encoding: 7bit Subject: [dhcwg] thought you might know... Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit From what I see on your web page you are the folks how establish the standards for DHCP. Sorry to bother you with what I am sure is a basic question but I have been searching for days now and can not find the information I need. What I would like to know is if there is a way to find out what IP addresses DHCP has assigned to each of the clients on a network. I know I can go to each of the individual stations an get the info via IPCONFIG but several of the devices on my network do not have a user interface. One of these devices on my network is a wireless bridge. It's configuration can be managed via it's IP and a web browser. But since it is dynamically assigned I do not know it's IP (without attaching a laptop to it) and can not access the configuration page via my browser. I have thought of writing a script using ping to poll each address in the range of the subnet mask but this seems kind of cumbersome and I do not want to upset my ISP by accidentally doing something that may be illegal. I am frustrated after the years of training I have had an the certifications I still don't have the information I need! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jul 23 20:24:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07462; Tue, 23 Jul 2002 19:38:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25597; Tue, 23 Jul 2002 19:39:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04789 for ; Fri, 19 Jul 2002 10:58:35 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10641 for ; Fri, 19 Jul 2002 10:57:36 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6JEwDi00055 for ; Fri, 19 Jul 2002 09:58:13 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jul 2002 09:57:59 -0500 Message-ID: From: "Imran Hafeez" To: "'dhcwg@ietf.org'" Date: Fri, 19 Jul 2002 09:57:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22F34.ABA9C4F0" Subject: [dhcwg] Question on DHCPV6 RFC draft-ietf-dhc-dhcpv6-26.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C22F34.ABA9C4F0 Content-Type: text/plain; charset="iso-8859-1" Hi, In the DHCPV6 RFC the IAADDR option specifies an IPV6 address but without any indication to where the prefix & interface id starts and ends. However if you read Radius RFC's for IPV6, they explicitly specify this information, in otherwords they break the IPV6 address into its components. Does anyone know why it was done this way ? Wouldn't this have any potential implications to the way DHCPV6 could be configured ? thanx in advance, Imran Hafeez ------_=_NextPart_001_01C22F34.ABA9C4F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Question on DHCPV6 RFC draft-ietf-dhc-dhcpv6-26.txt

Hi,
In the DHCPV6 RFC the IAADDR option specifies an = IPV6 address but without any indication to where the prefix & = interface id starts and ends. However if you read Radius RFC's for = IPV6, they explicitly specify this information, in otherwords they = break the IPV6 address into its components.

Does anyone know why it was done this way ?

Wouldn't this have any potential implications to the = way DHCPV6 could be configured ?

thanx in advance,
Imran Hafeez

------_=_NextPart_001_01C22F34.ABA9C4F0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jul 24 18:14:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04021; Wed, 24 Jul 2002 18:14:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29867; Wed, 24 Jul 2002 18:15:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12285 for ; Wed, 24 Jul 2002 13:36:52 -0400 (EDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25303 for ; Wed, 24 Jul 2002 13:35:47 -0400 (EDT) Received: from attbi.com ([12.235.107.225]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020724173621.FSAG24728.rwcrmhc51.attbi.com@attbi.com> for ; Wed, 24 Jul 2002 17:36:21 +0000 Message-ID: <3D3EE4FB.1070104@attbi.com> Date: Wed, 24 Jul 2002 10:33:47 -0700 From: "YS Software Consultng, Inc." Reply-To: ysconsulting@attbi.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Have a techical question about DHCP Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hi, Before I ask a techical question I want to know if these questions are appropriate here. If not, where do you suggest I go ? -- Sincerely Yuri Shtil _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jul 24 21:00:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08105; Wed, 24 Jul 2002 21:00:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA09227; Wed, 24 Jul 2002 20:59:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA09201 for ; Wed, 24 Jul 2002 20:59:09 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08085 for ; Wed, 24 Jul 2002 20:58:05 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g6P0wkl21188; Wed, 24 Jul 2002 19:58:47 -0500 (CDT) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g6OLtLi02910; Wed, 24 Jul 2002 16:55:21 -0500 (CDT) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 24 Jul 2002 16:55:21 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D735@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Dan Clemens'" , dhcwg@ietf.org Subject: RE: [dhcwg] thought you might know... Date: Wed, 24 Jul 2002 16:55:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2335C.CD329FD0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C2335C.CD329FD0 Content-Type: text/plain; charset="ISO-8859-1" Dan: DHCP servers don't generally have a mechanism for you to ask this kind of question of them. There is a work in progress to provide this support, but it is generally for use by other network equipment and would not be available to just anyone. See http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-03.txt. However, there is another way you could obtain this information. Please see the Reverse ARP RFC (RFC 903). Of course, for this to work the device has to support this protocol and also has to be on the same link. Likely your best best is to speak to the DHCP operator (ISP) to see whether you can be assigned a fixed address (via DHCP) for the wireless bridge. I also don't fully understand your network configuration and why you have this problem. Perhaps more details regarding this would help to provide suggestions. - Bernie -----Original Message----- From: Dan Clemens [mailto:dancy@oregontrail.net] Sent: Thursday, July 18, 2002 11:42 PM To: dhcwg@ietf.org Subject: [dhcwg] thought you might know... From what I see on your web page you are the folks how establish the standards for DHCP. Sorry to bother you with what I am sure is a basic question but I have been searching for days now and can not find the information I need. What I would like to know is if there is a way to find out what IP addresses DHCP has assigned to each of the clients on a network. I know I can go to each of the individual stations an get the info via IPCONFIG but several of the devices on my network do not have a user interface. One of these devices on my network is a wireless bridge. It's configuration can be managed via it's IP and a web browser. But since it is dynamically assigned I do not know it's IP (without attaching a laptop to it) and can not access the configuration page via my browser. I have thought of writing a script using ping to poll each address in the range of the subnet mask but this seems kind of cumbersome and I do not want to upset my ISP by accidentally doing something that may be illegal. I am frustrated after the years of training I have had an the certifications I still don't have the information I need! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2335C.CD329FD0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] thought you might know...

Dan:

DHCP servers don't generally have a mechanism for you = to ask this kind of question of them. There is a work in progress to = provide this support, but it is generally for use by other network = equipment and would not be available to just anyone. See http://www.ietf.org/internet-drafts/draft-ietf-dhc-lea= sequery-03.txt.

However, there is another way you could obtain this = information. Please see the Reverse ARP RFC (RFC 903). Of course, for = this to work the device has to support this protocol and also has to be = on the same link.

Likely your best best is to speak to the DHCP = operator (ISP) to see whether you can be assigned a fixed address (via = DHCP) for the wireless bridge.

I also don't fully understand your network = configuration and why you have this problem. Perhaps more details = regarding this would help to provide suggestions.

- Bernie


-----Original Message-----
From: Dan Clemens [mailto:dancy@oregontrail.net]<= /FONT>
Sent: Thursday, July 18, 2002 11:42 PM
To: dhcwg@ietf.org
Subject: [dhcwg] thought you might know...


From what I see on your web page you are the folks = how establish the
standards for DHCP.  Sorry to bother you with = what I am sure is a basic
question but I have been searching for days now and = can not find the
information I need.

What I would like to know is if there is a way to = find out what IP addresses
DHCP has assigned to each of the clients on a = network.  I know I can go to
each of the individual stations an get the info via = IPCONFIG but several of
the devices on my network do not have a user = interface.  One of these
devices on my network is a wireless bridge. It's = configuration can be
managed via it's IP and a web browser.  But = since it is dynamically assigned
I do not know it's IP (without attaching a laptop to = it) and can not access
the configuration page via my browser.

I have thought of writing a script using ping to poll = each address in the
range of the subnet mask but this seems kind of = cumbersome and I do not want
to upset my ISP by accidentally doing something that = may be illegal.

I am frustrated after the years of training I have = had an the certifications
I still don't have the information I need!




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

------_=_NextPart_001_01C2335C.CD329FD0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jul 24 22:14:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10406; Wed, 24 Jul 2002 22:14:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13191; Wed, 24 Jul 2002 22:14:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13169 for ; Wed, 24 Jul 2002 22:14:51 -0400 (EDT) Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10392 for ; Wed, 24 Jul 2002 22:13:41 -0400 (EDT) Received: from GALADRIEL (merlion-ckm.cwc.nus.edu.sg [172.16.2.73]) by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with SMTP id KAA26143; Thu, 25 Jul 2002 10:12:54 +0800 (SGT) Message-ID: <001501c23381$056973f0$490210ac@GALADRIEL> Reply-To: "Raymond Jayaraj" From: "Raymond Jayaraj" To: "'Dan Clemens'" Cc: References: <66F66129A77AD411B76200508B65AC69B4D735@EAMBUNT705> Subject: Re: [dhcwg] thought you might know... Date: Thu, 25 Jul 2002 10:14:34 +0800 Organization: ICR, A-STAR MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C233C4.12EC2E30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C233C4.12EC2E30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] thought you might know...Hi Dan, This may not be the right list to be discussing this, but there's a 'dirty' way of doing this, and it involves using a sniffer such as ethereal (www.ethereal.com). 0. Run the sniffer on the same link as the machine whose IP address you'd like to know. Set filter (sniffer dependent) to capture only dhcp messages, or messages with the dhcp server's IP address. 1. Restart the machine. 2. You should see the DHCP messages on the sniffer, from=20 which you can obtain the IP address. You may also want to note its MAC address. To go a step further, you can automate this for all machines, for everytime you restart your system. But this requires some=20 Linux C programming, and using either the libpcap library or=20 netfilter. Also you have to keep track of the MAC addresses=20 of each machine. - Raymond ----- Original Message -----=20 From: Bernie Volz (EUD)=20 To: 'Dan Clemens' ; dhcwg@ietf.org=20 Sent: Thursday, July 25, 2002 5:55 AM Subject: RE: [dhcwg] thought you might know... Dan:=20 DHCP servers don't generally have a mechanism for you to ask this kind = of question of them. There is a work in progress to provide this = support, but it is generally for use by other network equipment and = would not be available to just anyone. See = http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-03.txt. However, there is another way you could obtain this information. = Please see the Reverse ARP RFC (RFC 903). Of course, for this to work = the device has to support this protocol and also has to be on the same = link. Likely your best best is to speak to the DHCP operator (ISP) to see = whether you can be assigned a fixed address (via DHCP) for the wireless = bridge. I also don't fully understand your network configuration and why you = have this problem. Perhaps more details regarding this would help to = provide suggestions. - Bernie=20 -----Original Message-----=20 From: Dan Clemens [mailto:dancy@oregontrail.net]=20 Sent: Thursday, July 18, 2002 11:42 PM=20 To: dhcwg@ietf.org=20 Subject: [dhcwg] thought you might know...=20 From what I see on your web page you are the folks how establish the=20 standards for DHCP. Sorry to bother you with what I am sure is a = basic=20 question but I have been searching for days now and can not find the=20 information I need.=20 What I would like to know is if there is a way to find out what IP = addresses=20 DHCP has assigned to each of the clients on a network. I know I can = go to=20 each of the individual stations an get the info via IPCONFIG but = several of=20 the devices on my network do not have a user interface. One of these=20 devices on my network is a wireless bridge. It's configuration can be=20 managed via it's IP and a web browser. But since it is dynamically = assigned=20 I do not know it's IP (without attaching a laptop to it) and can not = access=20 the configuration page via my browser.=20 I have thought of writing a script using ping to poll each address in = the=20 range of the subnet mask but this seems kind of cumbersome and I do = not want=20 to upset my ISP by accidentally doing something that may be illegal.=20 I am frustrated after the years of training I have had an the = certifications=20 I still don't have the information I need!=20 _______________________________________________=20 dhcwg mailing list=20 dhcwg@ietf.org=20 https://www1.ietf.org/mailman/listinfo/dhcwg=20 ------=_NextPart_000_0012_01C233C4.12EC2E30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] thought you might know...
Hi Dan,
 
This may not be the right list = to be=20 discussing this, but
there's a 'dirty' way of doing = this, and it=20 involves using
a sniffer such as ethereal (www.ethereal.com).
 
0. Run the sniffer on the same = link as the=20 machine whose IP
   address you'd like = to know.=20 Set filter (sniffer dependent)
   to capture = only dhcp messages, or messages with the = dhcp
   server's IP=20 address.
 
1. Restart the = machine.
 
2. You should see the DHCP = messages on the=20 sniffer, from
   which you=20 can obtain the IP = address. You may=20 also want to
   note its MAC=20 address.
 
To go a step further, you = can automate this for all = machines,
for everytime you restart your = system. But=20 this requires some
Linux C programming, and using either the libpcap library or =
netfilter. Also you = have to keep track of the MAC addresses =
of each machine.
 
- Raymond
 
----- Original Message -----
From:=20 Bernie Volz (EUD)
To: 'Dan=20 Clemens' ; dhcwg@ietf.org
Sent: Thursday, July 25, 2002 = 5:55=20 AM
Subject: RE: [dhcwg] thought = you might=20 know...

Dan:

DHCP servers don't generally have a mechanism for = you to ask=20 this kind of question of them. There is a work in progress to provide = this=20 support, but it is generally for use by other network equipment and = would not=20 be available to just anyone. See http://www.ietf.org/internet-drafts/draft-ietf-dhc-leaseq= uery-03.txt.

However, there is another way you could obtain this=20 information. Please see the Reverse ARP RFC (RFC 903). Of course, for = this to=20 work the device has to support this protocol and also has to be on the = same=20 link.

Likely your best best is to speak to the DHCP = operator (ISP)=20 to see whether you can be assigned a fixed address (via DHCP) for the = wireless=20 bridge.

I also don't fully understand your network = configuration and=20 why you have this problem. Perhaps more details regarding this would = help to=20 provide suggestions.

- Bernie


-----Original Message-----
From: Dan=20 Clemens [mailto:dancy@oregontrail.net]=20
Sent: Thursday, July 18, 2002 11:42 PM =
To: dhcwg@ietf.org
Subject: [dhcwg] = thought you=20 might know...


From what I see on your web page you are the folks = how=20 establish the
standards for DHCP.  = Sorry to=20 bother you with what I am sure is a basic
question but=20 I have been searching for days now and can not find the =
information I need.

What I would like to know is if there is a way to = find out=20 what IP addresses
DHCP has assigned to each = of the=20 clients on a network.  I know I can go to
each of=20 the individual stations an get the info via IPCONFIG but several = of=20
the devices on my network do not have a user = interface. =20 One of these
devices on my network is a = wireless=20 bridge. It's configuration can be
managed = via it's IP=20 and a web browser.  But since it is dynamically assigned =
I do not know it's IP (without attaching a laptop to it) and = can not=20 access
the configuration page via my = browser.=20

I have thought of writing a script using ping to = poll each=20 address in the
range of the subnet mask but = this seems=20 kind of cumbersome and I do not want
to = upset my ISP=20 by accidentally doing something that may be illegal.

I am frustrated after the years of training I have = had an the=20 certifications
I still don't have the = information I=20 need!




_______________________________________________=20
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg=20

------=_NextPart_000_0012_01C233C4.12EC2E30-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jul 25 11:21:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08072; Thu, 25 Jul 2002 11:21:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05161; Thu, 25 Jul 2002 11:22:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05138 for ; Thu, 25 Jul 2002 11:22:05 -0400 (EDT) Received: from thebest.argo.com.br (thebest.argo.com.br [200.241.127.93]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08026 for ; Thu, 25 Jul 2002 11:20:59 -0400 (EDT) Received: (qmail 5984 invoked from network); 25 Jul 2002 15:26:29 -0000 Received: from localhost (HELO thebest.argo.com.br) (127.0.0.1) by 0 with SMTP; 25 Jul 2002 15:26:29 -0000 Message-ID: <3D4018A4.70808@thebest.argo.com.br> Date: Thu, 25 Jul 2002 11:26:28 -0400 From: Renato Lins User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a+) Gecko/20020711 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] need sample for dhcpd config Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit I think this may be a very common situation but I am very new to dhcp server. Any help will do. I have one network with 20 computer connect to one switch, this net has two independent routers with also connected to the same switch, I need that a group of 10 computer to get a IP class (192.168.1.x) with the default router to (192.168.1.1) and the other 10 get a IP class (192.168.2.x) with the default router to (192.168.2.1) . The computers are can be separated by the MAC ADDRESS. I tought some thing like bellow, based on sample dhcpd.conf.sample, but was unable to find the correct sintaxe. subnet 192.168.1.0 netmask 255.255.255.0 { option routers 192.168.1.1; option subnet-mask 255.255.255.0; group n1 { hardware ethernet 12:34:56:78:AB:CD; hardware ethernet 13:34:56:78:AB:CD; hardware ethernet 14:34:56:78:AB:CD; hardware ethernet 15:34:56:78:AB:CD; hardware ethernet 16:34:56:78:AB:CD; hardware ethernet 17:34:56:78:AB:CD; } } subnet 192.168.2.0 netmask 255.255.255.0 { option routers 192.168.2.1; option subnet-mask 255.255.255.0; group n2 { hardware ethernet 11:14:56:78:AB:CD; hardware ethernet 11:24:56:78:AB:CD; hardware ethernet 11:34:56:78:AB:CD; hardware ethernet 11:44:56:78:AB:CD; hardware ethernet 11:54:56:78:AB:CD; hardware ethernet 11:64:56:78:AB:CD; } } I am using Linux Mandrake 8.2 with dhcp-server-3.0-1rc8.1mdk Thanks Renato Lins _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jul 26 01:14:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29879; Fri, 26 Jul 2002 01:14:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27903; Fri, 26 Jul 2002 01:14:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27863 for ; Fri, 26 Jul 2002 01:14:50 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29876 for ; Fri, 26 Jul 2002 01:13:43 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn3-44.cisco.com [10.21.64.44]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id BAA18761 for ; Fri, 26 Jul 2002 01:14:16 -0400 (EDT) Message-Id: <4.3.2.7.2.20020726011205.03a20320@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 26 Jul 2002 01:14:13 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call for "Dynamic Host Configuration Protocol (DHCP) Server MIB" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Announcing the WG last call for "DHCP Option for CableLabs Client Configuration", . If you have any comments about this document, please respond to dhcwg@ietf.org. The last call discussion will close on Friday, 8/2/2002. Note that the recent discussion about this draft on the mailing list will be considered when revising the document in response to the WG last call. - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jul 26 14:11:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02757; Fri, 26 Jul 2002 14:11:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12859; Fri, 26 Jul 2002 14:12:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12830 for ; Fri, 26 Jul 2002 14:11:59 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02745 for ; Fri, 26 Jul 2002 14:10:53 -0400 (EDT) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-82.cisco.com [161.44.150.82]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA27785 for ; Fri, 26 Jul 2002 14:11:28 -0400 (EDT) Message-Id: <4.3.2.7.2.20020726141045.01f9f0b8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 26 Jul 2002 14:11:23 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call for "DHCP Option for CableLabs Client Configuration" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org (resend with corrected "Subject:" - RD) Announcing the WG last call for "DHCP Option for CableLabs Client Configuration", . If you have any comments about this document, please respond to dhcwg@ietf.org. The last call discussion will close on Friday, 8/2/2002. Note that the recent discussion about this draft on the mailing list will be considered when revising the document in response to the WG last call. - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jul 29 15:11:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11482; Mon, 29 Jul 2002 15:11:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24188; Mon, 29 Jul 2002 15:11:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24167 for ; Mon, 29 Jul 2002 15:11:56 -0400 (EDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11473 for ; Mon, 29 Jul 2002 15:10:48 -0400 (EDT) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6TJBDe8085070; Mon, 29 Jul 2002 15:11:13 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by northrelay03.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6TJBA9r062198; Mon, 29 Jul 2002 15:11:10 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g6TJAIh02042; Mon, 29 Jul 2002 15:10:18 -0400 Message-Id: <200207291910.g6TJAIh02042@rotala.raleigh.ibm.com> To: "Bernie Volz (EUD)" cc: "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, paduffy@cisco.com Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration In-Reply-To: Message from "Mon, 22 Jul 2002 11:25:38 CDT." <66F66129A77AD411B76200508B65AC69B4D710@EAMBUNT705> Date: Mon, 29 Jul 2002 15:10:17 -0400 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I too, just reviewed this document has have some questions/comments. I agree with Bernie that it's underspecified, and just pointing to the other documents is insufficient. There should be enough text in this document so that a DHC implementor can figure out what to do. 1) It's not clear who sends/uses the options (i.e., the MTS or CM). 2) Its also not clear just what the CM does. Is it being a relay agent that routes DHC packets from MTA's differently than normal DHC packets? Reading between the lines a bit, is the following happening? a) the CM boots first, and requests (and receives?) sub-options 1 & 2. b) any DHC request from the MTA goes through the CM (the CM is in effect a relay agent) and the CM relays the DHC request to the DHC server it learned in step a). The CM knows when it is relaying a MTA option because the MTA includes a CCC option. Is my understanding anywhere near correct at this point? (I have more questions, but the specific questions depend on whether my understanding is anywhere near correct at this point). c) the response from the server to the MTA includes some combination of the remaining suboptions. 3) There are some kerberos-specfic sub-options here. I wonder if they make sense from the kerberos perspective (and will try to find someone who can answer). Reason I say this is I'm aware of an older kerberos ID that put Realm information into a DNS RR, and the realm field was NOT the same as an FQDN (as this ID says it will be) 4) Options 4 & 5 don't make sense to me immediately. Why would the MTA need special DNS servers (as opposed to just using the ones through it's ISP?) And, why can't the normal DNS server option be used here? If the MTA's DHC requests get routed to the TSP-specific DHC server, it can know to return an appropriate DNS server. Why is a special suboption needed? 5) I find it odd that there are retransmission controlling timer settings being communicated via DHC. Is there something broken in Kerberos that requires that standard values be overridden? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jul 29 17:28:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15582; Mon, 29 Jul 2002 17:28:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01473; Mon, 29 Jul 2002 17:29:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01452 for ; Mon, 29 Jul 2002 17:29:18 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15578 for ; Mon, 29 Jul 2002 17:28:11 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g6TLSbi06358; Mon, 29 Jul 2002 16:28:37 -0500 (CDT) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g6TLSax06839; Mon, 29 Jul 2002 16:28:36 -0500 (CDT) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 29 Jul 2002 16:28:36 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D764@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Paul Duffy'" , Thomas Narten Cc: "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration Date: Mon, 29 Jul 2002 16:28:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23746.E57770E6" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C23746.E57770E6 Content-Type: text/plain; charset="iso-8859-1" Given that duplicating a lot of work is likely to be rather useless, what about scaling back the IETF draft to remove much of the text and just have the draft indicate the option number and that there are suboptions and to see the CableLabs document for complete details? With the current draft, there's too much there to make it look like an attempt at a more complete specification. Therefore, removing most of that material and simply using the draft to reserve the option number might be best. This approach also means that the IETF (IANA) is out of managing the suboption space, but I didn't see that you really wanted that anyway. This may also be good since it avoids lots of additional debate as to how the suboptions are used (as I assume that is well documented in the CableLabs documents). The WG and IESG may need to review the CableLabs document to determine whether the usage is in line with DHCP (though I can't see why it wouldn't be). Thomas can probably provide more guidance as to how best to proceed. - Bernie -----Original Message----- From: Paul Duffy [mailto:paduffy@cisco.com] Sent: Monday, July 29, 2002 5:01 PM To: Thomas Narten Cc: Bernie Volz (EUD); 'Ralph Droms'; dhcwg@ietf.org; nrussell@cisco.com; pgrossma@cisco.com; Matt Osman Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration Thomas/Bernie, A few points of clarification: 1. On the advice of several DHCP and Cablelabs experts, we specifically did not duplicate Cablelabs specification content in this draft. We decided to define CCC sub-option syntax and content in the draft, with specific Cablelabs specifications elaborating on exactly how and when the CCC sub-options are used. The idea is to avoid significant duplication of text and the inevitable synchronization problems that would result between multiple documents. 2. CableLabs specifications that employ the CCC option (PacketCable, CableHome, etc.) describe specific CCC option usage. CCC client devices use DHCP option 60 to identify the "client type" or "project", thus telling the DHCP server which CCC sub-options it should be populating in its responses. At 03:10 PM 7/29/2002 -0400, Thomas Narten wrote: >I too, just reviewed this document has have some questions/comments. > >I agree with Bernie that it's underspecified, and just pointing to the >other documents is insufficient. There should be enough text in this >document so that a DHC implementor can figure out what to do. > >1) It's not clear who sends/uses the options (i.e., the MTS or > CM). Per comments above...this information is included in the Cablelab's specs. It was decided to refer to the external spec rather than repeat the information in the draft. >2) Its also not clear just what the CM does. Is it being a relay agent >that routes DHC packets from MTA's differently than normal DHC >packets? No. The CM is not specified to behave as a relay agent. >Reading between the lines a bit, is the following happening? > >a) the CM boots first, and requests (and receives?) sub-options 1 & 2. Correct, from the access provider's infrastructure... >b) any DHC request from the MTA goes through the CM (the CM is in >effect a relay agent) and the CM relays the DHC request to the DHC >server it learned in step a). The CM knows when it is relaying a MTA >option because the MTA includes a CCC option. No. The CM is not specified to behave as a relay agent. >Is my understanding anywhere near correct at this point? (I have more >questions, but the specific questions depend on whether my >understanding is anywhere near correct at this point). > >c) the response from the server to the MTA includes some combination >of the remaining suboptions. ...correct. Sub-option content is determined by the content of option 60 (in the request) >3) There are some kerberos-specfic sub-options here. I wonder if they > make sense from the kerberos perspective (and will try to find > someone who can answer). Reason I say this is I'm aware of an older > kerberos ID that put Realm information into a DNS RR, and the > realm field was NOT the same as an FQDN (as this ID says it will > be) A PacketCable MTA's realm name and domain name are not the same. A PacketCable deployment will typically be a large, multi vendor situation. The authentication realms and domain name space are kept separate. >4) Options 4 & 5 don't make sense to me immediately. Why would the MTA > need special DNS servers (as opposed to just using the ones through > it's ISP?) The PacketCable specs draw a hard line between data access provider and telephony service provider. The access provider is responsible for provisioning the CM, the telephony service provider provisions the MTA. These two business entities are assumed to have their own DHCP and DNS infrastructure. >And, why can't the normal DNS server option be used > here? If the MTA's DHC requests get routed to the TSP-specific DHC > server, it can know to return an appropriate DNS server. Why is a > special suboption needed? CCC sub-options 4/5 allow an optional port number where the standard DNS options do not. >5) I find it odd that there are retransmission controlling timer > settings being communicated via DHC. Is there something broken in > Kerberos that requires that standard values be overridden? They are present to allow boot time configuration of corresponding MIB objects on a device. For finer grained control.... >Thomas I hope this helps. Please let me know if there are any other points I might clarify. Cheers, -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com ------_=_NextPart_001_01C23746.E57770E6 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] DHCP Option for CableLabs Client Configuration

Given that duplicating a lot of work is likely to be rather useless, what about
scaling back the IETF draft to remove much of the text and just have the draft
indicate the option number and that there are suboptions and to see the CableLabs
document for complete details?

With the current draft, there's too much there to make it look like an attempt
at a more complete specification. Therefore, removing most of that material and
simply using the draft to reserve the option number might be best.

This approach also means that the IETF (IANA) is out of managing the suboption
space, but I didn't see that you really wanted that anyway. This may also be
good since it avoids lots of additional debate as to how the suboptions are used
(as I assume that is well documented in the CableLabs documents).

The WG and IESG may need to review the CableLabs document to determine whether
the usage is in line with DHCP (though I can't see why it wouldn't be).

Thomas can probably provide more guidance as to how best to proceed.

- Bernie

-----Original Message-----
From: Paul Duffy [mailto:paduffy@cisco.com]
Sent: Monday, July 29, 2002 5:01 PM
To: Thomas Narten
Cc: Bernie Volz (EUD); 'Ralph Droms'; dhcwg@ietf.org;
nrussell@cisco.com; pgrossma@cisco.com; Matt Osman
Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration


Thomas/Bernie,

A few points of clarification:

1. On the advice of several DHCP and Cablelabs experts, we specifically did
not duplicate Cablelabs specification content in this draft.  We decided to
define CCC sub-option syntax and content in the draft, with specific
Cablelabs specifications elaborating on exactly how and when the CCC
sub-options are used.  The idea is to avoid significant duplication of text
and the inevitable synchronization problems that would result between
multiple documents.

2. CableLabs specifications that employ the CCC option (PacketCable,
CableHome, etc.) describe specific CCC option usage. CCC client devices use
DHCP option 60 to identify the "client type" or "project", thus telling the
DHCP server which CCC sub-options it should be populating in its responses.

At 03:10 PM 7/29/2002 -0400, Thomas Narten wrote:
>I too, just reviewed this document has have some questions/comments.
>
>I agree with Bernie that it's underspecified, and just pointing to the
>other documents is insufficient. There should be enough text in this
>document so that a DHC implementor can figure out what to do.
>
>1) It's not clear who sends/uses the options (i.e., the MTS or
>    CM).

Per comments above...this information is included in the Cablelab's
specs.  It was decided to refer to the external spec rather than repeat the
information in the draft.

>2) Its also not clear just what the CM does. Is it being a relay agent
>that routes DHC packets from MTA's differently than normal DHC
>packets?

No.  The CM is not specified to behave as a relay agent.

>Reading between the lines a bit, is the following happening?
>
>a) the CM boots first, and requests (and receives?) sub-options 1 & 2.

Correct, from the access provider's infrastructure...

>b) any DHC request from the MTA goes through the CM (the CM is in
>effect a relay agent) and the CM relays the DHC request to the DHC
>server it learned in step a). The CM knows when it is relaying a MTA
>option because the MTA includes a CCC option.

No.  The CM is not specified to behave as a relay agent.


>Is my understanding anywhere near correct at this point? (I have more
>questions, but the specific questions depend on whether my
>understanding is anywhere near correct at this point).
>
>c) the response from the server to the MTA includes some combination
>of the remaining suboptions.

...correct.  Sub-option content is determined by the content of option 60
(in the request)


>3) There are some kerberos-specfic sub-options here. I wonder if they
>    make sense from the kerberos perspective (and will try to find
>    someone who can answer). Reason I say this is I'm aware of an older
>    kerberos ID that put Realm information into a  DNS RR, and the
>    realm field was NOT the same as an FQDN (as this ID says it will
>    be)

A PacketCable MTA's realm name and domain name are not the same.  A
PacketCable deployment will typically be a large, multi vendor
situation.  The authentication realms and domain name space are kept
separate.

>4) Options 4 & 5 don't make sense to me immediately. Why would the MTA
>    need special DNS servers (as opposed to just using the ones through
>    it's ISP?)

The PacketCable specs draw a hard line between data access provider and
telephony service provider.  The access provider is responsible for
provisioning the CM, the telephony service provider provisions the
MTA.  These two business entities are assumed to have their own DHCP and
DNS infrastructure.


>And, why can't the normal DNS server option be used
>    here? If the MTA's DHC requests get routed to the TSP-specific DHC
>    server, it can know to return an appropriate DNS server. Why is a
>    special suboption needed?

CCC sub-options 4/5 allow an optional port number where the standard DNS
options do not.


>5) I find it odd that there are retransmission controlling timer
>    settings being communicated via DHC. Is there something broken in
>    Kerberos that requires that standard values be overridden?

They are present to allow boot time configuration of corresponding MIB
objects on a device.  For finer grained control....


>Thomas


I hope this helps.  Please let me know if there are any other points I
might clarify.

Cheers,



--

Paul Duffy
Cisco Systems, Inc.
paduffy@cisco.com

------_=_NextPart_001_01C23746.E57770E6-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jul 30 09:18:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16737; Tue, 30 Jul 2002 09:18:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24532; Tue, 30 Jul 2002 09:16:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24511 for ; Tue, 30 Jul 2002 09:16:53 -0400 (EDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16698 for ; Tue, 30 Jul 2002 09:15:42 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g6UDFvX05467; Tue, 30 Jul 2002 09:15:57 -0400 Message-Id: <200207301315.g6UDFvX05467@cichlid.adsl.duke.edu> To: Paul Duffy cc: "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration In-Reply-To: Message from Paul Duffy of "Mon, 29 Jul 2002 17:00:55 EDT." <4.3.2.7.2.20020729153748.016ebca0@funnel.cisco.com> Date: Tue, 30 Jul 2002 09:15:57 -0400 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Paul, > 1. On the advice of several DHCP and Cablelabs experts, we specifically did > not duplicate Cablelabs specification content in this draft. We decided to > define CCC sub-option syntax and content in the draft, with specific > Cablelabs specifications elaborating on exactly how and when the CCC > sub-options are used. The idea is to avoid significant duplication of text > and the inevitable synchronization problems that would result between > multiple documents. I agree that duplication of text is not a good idea. But this document could include enough background information and details so that one could implement/review it without having to look at the other document. I.e, *this* document should make it clear what the DHCP operations are. The other document can indicate how the values in the option are to be used. Looking at the other document, I see now that: 1) The DHC server is supposed to include the CCC option in its Advertise. The MTA uses that information in selecting a server. This is normal DHCP, and the document could easily make this part clear. 1a) the client identifies itself with a "user class" option, this allows the DHC server to know to include the CCC option. Correct? In any case, the document could easily make it clear what the normal steps are here. 2) Once the MTA has chosen a server, it seems to me like normal DHCP would apply. At this point, some of the specific options don't make sense (or maybe this is a wording thing). > | 4 | MTA | TSP's Primary Domain Name Server Address | > +---------+---------+--------------------------------------------+ > | 5 | MTA | TSP's Secondary Domain Name Server Address | Is there ever a reason for the MTA to use a "normal" DNS server vs. the "TSP DNS"? I would assume not. Thus, the above option appears redundent with the normal DHC option for identifying DNS servers. Can someone clarify here if this is/is not the case? 3) It's not immediately clear whether/how the CM uses these options. They seem specific to the MTA. Does the CM use these options? 4) > | 9 | | Reserved for future CableLabs use | I find it odd that this document says "reserved", when the cablelabs document pretty clearly defines this option and what it means. Please clarify. 5) > 8.1. TSP's DHCP Server Address Sub-Options There are number of formats, some of which include a port number. It appears the MTA takes the DHC server address and sends followup DHC messages to *that* particular server (possibly at a redirected port). This seems like a change to basic DHC behavior on the client. Seems to me that this is inappropriate and unnecessary (at least in some cases). Also, I find it unfortunate that someone outside of the IETF seems to be specifying behavior that changes basic DHCP behavior. First, to redirect the client to a specific DHC server, it would seem better to just have the MTA client pick the server based on the DHC advertisement. This can already be done in DHC today. (i.e, the client just uses the server that sent an advertisement that the MTA liked.) No special option is needed. *If* the DHC WG thinks that modifying the basic DHC client processing rules in order to redirect the client to other servers (and ports) via a specific option is a good idea, it would be better for the WG to define a general way of doing this. Seems to me that Cablelabs is extending/modifying basic DHC processing rules inappropriately, something that the IETF/DHC WG should retain control over. I'd like to better understand the requirements here. > >3) There are some kerberos-specfic sub-options here. I wonder if they > > make sense from the kerberos perspective (and will try to find > > someone who can answer). Reason I say this is I'm aware of an older > > kerberos ID that put Realm information into a DNS RR, and the > > realm field was NOT the same as an FQDN (as this ID says it will > > be) > A PacketCable MTA's realm name and domain name are not the same. A > PacketCable deployment will typically be a large, multi vendor > situation. The authentication realms and domain name space are kept > separate. This is not what I read the document to say: > 8.4. TSP's Kerberos Realm Name Sub-Option > > The PacketCable architecture requires an MTA to authenticate itself > to the TSP's network via the Kerberos protocol. A Kerberos Realm > name is required at the MTA to permit a DNS lookup for the address of > the TSP's Kerberos Key Distribution Center (KDC) entity. > > The Kerberos Realm name is an FQDN. The sub-option is encoded as > follows: I read the above as the Realm name is a FQDN. Please clarify. > >4) Options 4 & 5 don't make sense to me immediately. Why would the MTA > > need special DNS servers (as opposed to just using the ones through > > it's ISP?) > The PacketCable specs draw a hard line between data access provider and > telephony service provider. The access provider is responsible for > provisioning the CM, the telephony service provider provisions the > MTA. These two business entities are assumed to have their own DHCP and > DNS infrastructure. OK. But I think there may be cleaner ways of doing this (using existing DHC mechanisms) than the proposed options. > >And, why can't the normal DNS server option be used > > here? If the MTA's DHC requests get routed to the TSP-specific DHC > > server, it can know to return an appropriate DNS server. Why is a > > special suboption needed? > CCC sub-options 4/5 allow an optional port number where the standard DNS > options do not. How important is this? Is this critical? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jul 30 09:20:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16822; Tue, 30 Jul 2002 09:20:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24756; Tue, 30 Jul 2002 09:21:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24736 for ; Tue, 30 Jul 2002 09:21:23 -0400 (EDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16819 for ; Tue, 30 Jul 2002 09:20:13 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g6UDKRN05488; Tue, 30 Jul 2002 09:20:27 -0400 Message-Id: <200207301320.g6UDKRN05488@cichlid.adsl.duke.edu> To: "Bernie Volz (EUD)" cc: "'Paul Duffy'" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration In-Reply-To: Message from "Bernie Volz (EUD)" of "Mon, 29 Jul 2002 16:28:35 CDT." <66F66129A77AD411B76200508B65AC69B4D764@EAMBUNT705> Date: Tue, 30 Jul 2002 09:20:27 -0400 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Bernie, > Given that duplicating a lot of work is likely to be rather useless, > what about scaling back the IETF draft to remove much of the text > and just have the draft indicate the option number and that there > are suboptions and to see the CableLabs document for complete > details? > With the current draft, there's too much there to make it look like > an attempt at a more complete specification. Therefore, removing > most of that material and simply using the draft to reserve the > option number might be best. I think a better balance can be found. See my other note. > This approach also means that the IETF (IANA) is out of managing the > suboption space, but I didn't see that you really wanted that > anyway. This may also be good since it avoids lots of additional > debate as to how the suboptions are used (as I assume that is well > documented in the CableLabs documents). I disagree strongly with the idea that we give Cablelabs (or any outside organization) a blank check to define options that extend DHC without requiring any formal IETF/WG review. This can result in new sub-options being defined that that don't make sense to us (i.e, modify the protocol itself). Ditto on defining sub options that duplicate existing options. The IETF needs to review DHCP options to make sure they make sense and are consistent with DHC. Remember the Intel PXE option? I recall folks not being terribly happy about that. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jul 30 09:35:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17237; Tue, 30 Jul 2002 09:35:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25964; Tue, 30 Jul 2002 09:36:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25900 for ; Tue, 30 Jul 2002 09:36:25 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17212 for ; Tue, 30 Jul 2002 09:35:15 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g6UDaGl27331; Tue, 30 Jul 2002 08:36:16 -0500 (CDT) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g6UDaGe23920; Tue, 30 Jul 2002 08:36:16 -0500 (CDT) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 30 Jul 2002 08:36:16 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D76C@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" Cc: "'Paul Duffy'" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration Date: Tue, 30 Jul 2002 08:36:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C237CE.12A765AA" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C237CE.12A765AA Content-Type: text/plain; charset="ISO-8859-1" I will defer to Thomas's recommendations. I don't recall the Intel PXE issue because I wasn't actively involved in the DHC WG at that time. - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Tuesday, July 30, 2002 9:20 AM To: Bernie Volz (EUD) Cc: 'Paul Duffy'; 'Ralph Droms'; dhcwg@ietf.org; nrussell@cisco.com; pgrossma@cisco.com; Matt Osman Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration Bernie, > Given that duplicating a lot of work is likely to be rather useless, > what about scaling back the IETF draft to remove much of the text > and just have the draft indicate the option number and that there > are suboptions and to see the CableLabs document for complete > details? > With the current draft, there's too much there to make it look like > an attempt at a more complete specification. Therefore, removing > most of that material and simply using the draft to reserve the > option number might be best. I think a better balance can be found. See my other note. > This approach also means that the IETF (IANA) is out of managing the > suboption space, but I didn't see that you really wanted that > anyway. This may also be good since it avoids lots of additional > debate as to how the suboptions are used (as I assume that is well > documented in the CableLabs documents). I disagree strongly with the idea that we give Cablelabs (or any outside organization) a blank check to define options that extend DHC without requiring any formal IETF/WG review. This can result in new sub-options being defined that that don't make sense to us (i.e, modify the protocol itself). Ditto on defining sub options that duplicate existing options. The IETF needs to review DHCP options to make sure they make sense and are consistent with DHC. Remember the Intel PXE option? I recall folks not being terribly happy about that. Thomas ------_=_NextPart_001_01C237CE.12A765AA Content-Type: text/html; charset="ISO-8859-1" RE: [dhcwg] DHCP Option for CableLabs Client Configuration

I will defer to Thomas's recommendations.

I don't recall the Intel PXE issue because I wasn't actively involved in the DHC WG at that time.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Tuesday, July 30, 2002 9:20 AM
To: Bernie Volz (EUD)
Cc: 'Paul Duffy'; 'Ralph Droms'; dhcwg@ietf.org; nrussell@cisco.com;
pgrossma@cisco.com; Matt Osman
Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration


Bernie,

> Given that duplicating a lot of work is likely to be rather useless,
> what about scaling back the IETF draft to remove much of the text
> and just have the draft indicate the option number and that there
> are suboptions and to see the CableLabs document for complete
> details?

> With the current draft, there's too much there to make it look like
> an attempt at a more complete specification. Therefore, removing
> most of that material and simply using the draft to reserve the
> option number might be best.

I think a better balance can be found. See my other note.

> This approach also means that the IETF (IANA) is out of managing the
> suboption space, but I didn't see that you really wanted that
> anyway. This may also be good since it avoids lots of additional
> debate as to how the suboptions are used (as I assume that is well
> documented in the CableLabs documents).

I disagree strongly with the idea that we give Cablelabs (or any
outside organization) a blank check to define options that extend DHC
without requiring any formal IETF/WG review. This can result in new
sub-options being defined that that don't make sense to us (i.e,
modify the protocol itself). Ditto on defining sub options that
duplicate existing options.

The IETF needs to review DHCP options to make sure they make sense and
are consistent with DHC. Remember the Intel PXE option? I recall folks
not being terribly happy about that.

Thomas

------_=_NextPart_001_01C237CE.12A765AA-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jul 30 15:21:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05709; Tue, 30 Jul 2002 15:21:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19952; Tue, 30 Jul 2002 15:21:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19921 for ; Tue, 30 Jul 2002 15:21:02 -0400 (EDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05635 for ; Tue, 30 Jul 2002 15:19:52 -0400 (EDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6UJKdNv013244; Tue, 30 Jul 2002 15:20:39 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6UJKc7j034100; Tue, 30 Jul 2002 13:20:38 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g6UJJeM08693; Tue, 30 Jul 2002 15:19:40 -0400 Message-Id: <200207301919.g6UJJeM08693@rotala.raleigh.ibm.com> To: Paul Duffy cc: "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration In-Reply-To: Message from "Tue, 30 Jul 2002 12:48:58 EDT." <4.3.2.7.2.20020730104742.028c65d8@funnel.cisco.com> Date: Tue, 30 Jul 2002 15:19:40 -0400 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > We could add a paragraph or two describing, in general terms, that the DHCP > client requests the CCC option and provide option 60 to identify its client > type to the server...the server then determines the CCC sub-option content > that would be included in responses. This would be helpful. > But we would defer to the specific Cablelabs specifications to > define the exact sub-option content in the responses. How does that > sound ? Could you give an example? Are you talking about removing all the text from the current ID? I'm not sure I'm in favor of that either. > >Is there ever a reason for the MTA to use a "normal" DNS server > >vs. the "TSP DNS"? I would assume not. Thus, the above option appears > >redundent with the normal DHC option for identifying DNS servers. Can > >someone clarify here if this is/is not the case? > Again, sub-options 4 and 5 permit port numbers. Normal DNS options > do not... Some comments. First, let's consider the case where the port number version is not used, i.e., DNS servers are accessed at the normal port numbers. In this case, how does this option differ from option 6 (the standard Domain Option)? My sense (from what I understand) is they are the same. In that case, I would say use that option and don't even define a sub-option that allows specification of the DNS server without a port number. No need to define a redundant option. Second, there has apparently not been an issue in general with the Domain Option not specifying an alternate port number, presumably because its not required in general. Why is it required in your spec? Just saying "it's a requirement" isn't very illuminating. > >3) It's not immediately clear whether/how the CM uses these > > options. They seem specific to the MTA. Does the CM use these > > options? > Per the PacketCable specs, MTA uses sub-option 4/5. See the provisioning > flows in the MTA prov spec (referenced in the draft). I just looked at the MTA provising draft. It is not at all clear to me that the CM needs any of these sub-options. Can you please point me to the sections in the document that explain how the CM uses them and what specific sub-options it uses? > >4) > > > > > | 9 | | Reserved for future CableLabs use | > > > >I find it odd that this document says "reserved", when the cablelabs > >document pretty clearly defines this option and what it means. Please > >clarify. > The PacketCable MTA prov spec is incorrect. It will be updated soon. > Sub-option 9's usage was dropped just prior to the draft's posting. The > draft is correct and authoritative regarding sub-option > definitions/syntax. Any duplication of the draft's text in the PacketCable > specs will soon be removed. OK. But I will note that the classification of the document is "ISSUED" (per the cover page), which corresponds to "A stable document, which has undergone rigorous member and vendor review and is suitable for product testing and development, cross-vendor interoperability, and for certification testing." Can you clarify what the next steps for the document are and when it will get updated? > Sub-options 1 and 2 are the mechanism via which the access provider > strictly controls which business entities are permitted to offer > telephony service over its network. This is described in the > PacketCable MTA prov spec. Right. In other words, the MTA needs to use a special DNS server and get special client-specific configuration. What I don't quite understand is why that requires Cablelabs-specific options. This seems (mostly) doable with standard DHCP. In that case, I'd prefer that approach be used to just defining a bunch of specific (redundant) options. Specifically, if the client includes in its Discover with an "I'm a MTA" option, and the DHC servers return an "I'm a MTA DHC server" (which the client then selects), this is all fine and consistent with DHC. From that point on, the MTA DHC server can send it normal options, and those will be interpreted as the ones that the MTA should use. You don't need a special option that says "MTA must use this DNS server rather than the regular server". I'd like to understand what is wrong with the above reasoning. > Do sub-options 1 and 2 really constitute "modifying the basic DHC > client" and "changing basic DHCP behavior"? IMO, Yes. They modify the way the DHC client behaves. Note that DHC clients today can select the server based on what it advertises. But the option you've defined changes that in the following way: - it doesn't say "chose this server that sent you the offer", it seems to say "choose the server whose address is encoded in the sub-option". That's a very different semantic - or, it says, from now on, use a different port number when sending DHCP requests (again, a *very* different semantic). > Cablelabs and the several dozen companies that have vetted this > draft have absolutely no interest in anything but standard > protocols. There are several prototype DHCP servers and multiple > clients running this draft. This is the first mention that > Cablelabs has distorted the basic DHCP protocol. That is why it is important to get DHCP options reviewed within the IETF, where the DHCP experts are. > We look to the DHCP gurus for further guidance here...but PacketCable > requires an "iron fist" mechanism that allows the access provider to > control who is allowed to offer telephony service over its network. I believe that normal DHCP does this already. I don't understand how the proposed extensions are needed (at least in the case of the DHC and DNS options). > > > CCC sub-options 4/5 allow an optional port number where the standard DNS > > > options do not. > > > >How important is this? Is this critical? > Its a requirement of the PacketCable architecture. Why? How important a requirement? Its clearly not needed in all cases, since some forms of the option do not include a port number. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jul 30 16:28:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07664; Tue, 30 Jul 2002 16:28:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23779; Tue, 30 Jul 2002 16:28:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00117 for ; Mon, 29 Jul 2002 17:01:30 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14750 for ; Mon, 29 Jul 2002 17:00:22 -0400 (EDT) Received: from paduffy-w2k.cisco.com (ch2-dhcp150-53.cisco.com [161.44.150.53]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA15380; Mon, 29 Jul 2002 17:00:56 -0400 (EDT) Message-Id: <4.3.2.7.2.20020729153748.016ebca0@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 29 Jul 2002 17:00:55 -0400 To: Thomas Narten From: Paul Duffy Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration Cc: "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman In-Reply-To: <200207291910.g6TJAIh02042@rotala.raleigh.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Thomas/Bernie, A few points of clarification: 1. On the advice of several DHCP and Cablelabs experts, we specifically did not duplicate Cablelabs specification content in this draft. We decided to define CCC sub-option syntax and content in the draft, with specific Cablelabs specifications elaborating on exactly how and when the CCC sub-options are used. The idea is to avoid significant duplication of text and the inevitable synchronization problems that would result between multiple documents. 2. CableLabs specifications that employ the CCC option (PacketCable, CableHome, etc.) describe specific CCC option usage. CCC client devices use DHCP option 60 to identify the "client type" or "project", thus telling the DHCP server which CCC sub-options it should be populating in its responses. At 03:10 PM 7/29/2002 -0400, Thomas Narten wrote: >I too, just reviewed this document has have some questions/comments. > >I agree with Bernie that it's underspecified, and just pointing to the >other documents is insufficient. There should be enough text in this >document so that a DHC implementor can figure out what to do. > >1) It's not clear who sends/uses the options (i.e., the MTS or > CM). Per comments above...this information is included in the Cablelab's specs. It was decided to refer to the external spec rather than repeat the information in the draft. >2) Its also not clear just what the CM does. Is it being a relay agent >that routes DHC packets from MTA's differently than normal DHC >packets? No. The CM is not specified to behave as a relay agent. >Reading between the lines a bit, is the following happening? > >a) the CM boots first, and requests (and receives?) sub-options 1 & 2. Correct, from the access provider's infrastructure... >b) any DHC request from the MTA goes through the CM (the CM is in >effect a relay agent) and the CM relays the DHC request to the DHC >server it learned in step a). The CM knows when it is relaying a MTA >option because the MTA includes a CCC option. No. The CM is not specified to behave as a relay agent. >Is my understanding anywhere near correct at this point? (I have more >questions, but the specific questions depend on whether my >understanding is anywhere near correct at this point). > >c) the response from the server to the MTA includes some combination >of the remaining suboptions. ...correct. Sub-option content is determined by the content of option 60 (in the request) >3) There are some kerberos-specfic sub-options here. I wonder if they > make sense from the kerberos perspective (and will try to find > someone who can answer). Reason I say this is I'm aware of an older > kerberos ID that put Realm information into a DNS RR, and the > realm field was NOT the same as an FQDN (as this ID says it will > be) A PacketCable MTA's realm name and domain name are not the same. A PacketCable deployment will typically be a large, multi vendor situation. The authentication realms and domain name space are kept separate. >4) Options 4 & 5 don't make sense to me immediately. Why would the MTA > need special DNS servers (as opposed to just using the ones through > it's ISP?) The PacketCable specs draw a hard line between data access provider and telephony service provider. The access provider is responsible for provisioning the CM, the telephony service provider provisions the MTA. These two business entities are assumed to have their own DHCP and DNS infrastructure. >And, why can't the normal DNS server option be used > here? If the MTA's DHC requests get routed to the TSP-specific DHC > server, it can know to return an appropriate DNS server. Why is a > special suboption needed? CCC sub-options 4/5 allow an optional port number where the standard DNS options do not. >5) I find it odd that there are retransmission controlling timer > settings being communicated via DHC. Is there something broken in > Kerberos that requires that standard values be overridden? They are present to allow boot time configuration of corresponding MIB objects on a device. For finer grained control.... >Thomas I hope this helps. Please let me know if there are any other points I might clarify. Cheers, -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jul 30 16:31:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07794; Tue, 30 Jul 2002 16:31:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24452; Tue, 30 Jul 2002 16:32:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23398 for ; Tue, 30 Jul 2002 16:18:33 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07463 for ; Tue, 30 Jul 2002 16:17:23 -0400 (EDT) Received: from paduffy-w2k.cisco.com (ch2-dhcp150-53.cisco.com [161.44.150.53]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA05513; Tue, 30 Jul 2002 16:17:58 -0400 (EDT) Message-Id: <4.3.2.7.2.20020730161445.0295e4d0@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Jul 2002 16:17:58 -0400 To: Thomas Narten From: Paul Duffy Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration Cc: "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman In-Reply-To: <200207301315.g6UDFvX05467@cichlid.adsl.duke.edu> References: <4.3.2.7.2.20020729153748.016ebca0@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Thomas...inline.... > > >3) There are some kerberos-specfic sub-options here. I wonder if they > > > make sense from the kerberos perspective (and will try to find > > > someone who can answer). Reason I say this is I'm aware of an older > > > kerberos ID that put Realm information into a DNS RR, and the > > > realm field was NOT the same as an FQDN (as this ID says it will > > > be) > > > A PacketCable MTA's realm name and domain name are not the same. A > > PacketCable deployment will typically be a large, multi vendor > > situation. The authentication realms and domain name space are kept > > separate. > >This is not what I read the document to say: > > > 8.4. TSP's Kerberos Realm Name Sub-Option > > > > The PacketCable architecture requires an MTA to authenticate itself > > to the TSP's network via the Kerberos protocol. A Kerberos Realm > > name is required at the MTA to permit a DNS lookup for the address of > > the TSP's Kerberos Key Distribution Center (KDC) entity. > > > > The Kerberos Realm name is an FQDN. The sub-option is encoded as > > follows: > >I read the above as the Realm name is a FQDN. Please clarify. Looks like we need to correct this section of the draft. It should say the Kerberos Realm name should be encoded per RFC 1510. The Kerberos Realm name is not an FQDN. Cheers, -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jul 30 16:31:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07820; Tue, 30 Jul 2002 16:31:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24468; Tue, 30 Jul 2002 16:32:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08943 for ; Tue, 30 Jul 2002 12:49:32 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27902 for ; Tue, 30 Jul 2002 12:48:25 -0400 (EDT) Received: from paduffy-w2k.cisco.com (ch2-dhcp150-53.cisco.com [161.44.150.53]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA18025; Tue, 30 Jul 2002 12:48:59 -0400 (EDT) Message-Id: <4.3.2.7.2.20020730104742.028c65d8@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Jul 2002 12:48:58 -0400 To: Thomas Narten From: Paul Duffy Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration Cc: "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman In-Reply-To: <200207301315.g6UDFvX05467@cichlid.adsl.duke.edu> References: <4.3.2.7.2.20020729153748.016ebca0@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hi Thomas...inline please... At 09:15 AM 7/30/2002 -0400, Thomas Narten wrote: >Paul, > > > 1. On the advice of several DHCP and Cablelabs experts, we specifically > did > > not duplicate Cablelabs specification content in this draft. We > decided to > > define CCC sub-option syntax and content in the draft, with specific > > Cablelabs specifications elaborating on exactly how and when the CCC > > sub-options are used. The idea is to avoid significant duplication of > text > > and the inevitable synchronization problems that would result between > > multiple documents. > >I agree that duplication of text is not a good idea. But this document >could include enough background information and details so that one >could implement/review it without having to look at the other >document. I.e, *this* document should make it clear what the DHCP >operations are. The other document can indicate how the values in the >option are to be used. Again, we were advised not to do this. This would require significant additions be made to the draft (per multiple Cablelabs projects). This would become a large, difficult synchronization headache. We could add a paragraph or two describing, in general terms, that the DHCP client requests the CCC option and provide option 60 to identify its client type to the server...the server then determines the CCC sub-option content that would be included in responses. But we would defer to the specific Cablelabs specifications to define the exact sub-option content in the responses. How does that sound ? >Looking at the other document, I see now that: > >1) The DHC server is supposed to include the CCC option in its > Advertise. The MTA uses that information in selecting a > server. This is normal DHCP, and the document could easily make > this part clear. > >1a) the client identifies itself with a "user class" option, this > allows the DHC server to know to include the CCC option. Correct? > In any case, the document could easily make it clear what the > normal steps are here. > >2) Once the MTA has chosen a server, it seems to me like normal DHCP > would apply. At this point, some of the specific options don't make > sense (or maybe this is a wording thing). > > > | 4 | MTA | TSP's Primary Domain Name Server Address | > > +---------+---------+--------------------------------------------+ > > | 5 | MTA | TSP's Secondary Domain Name Server Address | > >Is there ever a reason for the MTA to use a "normal" DNS server >vs. the "TSP DNS"? I would assume not. Thus, the above option appears >redundent with the normal DHC option for identifying DNS servers. Can >someone clarify here if this is/is not the case? Again, sub-options 4 and 5 permit port numbers. Normal DNS options do not... >3) It's not immediately clear whether/how the CM uses these > options. They seem specific to the MTA. Does the CM use these > options? Per the PacketCable specs, MTA uses sub-option 4/5. See the provisioning flows in the MTA prov spec (referenced in the draft). >4) > > > | 9 | | Reserved for future CableLabs use | > >I find it odd that this document says "reserved", when the cablelabs >document pretty clearly defines this option and what it means. Please >clarify. The PacketCable MTA prov spec is incorrect. It will be updated soon. Sub-option 9's usage was dropped just prior to the draft's posting. The draft is correct and authoritative regarding sub-option definitions/syntax. Any duplication of the draft's text in the PacketCable specs will soon be removed. >5) > > > 8.1. TSP's DHCP Server Address Sub-Options > >There are number of formats, some of which include a port number. It >appears the MTA takes the DHC server address and sends followup DHC >messages to *that* particular server (possibly at a redirected port). > >This seems like a change to basic DHC behavior on the client. Seems to >me that this is inappropriate and unnecessary (at least in some >cases). Also, I find it unfortunate that someone outside of the IETF >seems to be specifying behavior that changes basic DHCP behavior. > >First, to redirect the client to a specific DHC server, it would seem >better to just have the MTA client pick the server based on the DHC >advertisement. This can already be done in DHC today. (i.e, the client >just uses the server that sent an advertisement that the MTA liked.) >No special option is needed. > >*If* the DHC WG thinks that modifying the basic DHC client processing >rules in order to redirect the client to other servers (and ports) via >a specific option is a good idea, it would be better for the WG to >define a general way of doing this. >Seems to me that Cablelabs is extending/modifying basic DHC processing >rules inappropriately, something that the IETF/DHC WG should retain >control over. > >I'd like to better understand the requirements here. Sub-options 1 and 2 are the mechanism via which the access provider strictly controls which business entities are permitted to offer telephony service over its network. This is described in the PacketCable MTA prov spec. Do sub-options 1 and 2 really constitute "modifying the basic DHC client" and "changing basic DHCP behavior"? Cablelabs and the several dozen companies that have vetted this draft have absolutely no interest in anything but standard protocols. There are several prototype DHCP servers and multiple clients running this draft. This is the first mention that Cablelabs has distorted the basic DHCP protocol. We look to the DHCP gurus for further guidance here...but PacketCable requires an "iron fist" mechanism that allows the access provider to control who is allowed to offer telephony service over its network. > > >3) There are some kerberos-specfic sub-options here. I wonder if they > > > make sense from the kerberos perspective (and will try to find > > > someone who can answer). Reason I say this is I'm aware of an older > > > kerberos ID that put Realm information into a DNS RR, and the > > > realm field was NOT the same as an FQDN (as this ID says it will > > > be) > > > A PacketCable MTA's realm name and domain name are not the same. A > > PacketCable deployment will typically be a large, multi vendor > > situation. The authentication realms and domain name space are kept > > separate. > >This is not what I read the document to say: > > > 8.4. TSP's Kerberos Realm Name Sub-Option > > > > The PacketCable architecture requires an MTA to authenticate itself > > to the TSP's network via the Kerberos protocol. A Kerberos Realm > > name is required at the MTA to permit a DNS lookup for the address of > > the TSP's Kerberos Key Distribution Center (KDC) entity. > > > > The Kerberos Realm name is an FQDN. The sub-option is encoded as > > follows: > >I read the above as the Realm name is a FQDN. Please clarify. I need to review this point. I'll get back to you shortly... > > >4) Options 4 & 5 don't make sense to me immediately. Why would the MTA > > > need special DNS servers (as opposed to just using the ones through > > > it's ISP?) > > > The PacketCable specs draw a hard line between data access provider and > > telephony service provider. The access provider is responsible for > > provisioning the CM, the telephony service provider provisions the > > MTA. These two business entities are assumed to have their own DHCP and > > DNS infrastructure. > >OK. But I think there may be cleaner ways of doing this (using >existing DHC mechanisms) than the proposed options. > > > >And, why can't the normal DNS server option be used > > > here? If the MTA's DHC requests get routed to the TSP-specific DHC > > > server, it can know to return an appropriate DNS server. Why is a > > > special suboption needed? > > > CCC sub-options 4/5 allow an optional port number where the standard DNS > > options do not. > >How important is this? Is this critical? Its a requirement of the PacketCable architecture. >Thomas Cheers, -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jul 31 12:58:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07212; Wed, 31 Jul 2002 12:58:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21655; Wed, 31 Jul 2002 12:58:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21631 for ; Wed, 31 Jul 2002 12:58:08 -0400 (EDT) Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07115 for ; Wed, 31 Jul 2002 12:57:00 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25008; Wed, 31 Jul 2002 10:58:01 -0600 (MDT) Received: from lillen (d-umpk17-99-214.Eng.Sun.COM [129.146.99.214]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g6VGvvg29708; Wed, 31 Jul 2002 18:57:58 +0200 (MEST) Date: Wed, 31 Jul 2002 03:26:43 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration To: Paul Duffy Cc: Thomas Narten , "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman In-Reply-To: "Your message with ID" <4.3.2.7.2.20020730104742.028c65d8@funnel.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > > > CCC sub-options 4/5 allow an optional port number where the standard DNS > > > options do not. > > > >How important is this? Is this critical? > > Its a requirement of the PacketCable architecture. In the Internet architecture the DNS servers/resolvers use a standard port number. Thus it seems like the PacketCable architecture doesn't conform to the Internet architecture. This sure looks odd. Are we (the WG and the IETF) reviewing this draft supposed to blindly agree with the packetcable architecture? Or are we supposed to review that architecture first? Confused Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jul 31 15:57:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15614; Wed, 31 Jul 2002 15:57:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06031; Wed, 31 Jul 2002 15:56:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02498 for ; Wed, 31 Jul 2002 15:15:42 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13967 for ; Wed, 31 Jul 2002 15:14:32 -0400 (EDT) Received: from paduffy-w2k.cisco.com (ch2-dhcp150-53.cisco.com [161.44.150.53]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA23502; Wed, 31 Jul 2002 15:15:09 -0400 (EDT) Message-Id: <4.3.2.7.2.20020731131236.0267ae10@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 31 Jul 2002 15:15:08 -0400 To: Thomas Narten From: Paul Duffy Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration Cc: "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman In-Reply-To: <200207301919.g6UJJeM08693@rotala.raleigh.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Thomas, The high level issues you've raised... 1. Suggested text addition to the draft...generally describe how the CCC option is used.... "Cablelabs client devices will issue DHCP requests that include options 55 and 60. Option 50 will request the CCC option from the DHCP server. Option 60 will specify the specific Cablelabs client type, thus directing the DHCP server to populate specific CCC sub-option content in its responses. The details of which CCC sub-options are populated for each specific client type are spelled out in the various Cablelabs project specifications. For example, the PacketCable MTA Device Provisioning Specification [ref] defines the specific set of CCC sub-options that must be populated in DHCP responses to CMs and MTAs in a PacketCable deployment." The point here is that different Cablelabs client devices will use a different set of CCC sub-options. I don't think we want to get into cross pollinating the various specifications. The CCC option draft describes "what" the option is, the specific Cablelabs specs describe "when" and "how" its used. 2. General PacketCable provisioning flow (as it relates to the CC option). This is a boiled down version of section 7 of the MTA prov spec. I'm NOT suggesting this gets added to the draft. PacketCable device provisioning proceeds as follows. DOCSIS 1.1 provisioning steps: a. CM issues broadcast discover which includes option 60 of "docsis1.1:..." and requests CCC option in option 55. b. One or more offers arrive at the CM. The offers MUST include the CCC option w/ sub-options 1/2. c. CM selects one of the offers containing the CCC option and completes the DHCP exchange. d. CM completes the rest of its DOCSIS provisioning process. The key here is that the access provider's tightly controlled DHCP infrastructure sends the CM a specific list of valid, legal, PacketCable DHCP/DNS/SNMP server addresses for a specific service provider. PacketCable 1.0 scopes Embedded MTAs only, meaning the CM and MTA physically reside in an integrated box. The CCC sub-option 1/2 info is transferred by the CM component to the MTA component (how this occurs is implementation specific). This is the mechanism via which the access provider strictly controls which business entities are allowed to offer PacketCable service (or any other type of service) over its network. It also permits the access provider to direct a specific device to a specific service provider....you can have multiple PacketCable service providers on the same access network. Continuing... PacketCable 1.0 provisioning steps: e.MTA issues broadcast discover which includes option 60 of "pktc1.0:..." and requests CCC option in option 55. f. One or more offers arrive at the MTA. These offers must include the CCC option with sub-options 3, 4, 6 (5, 7, 8, 10, 11 are optional) to be considered "valid". g. The MTA selects a valid offer from the set of DHCP servers identified in CCC sub-option 1/2. h. MTA completes the rest of the DHCP exchange i. MTA completes the rest of the secure provisioning steps The access providers are assumed to be offering multiple types of services (from different business entities) over their data network. The CCC options 1 through 5 are used by the access providers to direct the various client types to a restricted set of infrastructure servers that support the specific service type from a specific service provider. It was felt that this approach also makes the system a bit more difficult to hack. 4. Port numbers on CCC sub-options 1/2/3/4/5 Don't what more I can add here. This has been in the architecture since day one...additional control for the service providers. Your comment suggesting "if no port number, use DHCP option 6, if port number, use CCC sub-option 4/5"... as a developer...I'd rather just deal with the single CCC sub-option 4/5 and leave it at that. The implementation would be simpler (for both client and server). 5. Cablelabs specification development process. Specifcations start out as Works In Progress. Essentially, discussion documents. Following initial agreement by the participants, the WIP goes to a Draft status (D0x). Protoypes are typically developed at this stage. When everyone is satisfied that the Draft will actually work, the spec goes to a Interim stage (I0x). At this point the spec goes under rigorous change control and multiple vendors come out for compliance wave testing at the Cablelabs facility (essentially, a rigorous bake-off). Its typical that a specification will go through several I0x stages. Specifically, the PacketCable MTA prov spec is just now coming up on its I04 release. We will be filing change requests on I04 to clean up the sections that deal with the CCC option. Matt Osman from Cablelabs will have to comment if you need more detail here. Helps ? Cheers, At 03:19 PM 7/30/2002 -0400, Thomas Narten wrote: > > We could add a paragraph or two describing, in general terms, that the > DHCP > > client requests the CCC option and provide option 60 to identify its > client > > type to the server...the server then determines the CCC sub-option content > > that would be included in responses. > >This would be helpful. > > > But we would defer to the specific Cablelabs specifications to > > define the exact sub-option content in the responses. How does that > > sound ? > >Could you give an example? Are you talking about removing all the text >from the current ID? I'm not sure I'm in favor of that either. > > > >Is there ever a reason for the MTA to use a "normal" DNS server > > >vs. the "TSP DNS"? I would assume not. Thus, the above option appears > > >redundent with the normal DHC option for identifying DNS servers. Can > > >someone clarify here if this is/is not the case? > > > Again, sub-options 4 and 5 permit port numbers. Normal DNS options > > do not... > >Some comments. > >First, let's consider the case where the port number version is not >used, i.e., DNS servers are accessed at the normal port numbers. In >this case, how does this option differ from option 6 (the standard >Domain Option)? My sense (from what I understand) is they are the >same. In that case, I would say use that option and don't even define >a sub-option that allows specification of the DNS server without a >port number. No need to define a redundant option. > >Second, there has apparently not been an issue in general with the >Domain Option not specifying an alternate port number, presumably >because its not required in general. Why is it required in your spec? >Just saying "it's a requirement" isn't very illuminating. > > > >3) It's not immediately clear whether/how the CM uses these > > > options. They seem specific to the MTA. Does the CM use these > > > options? > > > Per the PacketCable specs, MTA uses sub-option 4/5. See the provisioning > > flows in the MTA prov spec (referenced in the draft). > >I just looked at the MTA provising draft. It is not at all clear to me >that the CM needs any of these sub-options. Can you please point me to >the sections in the document that explain how the CM uses them and >what specific sub-options it uses? > > > >4) > > > > > > > | 9 | | Reserved for future CableLabs use | > > > > > >I find it odd that this document says "reserved", when the cablelabs > > >document pretty clearly defines this option and what it means. Please > > >clarify. > > > The PacketCable MTA prov spec is incorrect. It will be updated soon. > > Sub-option 9's usage was dropped just prior to the draft's posting. The > > draft is correct and authoritative regarding sub-option > > definitions/syntax. Any duplication of the draft's text in the > PacketCable > > specs will soon be removed. > >OK. But I will note that the classification of the document is >"ISSUED" (per the cover page), which corresponds to > > "A stable document, which has undergone rigorous member and vendor > review and is suitable for product testing and development, cross-vendor > interoperability, and for certification testing." > >Can you clarify what the next steps for the document are and when it >will get updated? > > > Sub-options 1 and 2 are the mechanism via which the access provider > > strictly controls which business entities are permitted to offer > > telephony service over its network. This is described in the > > PacketCable MTA prov spec. > >Right. In other words, the MTA needs to use a special DNS server and >get special client-specific configuration. What I don't quite >understand is why that requires Cablelabs-specific options. This seems >(mostly) doable with standard DHCP. In that case, I'd prefer that >approach be used to just defining a bunch of specific (redundant) >options. > >Specifically, if the client includes in its Discover with an "I'm a >MTA" option, and the DHC servers return an "I'm a MTA DHC server" >(which the client then selects), this is all fine and consistent with >DHC. From that point on, the MTA DHC server can send it normal >options, and those will be interpreted as the ones that the MTA should >use. You don't need a special option that says "MTA must use this DNS >server rather than the regular server". > >I'd like to understand what is wrong with the above reasoning. > > > Do sub-options 1 and 2 really constitute "modifying the basic DHC > > client" and "changing basic DHCP behavior"? > >IMO, Yes. They modify the way the DHC client behaves. Note that DHC >clients today can select the server based on what it advertises. But >the option you've defined changes that in the following way: > > - it doesn't say "chose this server that sent you the offer", it > seems to say "choose the server whose address is encoded in the > sub-option". That's a very different semantic > > - or, it says, from now on, use a different port number when sending > DHCP requests (again, a *very* different semantic). > > > Cablelabs and the several dozen companies that have vetted this > > draft have absolutely no interest in anything but standard > > protocols. There are several prototype DHCP servers and multiple > > clients running this draft. This is the first mention that > > Cablelabs has distorted the basic DHCP protocol. > >That is why it is important to get DHCP options reviewed within the >IETF, where the DHCP experts are. > > > We look to the DHCP gurus for further guidance here...but PacketCable > > requires an "iron fist" mechanism that allows the access provider to > > control who is allowed to offer telephony service over its network. > >I believe that normal DHCP does this already. I don't understand how >the proposed extensions are needed (at least in the case of the DHC >and DNS options). > > > > > CCC sub-options 4/5 allow an optional port number where the > standard DNS > > > > options do not. > > > > > >How important is this? Is this critical? > > > Its a requirement of the PacketCable architecture. > >Why? How important a requirement? Its clearly not needed in all >cases, since some forms of the option do not include a port number. > >Thomas -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jul 31 18:02:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19825; Wed, 31 Jul 2002 18:02:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13670; Wed, 31 Jul 2002 18:01:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13095 for ; Wed, 31 Jul 2002 17:59:12 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19715 for ; Wed, 31 Jul 2002 17:58:03 -0400 (EDT) Received: from paduffy-w2k.cisco.com (ch2-dhcp150-53.cisco.com [161.44.150.53]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA06104; Wed, 31 Jul 2002 17:58:40 -0400 (EDT) Message-Id: <4.3.2.7.2.20020731174815.02675eb8@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 31 Jul 2002 17:58:40 -0400 To: Thomas Narten From: Paul Duffy Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration Cc: "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Futher thoughts from the Cablelabs folks re: the optional port numbers on CCC sub-options 1-5. 1. A primary use case is for testing/lab/trial deployments. The only way to configure an MTA (a headless, embedded device) for a non standard port number would be via the CCC sub-option 4/5 mechanism. 2. Permitting protocol servers to run on a non standard port is not without precedence. Its been pointed out that Paul Vixie's "named" server allows it to be configured on a specific port. Does this mean that Paul is violating Internet Standards ? Come to think of it, I don't think I've ever seen a protocol server that did not permit configuration of its protocol port. Thoughts ? Cheers, ---------------------------------------------------------------- The high level issues you've raised... 1. Suggested text addition to the draft...generally describe how the CCC option is used.... "Cablelabs client devices will issue DHCP requests that include options 55 and 60. Option 50 will request the CCC option from the DHCP server. Option 60 will specify the specific Cablelabs client type, thus directing the DHCP server to populate specific CCC sub-option content in its responses. The details of which CCC sub-options are populated for each specific client type are spelled out in the various Cablelabs project specifications. For example, the PacketCable MTA Device Provisioning Specification [ref] defines the specific set of CCC sub-options that must be populated in DHCP responses to CMs and MTAs in a PacketCable deployment." The point here is that different Cablelabs client devices will use a different set of CCC sub-options. I don't think we want to get into cross pollinating the various specifications. The CCC option draft describes "what" the option is, the specific Cablelabs specs describe "when" and "how" its used. 2. General PacketCable provisioning flow (as it relates to the CC option). This is a boiled down version of section 7 of the MTA prov spec. I'm NOT suggesting this gets added to the draft. PacketCable device provisioning proceeds as follows. DOCSIS 1.1 provisioning steps: a. CM issues broadcast discover which includes option 60 of "docsis1.1:..." and requests CCC option in option 55. b. One or more offers arrive at the CM. The offers MUST include the CCC option w/ sub-options 1/2. c. CM selects one of the offers containing the CCC option and completes the DHCP exchange. d. CM completes the rest of its DOCSIS provisioning process. The key here is that the access provider's tightly controlled DHCP infrastructure sends the CM a specific list of valid, legal, PacketCable DHCP/DNS/SNMP server addresses for a specific service provider. PacketCable 1.0 scopes Embedded MTAs only, meaning the CM and MTA physically reside in an integrated box. The CCC sub-option 1/2 info is transferred by the CM component to the MTA component (how this occurs is implementation specific). This is the mechanism via which the access provider strictly controls which business entities are allowed to offer PacketCable service (or any other type of service) over its network. It also permits the access provider to direct a specific device to a specific service provider....you can have multiple PacketCable service providers on the same access network. Continuing... PacketCable 1.0 provisioning steps: e.MTA issues broadcast discover which includes option 60 of "pktc1.0:..." and requests CCC option in option 55. f. One or more offers arrive at the MTA. These offers must include the CCC option with sub-options 3, 4, 6 (5, 7, 8, 10, 11 are optional) to be considered "valid". g. The MTA selects a valid offer from the set of DHCP servers identified in CCC sub-option 1/2. h. MTA completes the rest of the DHCP exchange i. MTA completes the rest of the secure provisioning steps The access providers are assumed to be offering multiple types of services (from different business entities) over their data network. The CCC options 1 through 5 are used by the access providers to direct the various client types to a restricted set of infrastructure servers that support the specific service type from a specific service provider. It was felt that this approach also makes the system a bit more difficult to hack. 4. Port numbers on CCC sub-options 1/2/3/4/5 Don't what more I can add here. This has been in the architecture since day one...additional control for the service providers. Your comment suggesting "if no port number, use DHCP option 6, if port number, use CCC sub-option 4/5"... as a developer...I'd rather just deal with the single CCC sub-option 4/5 and leave it at that. The implementation would be simpler (for both client and server). 5. Cablelabs specification development process. Specifcations start out as Works In Progress. Essentially, discussion documents. Following initial agreement by the participants, the WIP goes to a Draft status (D0x). Protoypes are typically developed at this stage. When everyone is satisfied that the Draft will actually work, the spec goes to a Interim stage (I0x). At this point the spec goes under rigorous change control and multiple vendors come out for compliance wave testing at the Cablelabs facility (essentially, a rigorous bake-off). Its typical that a specification will go through several I0x stages. Specifically, the PacketCable MTA prov spec is just now coming up on its I04 release. We will be filing change requests on I04 to clean up the sections that deal with the CCC option. Matt Osman from Cablelabs will have to comment if you need more detail here. Helps ? Cheers, At 03:19 PM 7/30/2002 -0400, Thomas Narten wrote: > > We could add a paragraph or two describing, in general terms, that the > DHCP > > client requests the CCC option and provide option 60 to identify its > client > > type to the server...the server then determines the CCC sub-option content > > that would be included in responses. > >This would be helpful. > > > But we would defer to the specific Cablelabs specifications to > > define the exact sub-option content in the responses. How does that > > sound ? > >Could you give an example? Are you talking about removing all the text >from the current ID? I'm not sure I'm in favor of that either. > > > >Is there ever a reason for the MTA to use a "normal" DNS server > > >vs. the "TSP DNS"? I would assume not. Thus, the above option appears > > >redundent with the normal DHC option for identifying DNS servers. Can > > >someone clarify here if this is/is not the case? > > > Again, sub-options 4 and 5 permit port numbers. Normal DNS options > > do not... > >Some comments. > >First, let's consider the case where the port number version is not >used, i.e., DNS servers are accessed at the normal port numbers. In >this case, how does this option differ from option 6 (the standard >Domain Option)? My sense (from what I understand) is they are the >same. In that case, I would say use that option and don't even define >a sub-option that allows specification of the DNS server without a >port number. No need to define a redundant option. > >Second, there has apparently not been an issue in general with the >Domain Option not specifying an alternate port number, presumably >because its not required in general. Why is it required in your spec? >Just saying "it's a requirement" isn't very illuminating. > > > >3) It's not immediately clear whether/how the CM uses these > > > options. They seem specific to the MTA. Does the CM use these > > > options? > > > Per the PacketCable specs, MTA uses sub-option 4/5. See the provisioning > > flows in the MTA prov spec (referenced in the draft). > >I just looked at the MTA provising draft. It is not at all clear to me >that the CM needs any of these sub-options. Can you please point me to >the sections in the document that explain how the CM uses them and >what specific sub-options it uses? > > > >4) > > > > > > > | 9 | | Reserved for future CableLabs use | > > > > > >I find it odd that this document says "reserved", when the cablelabs > > >document pretty clearly defines this option and what it means. Please > > >clarify. > > > The PacketCable MTA prov spec is incorrect. It will be updated soon. > > Sub-option 9's usage was dropped just prior to the draft's posting. The > > draft is correct and authoritative regarding sub-option > > definitions/syntax. Any duplication of the draft's text in the > PacketCable > > specs will soon be removed. > >OK. But I will note that the classification of the document is >"ISSUED" (per the cover page), which corresponds to > > "A stable document, which has undergone rigorous member and vendor > review and is suitable for product testing and development, cross-vendor > interoperability, and for certification testing." > >Can you clarify what the next steps for the document are and when it >will get updated? > > > Sub-options 1 and 2 are the mechanism via which the access provider > > strictly controls which business entities are permitted to offer > > telephony service over its network. This is described in the > > PacketCable MTA prov spec. > >Right. In other words, the MTA needs to use a special DNS server and >get special client-specific configuration. What I don't quite >understand is why that requires Cablelabs-specific options. This seems >(mostly) doable with standard DHCP. In that case, I'd prefer that >approach be used to just defining a bunch of specific (redundant) >options. > >Specifically, if the client includes in its Discover with an "I'm a >MTA" option, and the DHC servers return an "I'm a MTA DHC server" >(which the client then selects), this is all fine and consistent with >DHC. From that point on, the MTA DHC server can send it normal >options, and those will be interpreted as the ones that the MTA should >use. You don't need a special option that says "MTA must use this DNS >server rather than the regular server". > >I'd like to understand what is wrong with the above reasoning. > > > Do sub-options 1 and 2 really constitute "modifying the basic DHC > > client" and "changing basic DHCP behavior"? > >IMO, Yes. They modify the way the DHC client behaves. Note that DHC >clients today can select the server based on what it advertises. But >the option you've defined changes that in the following way: > > - it doesn't say "chose this server that sent you the offer", it > seems to say "choose the server whose address is encoded in the > sub-option". That's a very different semantic > > - or, it says, from now on, use a different port number when sending > DHCP requests (again, a *very* different semantic). > > > Cablelabs and the several dozen companies that have vetted this > > draft have absolutely no interest in anything but standard > > protocols. There are several prototype DHCP servers and multiple > > clients running this draft. This is the first mention that > > Cablelabs has distorted the basic DHCP protocol. > >That is why it is important to get DHCP options reviewed within the >IETF, where the DHCP experts are. > > > We look to the DHCP gurus for further guidance here...but PacketCable > > requires an "iron fist" mechanism that allows the access provider to > > control who is allowed to offer telephony service over its network. > >I believe that normal DHCP does this already. I don't understand how >the proposed extensions are needed (at least in the case of the DHC >and DNS options). > > > > > CCC sub-options 4/5 allow an optional port number where the > standard DNS > > > > options do not. > > > > > >How important is this? Is this critical? > > > Its a requirement of the PacketCable architecture. > >Why? How important a requirement? Its clearly not needed in all >cases, since some forms of the option do not include a port number. > >Thomas -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg