From owner-dhcp-v4@bucknell.edu Thu Jun 1 08:25:12 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21408 for ; Thu, 1 Jun 2000 08:25:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e51CL7W21535; Thu, 1 Jun 2000 08:21:09 -0400 (EDT) Received: from hotmail.com (law2-f168.hotmail.com [216.32.181.168]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e51CKxW21030 for ; Thu, 1 Jun 2000 08:20:59 -0400 (EDT) Received: (qmail 453 invoked by uid 0); 1 Jun 2000 12:20:43 -0000 Message-ID: <20000601122043.452.qmail@hotmail.com> Received: from 195.77.235.2 by www.hotmail.com with HTTP; Thu, 01 Jun 2000 05:20:43 PDT X-Originating-IP: [195.77.235.2] From: "Marc" To: DHCPv4 discussion list Subject: DHCP Server with two NIC's Date: Thu, 01 Jun 2000 14:20:43 CEST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Reply-To: marc_jaumandreu@hotmail.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I have a NT Server 4.0 with a DHCP Server on a Token-Ring network. The server has a class C IP address. I need add one more NIC, because the complicated of the network doesn't permit more than one IP for NIC neither change the subnetmask. So, at this point, that's the question: Is compatible a DHCP Server working with two network cards, everyone with their class C IP address and both with the same subnet mask (255.255.255.0)? If yes, then: - The existing IP address is 192.28.88.40 (subnet mask 255.255.255.0), serving the hosts compressed in 192.28.88.0 network. Can i add, for example, the next IP address?: 192.28.89.40 (subnet mask 255.255.255.0)to serve the new hosts compressed in 192.28.89.0 network? - In the DHCP Manager (or i don't know where) how can i bind the network cards with their respective IP address? Do i need create two scopes, one for every NIC? ... or what?? - Do i need activate IP Routing on the server? Thanks for all ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-dhcp-v4@bucknell.edu Fri Jun 2 06:45:42 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27582 for ; Fri, 2 Jun 2000 06:45:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e52AgQW31833; Fri, 2 Jun 2000 06:42:26 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e52AgKW31775 for ; Fri, 2 Jun 2000 06:42:20 -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 GAA27417; Fri, 2 Jun 2000 06:42:19 -0400 (EDT) Message-Id: <200006021042.GAA27417@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-new-opt-msg-00.txt Date: Fri, 02 Jun 2000 06:42:18 -0400 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --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 : Procedure for Defining New DHCP Options and Message Types Author(s) : R. Droms Filename : draft-ietf-dhc-new-opt-msg-00.txt Pages : 6 Date : 01-Jun-00 The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in tagged data items that are stored in the 'options' field of the DHCP message. The data items themselves are also called 'options.' DHCP protocol messages are identified by the 'DHCP Message Type' option (option code 51). Each message type is defined by the data value carried in the 'DHCP Message Type' option. New DHCP options and message types may be defined after the publication of the DHCP specification to accommodate requirements for conveyance of new configuration parameters or to accommodate new protocol semantics. This document describes the procedure for defining new DHCP options and message types. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-new-opt-msg-00.txt 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-new-opt-msg-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-new-opt-msg-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000601103455.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-new-opt-msg-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-new-opt-msg-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000601103455.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Fri Jun 2 07:27:48 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28644 for ; Fri, 2 Jun 2000 07:27:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e52BP1W01089; Fri, 2 Jun 2000 07:25:01 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e52BOxW00187 for ; Fri, 2 Jun 2000 07:24:59 -0400 (EDT) Received: from droms-mac (rtp-dial-1-237.cisco.com [10.83.97.237]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA26296 for ; Fri, 2 Jun 2000 07:24:41 -0400 (EDT) Message-Id: <4.2.2.20000602071353.00a501d0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 02 Jun 2000 07:24:22 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Update to RFC 2489 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I've published "Procedure for Defining New DHCP Options and Message Types" , which is intended to replace RFC 2489. The new I-D gives a procedure for issuing new DHCP message types as well as new option codes. We need to have this procedure in place to assign a new message type code for the RECONFIGURE option as described in . The draft mentions the new options review procedure, which is currently documented in draft-ietf-dhc-option-review-and-namespace-02.txt, and requires that new options and message types be reviewed through any new procedure accepted by the DHC WG. This new document is a simple update to the current procedure for accepting new options. If the document is not controversial, I will fast-track it through the WG and go to last call some time next week. If the WG would like to engage in a longer discussion, the document will go through the normal WG review procedure. Please review the document and reply to the mailing list with comments... - Ralph From owner-dhcp-v4@bucknell.edu Fri Jun 2 13:37:19 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08107 for ; Fri, 2 Jun 2000 13:37:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e52HWxW20430; Fri, 2 Jun 2000 13:33:00 -0400 (EDT) Received: from gigi.excite.com ([199.172.152.110]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e52HWlW16614 for ; Fri, 2 Jun 2000 13:32:47 -0400 (EDT) Received: from prickles ([199.172.153.88]) by gigi.excite.com (InterMail vM.4.01.02.39 201-229-119-122) with ESMTP id <20000602173226.BJVS8271.gigi.excite.com@prickles> for ; Fri, 2 Jun 2000 10:32:26 -0700 Message-ID: <20413945.959967146679.JavaMail.imail@prickles> Date: Fri, 2 Jun 2000 10:32:26 -0700 (PDT) From: Joe Chromcik To: DHCPv4 discussion list Subject: Windows 98 DHCP Problem Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Excite Inbox X-Sender-Ip: 63.91.93.142 Reply-To: jchromcik@excite.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Sorry for the broadcast but I am looking for Matthew Williams. We were communicating a little while back about a Windows 98 DHCP issue and I setup the Network Monitor to capture traffic between the client and the server. Matt can you please respond back to me. Joe Chromcik _______________________________________________________ Get 100% FREE Internet Access powered by Excite Visit http://freelane.excite.com/freeisp From owner-dhcp-v6@bucknell.edu Tue Jun 6 14:57:01 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17081 for ; Tue, 6 Jun 2000 14:57:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e56IqmW06808; Tue, 6 Jun 2000 14:52:48 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e56IqYW09449; Tue, 6 Jun 2000 14:52:34 -0400 (EDT) Received: from droms-mac (sj-dial-3-128.cisco.com [171.68.180.129]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA18623; Tue, 6 Jun 2000 14:52:16 -0400 (EDT) Message-Id: <4.2.2.20000606144908.00a2e7c0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 06 Jun 2000 14:51:38 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: DHC WG meetings in Pittsburgh Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I'm about to request DHC WG meeting slots for the IETF in Pittsburgh. Due to other commitments I have for later in the week, the WG meetings will be scheduled for Monday and Tuesday. I will ask to avoid conflicts with zeroconf, mobile IP and IPng. Please let me know if there are other WG meeting conflicts with the DHC meetings you would like to avoid. - Ralph From owner-dhcp-v4@bucknell.edu Tue Jun 6 14:57:15 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17102 for ; Tue, 6 Jun 2000 14:57:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e56IqmW01920; Tue, 6 Jun 2000 14:52:48 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e56IqYW09449; Tue, 6 Jun 2000 14:52:34 -0400 (EDT) Received: from droms-mac (sj-dial-3-128.cisco.com [171.68.180.129]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA18623; Tue, 6 Jun 2000 14:52:16 -0400 (EDT) Message-Id: <4.2.2.20000606144908.00a2e7c0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 06 Jun 2000 14:51:38 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: DHC WG meetings in Pittsburgh Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I'm about to request DHC WG meeting slots for the IETF in Pittsburgh. Due to other commitments I have for later in the week, the WG meetings will be scheduled for Monday and Tuesday. I will ask to avoid conflicts with zeroconf, mobile IP and IPng. Please let me know if there are other WG meeting conflicts with the DHC meetings you would like to avoid. - Ralph From owner-dhcp-v4@bucknell.edu Tue Jun 6 16:01:05 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18340 for ; Tue, 6 Jun 2000 16:01:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e56Jv1W12859; Tue, 6 Jun 2000 15:57:01 -0400 (EDT) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e56JulW21221; Tue, 6 Jun 2000 15:56:48 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA06884; Tue, 6 Jun 2000 15:56:30 -0400 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.60.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA30466; Tue, 6 Jun 2000 15:56:30 -0400 Received: from ludwigia.raleigh.ibm.com (localhost [127.0.0.1]) by ludwigia.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id PAA06415; Tue, 6 Jun 2000 15:56:05 -0400 Message-Id: <200006061956.PAA06415@ludwigia.raleigh.ibm.com> To: DHCPv4 discussion list cc: "Ralph E. Droms" , DHCPv4 discussion list Subject: Comments on draft-ietf-dhc-userclass-05.txt Date: Tue, 06 Jun 2000 15:56:05 -0400 From: Thomas Narten Reply-To: narten@raleigh.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ralph has asked that this document be advanced as a PS. In reviewing this document, I have the following comments. I think it would be best to get the document revised once more before issuing the IETF last call. Can this be done quickly? > The code for this option is TBD. The document lists the user class option as TBD. Isn't this option 77 as already assigned by IANA? From http://www.isi.edu/in-notes/iana/assignments/bootp-dhcp-parameters: > 77 User-Class N User Class Information I would suggest making this clear in the document, and then adding an IANA Considerations section that simply states that option 77, which IANA has already assigned for this purpose, should be used. > Each User Class value is indicated in an opaque field and is > preceded by a one-byte field giving its length. > Let n be the number of User Classes carried in the > option. The length of the option as specified in Len must be > the sum of the lengths of each of the class names plus n: > Len= Len1 + Len2 + ...+ Lenn + n. > > Code Len Len1 Len2 > +-----+-----+-----+----------+-----+--------------+---- > | TBD | N | L1 | class 1 | L2 | class 2 |... > +-----+-----+-----+----------+-----+--------------+---- I think it would be good to more clearly define the length values. I got confused at first because I had assumed that the length byte also included the length field itself (it does in some protocols). This is apparently not the case here. I.e., add the phrase "the value in the User Class length field not include the length field itself" after the first sentence in the paragraph above. > 5. Security Considerations I think you should also add a paragraph specifically pointing out that because of existing DHCP vulnerabilities, some of the specific example uses for the user class option given this document need to be considered carefully. I.e, if the user class option will be used to give out special IP addresses that have better QOS associated with it, but there is no way to authtenticate a client, there is a vulnerability here. > 7. Acknowledgments > This document combines ideas from draft-ietf-dhc-userclass-03.txt > (by Glenn Stump and Ralph Droms) and > draft-ietf-dhc-useraddr-00.txt (by Ye Gu, Ramesh Vyaghrapuri and > Burcak Beser). It has been published as a revision to > draft-ietf-dhc-userclass-05.txt. A nit, but the document (when published as an RFC) can't have references to drafts. Best not to mention the drafts by name and just say something like "based on earlier drafts by ..." I think it would be good to reissue this document before having the IETF Last Call. The IANA-related material in particular is reviewed by IANA during the last call, so it would be good to get it in order. Jerome, can you get this ID reissued quickly? Thomas From owner-dhcp-v4@bucknell.edu Tue Jun 6 16:24:48 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18653 for ; Tue, 6 Jun 2000 16:24:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e56KNcW18563; Tue, 6 Jun 2000 16:23:38 -0400 (EDT) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e56KNRW25907; Tue, 6 Jun 2000 16:23:27 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA23634; Tue, 6 Jun 2000 16:23:08 -0400 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.60.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA21532; Tue, 6 Jun 2000 16:23:09 -0400 Received: from ludwigia.raleigh.ibm.com (localhost [127.0.0.1]) by ludwigia.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id QAA06516; Tue, 6 Jun 2000 16:22:43 -0400 Message-Id: <200006062022.QAA06516@ludwigia.raleigh.ibm.com> To: DHCPv4 discussion list cc: "Ralph E. Droms" , DHCPv4 discussion list Subject: draft-ietf-dhc-subnet-option-04.txt Date: Tue, 06 Jun 2000 16:22:43 -0400 From: Thomas Narten Reply-To: narten@raleigh.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ralph has indicated that this document is ready for advancement as a PS. In reviewing this document, I have the following comments. Question: how does this option relate to the ongoing work on DHCP authentication? My understanding is that from a DHCP perspective, there should be no conflict because a DHCP client adds this option, and if it includes an authentication option, the authentication would cover the subnet selection option. Right? I.e., the "client" we normally think of as being the DHCP client (i.e, the end machine that gets the address) doesn't actually exist in this picture. This option is used by a proxy that is requesting addresses on behalf of the "real" client, and the details of the interaction between the proxy and "real" client aren't important. Does this make sense? Thomas From owner-dhcp-v4@bucknell.edu Tue Jun 6 20:00:28 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20836 for ; Tue, 6 Jun 2000 20:00:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e56Nv6W16703; Tue, 6 Jun 2000 19:57:06 -0400 (EDT) Received: from mail.ultradns.com (IDENT:qmailr@[64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e56NuuW15836 for ; Tue, 6 Jun 2000 19:56:56 -0400 (EDT) Received: (qmail 5993 invoked from network); 6 Jun 2000 23:59:10 -0000 Received: from unknown (HELO ULTRADNS6PMNFK) (12.22.21.65) by mail.ultradns.com with SMTP; 6 Jun 2000 23:59:10 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: Comments on draft-ietf-dhc-userclass-05.txt Date: Tue, 6 Jun 2000 16:59:17 -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.2911.0) In-Reply-To: <200006061956.PAA06415@ludwigia.raleigh.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Jerome-- Based on Thomas' comments, I reassert my suggestion for improving the wording about the length octets [see earlier comments to WG Last Call]. --Barr > -----Original Message----- > From: owner-dhcp-v4@bucknell.edu [mailto:owner-dhcp-v4@bucknell.edu]On > Behalf Of Thomas Narten > Sent: Tuesday, June 06, 2000 12:56 PM > > > Each User Class value is indicated in an opaque field and is > > preceded by a one-byte field giving its length. > > Let n be the number of User Classes carried in the > > option. The length of the option as specified in Len must be > > the sum of the lengths of each of the class names plus n: > > Len= Len1 + Len2 + ...+ Lenn + n. > > > > Code Len Len1 Len2 > > +-----+-----+-----+----------+-----+--------------+---- > > | TBD | N | L1 | class 1 | L2 | class 2 |... > > +-----+-----+-----+----------+-----+--------------+---- > > I think it would be good to more clearly define the length values. I > got confused at first because I had assumed that the length byte also > included the length field itself (it does in some protocols). This is > apparently not the case here. I.e., add the phrase "the value in the > User Class length field not include the length field itself" after the > first sentence in the paragraph above. > > > I think it would be good to reissue this document before having the > IETF Last Call. The IANA-related material in particular is reviewed by > IANA during the last call, so it would be good to get it in > order. Jerome, can you get this ID reissued quickly? > From owner-dhcp-v4@bucknell.edu Wed Jun 7 04:15:03 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07779 for ; Wed, 7 Jun 2000 04:15:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5782CW17300; Wed, 7 Jun 2000 04:02:12 -0400 (EDT) Received: from hotmail.com (law2-f144.hotmail.com [216.32.181.144]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e57822W18037 for ; Wed, 7 Jun 2000 04:02:02 -0400 (EDT) Received: (qmail 6679 invoked by uid 0); 7 Jun 2000 08:01:43 -0000 Message-ID: <20000607080143.6678.qmail@hotmail.com> Received: from 195.77.235.2 by www.hotmail.com with HTTP; Wed, 07 Jun 2000 01:01:42 PDT X-Originating-IP: [195.77.235.2] From: "Marc" To: DHCPv4 discussion list Subject: Copy files to drive A reboots NT Server Date: Wed, 07 Jun 2000 10:01:42 CEST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Reply-To: marc_jaumandreu@hotmail.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN When i copy some files froma a local or network drive to drive A, the server automatically reboots without any error message. It occurs usually with IBm PC Servers 310 and IBM Netfinity 3000 models. Any help? Thanks to all ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-dhcp-v4@bucknell.edu Wed Jun 7 05:30:34 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08179 for ; Wed, 7 Jun 2000 05:30:32 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e579K7W19268; Wed, 7 Jun 2000 05:20:07 -0400 (EDT) Received: from gandalf.axion.bt.co.uk (gandalf.axion.bt.co.uk [132.146.17.29]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e579JtW21934; Wed, 7 Jun 2000 05:19:55 -0400 (EDT) Received: from cbtlipnt02.btlabs.bt.co.uk by gandalf (local) with ESMTP; Wed, 7 Jun 2000 10:18:14 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id ; Wed, 7 Jun 2000 10:17:41 +0100 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB207E897FD@mbtlipnt02.btlabs.bt.co.uk> From: jerome.privat@bt.com To: DHCPv4 discussion list Cc: droms@bucknell.edu, dhcp-v4@bucknell.edu Subject: RE: Comments on draft-ietf-dhc-userclass-05.txt Date: Wed, 7 Jun 2000 10:17:43 +0100 X-Mailer: Internet Mail Service (5.5.2651.88) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Reply-To: jerome.privat@bt.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Thomas, Thanks for your comments. I have revised the document to take into account all your comments. I have also clarified (and made more explicit) the description of the option as suggested by Barr during WG last call. I have just submitted this new issue of the draft (draft-ietf-dhc-userclass-08.txt) to the IETF. Let me know if we can go to IETF Last Call with this new issue. Jerome -----Original Message----- From: Thomas Narten [mailto:narten@raleigh.ibm.com] Sent: 06 June 2000 20:56 To: jerome.privat@bt.com Cc: Ralph E. Droms; DHCPv4 discussion list Subject: Comments on draft-ietf-dhc-userclass-05.txt Ralph has asked that this document be advanced as a PS. In reviewing this document, I have the following comments. I think it would be best to get the document revised once more before issuing the IETF last call. Can this be done quickly? > The code for this option is TBD. The document lists the user class option as TBD. Isn't this option 77 as already assigned by IANA? From http://www.isi.edu/in-notes/iana/assignments/bootp-dhcp-parameters: > 77 User-Class N User Class Information I would suggest making this clear in the document, and then adding an IANA Considerations section that simply states that option 77, which IANA has already assigned for this purpose, should be used. > Each User Class value is indicated in an opaque field and is > preceded by a one-byte field giving its length. > Let n be the number of User Classes carried in the > option. The length of the option as specified in Len must be > the sum of the lengths of each of the class names plus n: > Len= Len1 + Len2 + ...+ Lenn + n. > > Code Len Len1 Len2 > +-----+-----+-----+----------+-----+--------------+---- > | TBD | N | L1 | class 1 | L2 | class 2 |... > +-----+-----+-----+----------+-----+--------------+---- I think it would be good to more clearly define the length values. I got confused at first because I had assumed that the length byte also included the length field itself (it does in some protocols). This is apparently not the case here. I.e., add the phrase "the value in the User Class length field not include the length field itself" after the first sentence in the paragraph above. > 5. Security Considerations I think you should also add a paragraph specifically pointing out that because of existing DHCP vulnerabilities, some of the specific example uses for the user class option given this document need to be considered carefully. I.e, if the user class option will be used to give out special IP addresses that have better QOS associated with it, but there is no way to authtenticate a client, there is a vulnerability here. > 7. Acknowledgments > This document combines ideas from draft-ietf-dhc-userclass-03.txt > (by Glenn Stump and Ralph Droms) and > draft-ietf-dhc-useraddr-00.txt (by Ye Gu, Ramesh Vyaghrapuri and > Burcak Beser). It has been published as a revision to > draft-ietf-dhc-userclass-05.txt. A nit, but the document (when published as an RFC) can't have references to drafts. Best not to mention the drafts by name and just say something like "based on earlier drafts by ..." I think it would be good to reissue this document before having the IETF Last Call. The IANA-related material in particular is reviewed by IANA during the last call, so it would be good to get it in order. Jerome, can you get this ID reissued quickly? Thomas From owner-dhcp-v4@bucknell.edu Wed Jun 7 06:47:47 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08715 for ; Wed, 7 Jun 2000 06:47:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e57AgXW24144; Wed, 7 Jun 2000 06:42:33 -0400 (EDT) Received: from hygro.adsl.duke.edu (IDENT:root@hygro.adsl.duke.edu [152.16.64.159]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e57AgWW24707; Wed, 7 Jun 2000 06:42:32 -0400 (EDT) Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1]) by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id GAA02497; Wed, 7 Jun 2000 06:42:47 -0400 Message-Id: <200006071042.GAA02497@hygro.adsl.duke.edu> To: DHCPv4 discussion list cc: droms@bucknell.edu, dhcp-v4@bucknell.edu Subject: Re: Comments on draft-ietf-dhc-userclass-05.txt In-Reply-To: Message from jerome.privat@bt.com of "Wed, 07 Jun 2000 10:17:43 BST." <5104D4DBC598D211B5FE0000F8FE7EB207E897FD@mbtlipnt02.btlabs.bt.co.uk> Date: Wed, 07 Jun 2000 06:42:47 -0400 From: Thomas Narten Reply-To: narten@raleigh.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Jerome, > I have just submitted this new issue of the draft > (draft-ietf-dhc-userclass-08.txt) to the IETF. Great! > Let me know if we can go to IETF Last Call with this new issue. As soon as the new ID shows up and the announcement goes out. I.e., real soon. Thomas From owner-dhcp-v4@bucknell.edu Wed Jun 7 09:35:55 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10344 for ; Wed, 7 Jun 2000 09:35:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e57DInW06409; Wed, 7 Jun 2000 09:18:49 -0400 (EDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e57DIjW06394; Wed, 7 Jun 2000 09:18:45 -0400 (EDT) Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprch1.nortel.com; Wed, 7 Jun 2000 08:17:53 -0500 Received: from zcard00b.ca.nortel.com ([47.128.208.105]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id M34FK61L; Wed, 7 Jun 2000 09:17:46 -0400 Received: from netgww (NET-GWW [141.251.80.128]) by zcard00b.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LAJ76655; Wed, 7 Jun 2000 09:17:44 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Glenn Waters" To: DHCPv4 discussion list Cc: "Ralph E. Droms" , DHCPv4 discussion list Subject: RE: draft-ietf-dhc-subnet-option-04.txt Date: Wed, 7 Jun 2000 09:17:25 -0400 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.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <200006062022.QAA06516@ludwigia.raleigh.ibm.com> Reply-To: gww@nortelnetworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit -----Original Message----- From: Thomas Narten [mailto:narten@raleigh.ibm.com] Sent: Tuesday, June 6, 2000 16:23 To: Waters, Glenn Cc: Ralph E. Droms; DHCPv4 discussion list Subject: draft-ietf-dhc-subnet-option-04.txt Ralph has indicated that this document is ready for advancement as a PS. In reviewing this document, I have the following comments. Question: how does this option relate to the ongoing work on DHCP authentication? My understanding is that from a DHCP perspective, there should be no conflict because a DHCP client adds this option, and if it includes an authentication option, the authentication would cover the subnet selection option. Right? [gww] Right. I.e., the "client" we normally think of as being the DHCP client (i.e, the end machine that gets the address) doesn't actually exist in this picture. This option is used by a proxy that is requesting addresses on behalf of the "real" client, and the details of the interaction between the proxy and "real" client aren't important. Does this make sense? [gww] This all makes sense and is exactly correct. Thomas Cheers, /gww From owner-dhcp-v4@bucknell.edu Wed Jun 7 12:34:35 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15411 for ; Wed, 7 Jun 2000 12:34:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e57GUwW07886; Wed, 7 Jun 2000 12:30:58 -0400 (EDT) Received: from gandalf.axion.bt.co.uk (gandalf.axion.bt.co.uk [132.146.17.29]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e57GUsW09421 for ; Wed, 7 Jun 2000 12:30:54 -0400 (EDT) Received: from cbtlipnt01.btlabs.bt.co.uk by gandalf (local) with ESMTP; Wed, 7 Jun 2000 17:06:07 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id ; Wed, 7 Jun 2000 17:06:19 +0100 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB207E89805@mbtlipnt02.btlabs.bt.co.uk> From: jerome.privat@bt.com To: DHCPv4 discussion list Subject: User class: last changes Date: Wed, 7 Jun 2000 17:05:35 +0100 X-Mailer: Internet Mail Service (5.5.2651.88) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Reply-To: jerome.privat@bt.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Here are the changes I made to the draft in response to Thomas' comments (and Barr's suggestion) so that people in this mailing list can have a quick check if they wish. * Format of the option The format of this option is as follows: Code Len Value +-----+-----+--------------------- . . . --+ | 77 | N | User Class Data ('Len' octets) | +-----+-----+--------------------- . . . --+ where Value consists of zero or more instances of User Class Data. Each instance of User Class Data is formatted as follows: UC_Len_i User_Class_Data_i +--------+------------------------ . . . --+ | L_i | Opaque-Data ('UC_Len_i' octets) | +--------+------------------------ . . . --+ Each User Class value (User_Class_Data_i) is indicated as an opaque field. The value in UC_Len_i does not include the length field itself and MUST be non-zero. Let m be the number of User Classes carried in the option. The length of the option as specified in Len must be the sum of the lengths of each of the class names plus m: Len= UC_Len_1 + UC_Len_2 + ... + UC_Len_m + m. If any instances of User Class Data are present, the minimum value of Len is two (Len = UC_Len_1 + 1 = 1 + 1 = 2). The Code for this option is 77. * IANA Considerations Option 77, which IANA has already assigned for this purpose, should be used as the User Class Option for DHCP. * Security Considerations DHCP currently provides no authentication or security mechanisms. Potential exposures to attack are discussed is section 7 of the protocol specification [1]. This lack of authentication mechanism means that a DHCP server cannot check if a client or user is authorised to use a given User Class. This introduces an obvious vulnerability when using the User Class option. For example, if the User Class is used to give out special IP addresses that have better QoS associated with them (as described in section 1), there is no way to authenticate a client and it is therefore impossible to check if a client is authorised to use such an IP address. Jerome From owner-dhcp-v4@bucknell.edu Wed Jun 7 12:41:23 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15611 for ; Wed, 7 Jun 2000 12:41:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e57GebW31328; Wed, 7 Jun 2000 12:40:37 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e57GeMW10247 for ; Wed, 7 Jun 2000 12:40:22 -0400 (EDT) Received: from grosse.manhattan.fugue.com (a1.pm3-53.theriver.com [208.164.100.65]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id RAA15390; Tue, 6 Jun 2000 17:59:05 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id JAA00606; Wed, 7 Jun 2000 09:38:55 -0700 (MST) Message-Id: <200006071638.JAA00606@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: User class: last changes In-Reply-To: Message from jerome.privat@bt.com of "Wed, 07 Jun 2000 17:05:35 +0100." <5104D4DBC598D211B5FE0000F8FE7EB207E89805@mbtlipnt02.btlabs.bt.co.uk> Date: Wed, 07 Jun 2000 09:38:55 -0700 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Here are the changes I made to the draft in response to Thomas' comments > (and Barr's suggestion) so that people in this mailing list can have a > quick check if they wish. Nice! This makes it a lot clearer - although I think it was complete before, it's even better now. :') _MelloN_ From owner-dhcp-v4@bucknell.edu Thu Jun 8 06:48:08 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10666 for ; Thu, 8 Jun 2000 06:48:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e58AgYW10921; Thu, 8 Jun 2000 06:42:34 -0400 (EDT) Received: from hotmail.com (law2-f184.hotmail.com [216.32.181.184]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e58AgPW14492 for ; Thu, 8 Jun 2000 06:42:25 -0400 (EDT) Received: (qmail 76529 invoked by uid 0); 8 Jun 2000 10:42:09 -0000 Message-ID: <20000608104209.76528.qmail@hotmail.com> Received: from 195.77.235.2 by www.hotmail.com with HTTP; Thu, 08 Jun 2000 03:42:09 PDT X-Originating-IP: [195.77.235.2] From: "Marc" To: DHCPv4 discussion list Subject: Microsoft Proxy Server 2.0 question Date: Thu, 08 Jun 2000 12:42:09 CEST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Reply-To: marc_jaumandreu@hotmail.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I have a question about Microsoft Proxy Server 2.0. Here it is: Can i configure or define individual destination IP address to specifyc Proxy defined-users? ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-dhcp-v4@bucknell.edu Thu Jun 8 06:58:35 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10870 for ; Thu, 8 Jun 2000 06:58:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e58AvmW17156; Thu, 8 Jun 2000 06:57:48 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e58AvYW17395 for ; Thu, 8 Jun 2000 06:57:34 -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 GAA10746; Thu, 8 Jun 2000 06:57:33 -0400 (EDT) Message-Id: <200006081057.GAA10746@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-userclass-08.txt Date: Thu, 08 Jun 2000 06:57:33 -0400 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --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 User Class Option for DHCP Author(s) : G. Stump, R. Droms, Y. Gu, R. Vyaghrapuri, A. Demirtjis, B. Beser, J. Privat Filename : draft-ietf-dhc-userclass-08.txt Pages : 5 Date : 07-Jun-00 This option is used by a DHCP client to optionally identify the type or category of user or applications it represents. The information contained in this option is an opaque field that represents the user class of which the client is a member. Based on this class, a DHCP server selects the appropriate address pool to assign an address to the client and the appropriate configuration parameters. This option should be configurable by a user. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-userclass-08.txt 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-userclass-08.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-userclass-08.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: <20000607121508.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-userclass-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-userclass-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000607121508.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Thu Jun 8 16:01:10 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15566 for ; Thu, 8 Jun 2000 16:01:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e58JvTW19304; Thu, 8 Jun 2000 15:57:29 -0400 (EDT) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e58JvLW30766 for ; Thu, 8 Jun 2000 15:57:21 -0400 (EDT) Received: from droms-mac (pm3mi1-34.uplink.net [209.173.86.35]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id PAA23577 for ; Thu, 8 Jun 2000 15:57:19 -0400 (EDT) Message-Id: <4.2.2.20000608154947.00a50d50@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 08 Jun 2000 15:50:57 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Update to RFC 2489 (REMINDER!) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN REMINDER - Respond by this Friday, 6/9, if you have any comments about draft-ietf-dhc-new-opt-msg-00.txt =============================================================== I've published "Procedure for Defining New DHCP Options and Message Types" , which is intended to replace RFC 2489. The new I-D gives a procedure for issuing new DHCP message types as well as new option codes. We need to have this procedure in place to assign a new message type code for the RECONFIGURE option as described in . The draft mentions the new options review procedure, which is currently documented in draft-ietf-dhc-option-review-and-namespace-02.txt, and requires that new options and message types be reviewed through any new procedure accepted by the DHC WG. This new document is a simple update to the current procedure for accepting new options. If the document is not controversial, I will fast-track it through the WG and go to last call some time next week. If the WG would like to engage in a longer discussion, the document will go through the normal WG review procedure. Please review the document and reply to the mailing list with comments... - Ralph From owner-dhcp-v4@bucknell.edu Thu Jun 8 16:24:02 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15903 for ; Thu, 8 Jun 2000 16:24:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e58KNCW20848; Thu, 8 Jun 2000 16:23:12 -0400 (EDT) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e58KMxW30636; Thu, 8 Jun 2000 16:22:59 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA25926; Thu, 8 Jun 2000 16:22:42 -0400 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.60.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA26370; Thu, 8 Jun 2000 16:22:43 -0400 Received: from ludwigia.raleigh.ibm.com (localhost [127.0.0.1]) by ludwigia.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id QAA13202; Thu, 8 Jun 2000 16:21:51 -0400 Message-Id: <200006082021.QAA13202@ludwigia.raleigh.ibm.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Update to RFC 2489 (REMINDER!) In-Reply-To: Message from Ralph Droms of "Thu, 08 Jun 2000 15:50:57 EDT." <4.2.2.20000608154947.00a50d50@mail.bucknell.edu> Date: Thu, 08 Jun 2000 16:21:51 -0400 From: Thomas Narten Reply-To: narten@raleigh.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > REMINDER - Respond by this Friday, 6/9, if you have any > comments about draft-ietf-dhc-new-opt-msg-00.txt Comments of the form "I've read it, and it's fine" are appreciated too to avoid confusion with "nobody has read it, so who knows if it's baked". Thomas From owner-dhcp-v4@bucknell.edu Fri Jun 9 07:16:13 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08585 for ; Fri, 9 Jun 2000 07:16:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e59B9JW31800; Fri, 9 Jun 2000 07:09:19 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e59B9EW29836 for ; Fri, 9 Jun 2000 07:09:14 -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 HAA08474; Fri, 9 Jun 2000 07:09:13 -0400 (EDT) Message-Id: <200006091109.HAA08474@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-subnet-option-05.txt Date: Fri, 09 Jun 2000 07:09:12 -0400 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --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 Subnet Selection Option for DHCP Author(s) : G. Waters Filename : draft-ietf-dhc-subnet-option-05.txt Pages : 6 Date : 08-Jun-00 This memo defines a new DHCP option for selecting the subnet on which to allocate an address. This option would override a DHCP server's normal methods of selecting which subnet on which to allocate an address for a client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-subnet-option-05.txt 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-subnet-option-05.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-subnet-option-05.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: <20000608093854.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-subnet-option-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-subnet-option-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000608093854.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Fri Jun 9 07:16:32 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08596 for ; Fri, 9 Jun 2000 07:16:32 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e59BCPW22188; Fri, 9 Jun 2000 07:12:25 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e59B9NW18289 for ; Fri, 9 Jun 2000 07:09:23 -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 HAA08511; Fri, 9 Jun 2000 07:09:22 -0400 (EDT) Message-Id: <200006091109.HAA08511@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list CC: mobile-ip@standards.nortelnetworks.com, dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-glass-mobileip-agent-dhcp-proxy-00.txt Date: Fri, 09 Jun 2000 07:09:21 -0400 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobile IP Agents as DHCP Proxies Author(s) : S. Glass Filename : draft-glass-mobileip-agent-dhcp-proxy-00.txt Pages : 18 Date : 08-Jun-00 Since the inclusion of the Network Access Identifier (NAIs) into the mobile ip fabric, home agents have had a way to identify mobile nodes which do not have home IP addresses. After authenticating the registration request from such a mobile node, the home agent is then expected to assign a home addresses to the mobile node in the registration reply to be used on a semi-permanent basis. Unfortunately, no specific mechanism has yet been proposed. Ideally, as DHCP centralizes address management, a home agent should contact a DHCP server to allocate an address for the mobile node, thereby preserving DHCP as the central address maintainer. The technology does exist for a Home Agent to use DHCP controlled addresses, namely for the Home Agent to behave as a DHCP proxy agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-glass-mobileip-agent-dhcp-proxy-00.txt 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-glass-mobileip-agent-dhcp-proxy-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-glass-mobileip-agent-dhcp-proxy-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000608093912.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-glass-mobileip-agent-dhcp-proxy-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-glass-mobileip-agent-dhcp-proxy-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000608093912.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Fri Jun 9 13:08:49 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15419 for ; Fri, 9 Jun 2000 13:08:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e59GqvW03901; Fri, 9 Jun 2000 12:52:57 -0400 (EDT) Received: from honts307.wal-mart.com (honts307.wal-mart.com [146.132.234.37]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e59GqnW08795; Fri, 9 Jun 2000 12:52:49 -0400 (EDT) Received: from honts388.homeoffice.wal-mart.com (fwnts002.wal-mart.com [146.132.235.8]) by honts307.wal-mart.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MNJG0HQ2; Fri, 9 Jun 2000 11:56:09 -0500 Received: from honts305.homeoffice.wal-mart.com (unverified) by honts388.homeoffice.wal-mart.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Fri, 9 Jun 2000 11:52:32 -0500 Received: by HONTS305.homeoffice.wal-mart.com with Internet Mail Service (5.5.2650.21) id ; Fri, 9 Jun 2000 11:52:32 -0500 Message-ID: From: Nathan Lane To: DHCPv4 discussion list Subject: RE: Update to RFC 2489 (REMINDER!) Date: Fri, 9 Jun 2000 11:40:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Reply-To: ndlane@wal-mart.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I'd really like to see some clarification on the "private use" option namespace. It looks to me like we've ceeded the 128-254 option space to vendors who may not care to read all relevant documentation and hence will choose to use "private use" options over the vendor encapsulated space (also in need of a little clarification) due to lack of understanding, code expediency or a variety of other possible reasons. It's okay with me if we do abandon control of 128-254, but I see it is an issue for the future and I've certainly run into it before. Take the case when a device A doesn't support vendor encaps, client identifiers or anything else and needs option 129, but it's a different 129 from device B...I have very few classing mechanisms available from the devices in this case, leaving me to use MAC prefices which are subject to the whim of the manufacturer in many cases. This case, could we define "private use" as "not to be implemented in a product sold to the general public"? Or a requirement that private use options be changable by the end user? I do like the review procedures and expansion in for options, message types, etc. that are in the public space. -Nathan Lane Wal-Mart Stores, Inc. (501) 277-5786 > -----Original Message----- > From: Ralph Droms [SMTP:droms@bucknell.edu] > Sent: Thursday, June 08, 2000 2:51 PM > To: DHCPv4 discussion list > Subject: Update to RFC 2489 (REMINDER!) > > REMINDER - Respond by this Friday, 6/9, if you have any > comments about draft-ietf-dhc-new-opt-msg-00.txt > > =============================================================== > > I've published "Procedure for Defining New DHCP > Options and Message Types" , > which is intended to replace RFC 2489. The new I-D > gives a procedure for issuing new DHCP message types as well as > new option codes. We need to have this procedure in place > to assign a new message type code for the RECONFIGURE option > as described in . > > The draft mentions the new options review procedure, > which is currently documented in > draft-ietf-dhc-option-review-and-namespace-02.txt, > and requires that new options and message types be reviewed > through any new procedure accepted by the DHC WG. > > This new document is a simple update to the current > procedure for accepting new options. If the document > is not controversial, I will fast-track it through the > WG and go to last call some time next week. If the WG > would like to engage in a longer discussion, the > document will go through the normal WG review procedure. > > Please review the document and reply to the mailing > list with comments... > > - Ralph > > ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please notify the Wal-Mart E-mail administrator at " postmaster@wal-mart.com ". ********************************************************************** From owner-dhcp-v4@bucknell.edu Fri Jun 9 15:41:24 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18019 for ; Fri, 9 Jun 2000 15:41:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e59JbrW32515; Fri, 9 Jun 2000 15:37:53 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e59JbiW30291 for ; Fri, 9 Jun 2000 15:37:44 -0400 (EDT) Received: from droms-mac (sj-dial-3-59.cisco.com [171.68.180.60]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA09641; Fri, 9 Jun 2000 15:37:19 -0400 (EDT) Message-Id: <4.2.2.20000609153112.00a5be60@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 09 Jun 2000 15:36:22 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: RE: Update to RFC 2489 (REMINDER!) Cc: dhcp-v4@bucknell.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 11:40 AM 6/9/00 -0500, you wrote: >I'd really like to see some clarification on the "private use" option >namespace. > >[...] could we define "private use" as "not to be implemented in a >product sold to the general public"? Or a requirement that private use >options be changable by the end user? I don't think we want to give up the "private use" portion of the namespace; as you point out, to do so will result in chaos and conflicts in the use of option codes. I will put stronger language into the revision for RFC2489. - Ralph From owner-dhcp-v4@bucknell.edu Fri Jun 9 17:14:01 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18901 for ; Fri, 9 Jun 2000 17:14:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e59LAxW11677; Fri, 9 Jun 2000 17:10:59 -0400 (EDT) Received: from mail.ultradns.com (IDENT:qmailr@[64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e59LArW10336 for ; Fri, 9 Jun 2000 17:10:53 -0400 (EDT) Received: (qmail 23319 invoked from network); 9 Jun 2000 21:13:41 -0000 Received: from ip-216-73-154-39.vantas.net (HELO ULTRADNS6PMNFK) (216.73.154.39) by mail.ultradns.com with SMTP; 9 Jun 2000 21:13:41 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: Update to RFC 2489 (REMINDER!) Date: Fri, 9 Jun 2000 14:13:36 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <4.2.2.20000609153112.00a5be60@mail.bucknell.edu> Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-dhcp-v4@bucknell.edu [mailto:owner-dhcp-v4@bucknell.edu] > Sent: Friday, June 09, 2000 12:36 PM > >I'd really like to see some clarification on the "private use" option > >namespace. > > > >[...] could we define "private use" as "not to be implemented in a > >product sold to the general public"? Or a requirement that private use > >options be changable by the end user? > > I don't think we want to give up the "private use" portion of the > namespace; as you point out, to do so will result in chaos and > conflicts in the use of option codes. I will put stronger language > into the revision for RFC2489. > ...I concur.... --Barr From owner-dhcp-v4@bucknell.edu Fri Jun 9 17:32:34 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19112 for ; Fri, 9 Jun 2000 17:32:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e59LV0W24640; Fri, 9 Jun 2000 17:31:00 -0400 (EDT) Received: from mail.ultradns.com (IDENT:qmailr@[64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e59LUuW12840 for ; Fri, 9 Jun 2000 17:30:56 -0400 (EDT) Received: (qmail 23617 invoked from network); 9 Jun 2000 21:33:45 -0000 Received: from ip-216-73-154-39.vantas.net (HELO ULTRADNS6PMNFK) (216.73.154.39) by mail.ultradns.com with SMTP; 9 Jun 2000 21:33:45 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: Update to RFC 2489 (REMINDER!) Date: Fri, 9 Jun 2000 14:33:39 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <4.2.2.20000608154947.00a50d50@mail.bucknell.edu> Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit typos and nits: =============== 1. "publicly" is misspelled as "publically" in the second paragraph of section 2.1 2. "...will be document..." in the second sentence of the first paragraph of section 2.2 probably should read "...will be documented...." 3. "...new option or message typemay reference..." in the third sentence of the second paragraph of section 5 needs a space: "...new option or message type may reference...." changes: ======== Is it appropriate to institute a "sunset" rule for option codes? I propose all [new] options have an associated lifetime, somewhere between two and five years, when they are first accepted: before the end of that lifetime the DHC WG chair would issue a "call for renewal" on the option. If the DHC WG vote shows little or no interest in keeping the option, it would be deprecated in the next version of the DHCP RFC, and eventually dropped entirely, so the option code could be reused. This process could take multiple years, protecting any existing implementations which use the option, but would provide a well-defined way to recover unused or under-utilized option codes. Otherwise, I concur with the text of the I-D (and the proposed change regarding public and private option codes.) --Barr From owner-dhcp-v4@bucknell.edu Fri Jun 9 17:52:30 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19256 for ; Fri, 9 Jun 2000 17:52:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e59LnmW17768; Fri, 9 Jun 2000 17:49:48 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e59LnTW15319 for ; Fri, 9 Jun 2000 17:49:30 -0400 (EDT) Received: from droms-mac (atlantis-dial-1-27.cisco.com [171.68.181.28]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA23997; Fri, 9 Jun 2000 17:48:44 -0400 (EDT) Message-Id: <4.2.2.20000609174526.00a5b1c0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 09 Jun 2000 17:47:36 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: RE: Update to RFC 2489 (REMINDER!) In-Reply-To: References: <4.2.2.20000608154947.00a50d50@mail.bucknell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 02:33 PM 6/9/00 -0700, Barr Hibbs wrote: >changes: >======== > >Is it appropriate to institute a "sunset" rule for option codes? Interesting idea - what are you trying to accomplish? I don't think it's likely that we can reuse the option codes (well, maybe the 'Impress server option') once they've leaked out into installed clients. There will likely *always* be some client out there that continues to use an option past its sunset date. - Ralph From owner-dhcp-v4@bucknell.edu Fri Jun 9 17:53:28 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19257 for ; Fri, 9 Jun 2000 17:52:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e59LnYW07154; Fri, 9 Jun 2000 17:49:34 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e59LnMW16114 for ; Fri, 9 Jun 2000 17:49:22 -0400 (EDT) Received: from droms-mac (atlantis-dial-1-27.cisco.com [171.68.181.28]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA23991; Fri, 9 Jun 2000 17:48:42 -0400 (EDT) Message-Id: <4.2.2.20000609174445.00a59900@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 09 Jun 2000 17:45:10 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: RE: Update to RFC 2489 (REMINDER!) In-Reply-To: References: <4.2.2.20000608154947.00a50d50@mail.bucknell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 02:33 PM 6/9/00 -0700, Barr Hibbs wrote: >typos and nits: >=============== > >1. "publicly" is misspelled as "publically" in the second paragraph of >section 2.1 > >2. "...will be document..." in the second sentence of the first >paragraph of >section 2.2 probably should read "...will be documented...." > >3. "...new option or message typemay reference..." in the third >sentence of >the second paragraph of section 5 needs a space: "...new option or message >type may reference...." > Good catches and thanks... - Ralph From owner-dhcp-v4@bucknell.edu Fri Jun 9 18:01:51 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19401 for ; Fri, 9 Jun 2000 18:01:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e59M16W15534; Fri, 9 Jun 2000 18:01:06 -0400 (EDT) Received: from mail.ultradns.com (IDENT:qmailr@[64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e59M11W30362 for ; Fri, 9 Jun 2000 18:01:01 -0400 (EDT) Received: (qmail 23947 invoked from network); 9 Jun 2000 22:03:50 -0000 Received: from ip-216-73-154-39.vantas.net (HELO ULTRADNS6PMNFK) (216.73.154.39) by mail.ultradns.com with SMTP; 9 Jun 2000 22:03:50 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: Update to RFC 2489 (REMINDER!) Date: Fri, 9 Jun 2000 15:03:44 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <4.2.2.20000609174526.00a5b1c0@mail.bucknell.edu> Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > > At 02:33 PM 6/9/00 -0700, Barr Hibbs wrote: > > > > >Is it appropriate to institute a "sunset" rule for option codes? > > Interesting idea - what are you trying to accomplish? > > I don't think it's likely that we can reuse the option codes (well, > maybe the 'Impress server option') once they've leaked out into > installed clients. There will likely *always* be some client out > there that continues to use an option past its sunset date. > > ...at one time, we were concerned enough about the possible exhaustion of DHCPv4 option codes that we convened the futures panel, one of whose recommendations was a means for declaring 16-bit option codes. Since then, there doesn't seem to be as much urgency for preserving the remaining free option codes, but I suspect it will become a concern sooner or later. Rather than wait until we are faced with imminent exhaustion, I'm suggesting how we might plan for the eventual deprecation of unused or under-used option codes. For example, are there *really* any clients and servers that make use of Default IRC Server or Default WWW Server? --Barr From owner-dhcp-v4@bucknell.edu Fri Jun 9 18:01:58 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19414 for ; Fri, 9 Jun 2000 18:01:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e59M1HW15832; Fri, 9 Jun 2000 18:01:17 -0400 (EDT) Received: from honts307.wal-mart.com (honts307.wal-mart.com [146.132.234.37]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e59M1FW24986 for ; Fri, 9 Jun 2000 18:01:15 -0400 (EDT) Received: from honts385.homeoffice.wal-mart.com (fwnts002.wal-mart.com [146.132.235.8]) by honts307.wal-mart.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MNJG0TC7; Fri, 9 Jun 2000 17:04:36 -0500 Received: from honts305.homeoffice.wal-mart.com (unverified) by honts385.homeoffice.wal-mart.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Fri, 9 Jun 2000 16:55:08 -0500 Received: by HONTS305.homeoffice.wal-mart.com with Internet Mail Service (5.5.2650.21) id ; Fri, 9 Jun 2000 17:00:59 -0500 Message-ID: From: Nathan Lane To: DHCPv4 discussion list Subject: "Sunsetting" options Date: Fri, 9 Jun 2000 17:00:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Reply-To: ndlane@wal-mart.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > At 02:33 PM 6/9/00 -0700, Barr Hibbs wrote: > > >changes: > >======== > > > >Is it appropriate to institute a "sunset" rule for option codes? > > Interesting idea - what are you trying to accomplish? > > I don't think it's likely that we can reuse the option codes (well, > maybe the 'Impress server option') once they've leaked out into > installed clients. There will likely *always* be some client out > there that continues to use an option past its sunset date. > > - Ralph [Nathan Lane] Barr and I discussed this awhile back and I had the same objection that there will always be some client, somewhere. I understand the "end of life" statement of the manufacturers of the equipment, but some contracts state EOL can never happen until certain conditions are met such as decomissioning all devices in a large enterprise...which would go long past the "public EOL" on a product and make integration more difficult. Let me say, though, I like the idea technically. btw - whatever happened to the removal of options that had no RFC to back them up? Anybody ever coordinate that one? -Nathan Lane ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please notify the Wal-Mart E-mail administrator at " postmaster@wal-mart.com ". ********************************************************************** From owner-dhcp-v4@bucknell.edu Fri Jun 9 19:15:11 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19796 for ; Fri, 9 Jun 2000 19:15:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e59NAVW17758; Fri, 9 Jun 2000 19:10:31 -0400 (EDT) Received: from postal.metaip.checkpoint.com (metaip.checkpoint.com [204.29.28.25]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e59NA2W28505 for ; Fri, 9 Jun 2000 19:10:21 -0400 (EDT) Received: from cartman.metainfo.com (cartman.metainfo.com [204.29.28.145]) by postal.metaip.checkpoint.com (8.9.3/8.9.3VRJ666) with ESMTP id QAA30552; Sat, 10 Jun 2000 16:10:40 -0700 Received: from metaip.checkpoint.com (sneakers.metainfo.com [204.29.28.213]) by cartman.metainfo.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MLNKN3V2; Fri, 9 Jun 2000 16:04:39 -0700 Sender: owner-dhcp-v4@bucknell.edu Message-ID: <39417964.BC183DC6@metaip.checkpoint.com> Date: Fri, 09 Jun 2000 16:10:28 -0700 From: Richard Jones Organization: Checkpoint Software Technologies X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list CC: DHCPv4 discussion list Subject: Re: Update to RFC 2489 (REMINDER!) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: richardj@metaip.checkpoint.com X-Sender: richardj@postal.metaip.checkpoint.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit I think the idea has some attraction, but I don't believe it can be done without breaking something somewhere. How could the working group get a realistic idea of who is using what? That's a question I've wondered for some time. There's a certain amount of information that could be gleaned from vendors, lists etc., but in general it seems like a standards group can put them out, but can't take them back without a wholesale replacement - for the very reason that it's impossible to know what gets broken otherwise. My vote is that we leave the sunset definition out at this point. A couple more typos: Section 2.2, third paragraph - change accepatance to acceptance. Section 3, point 4 - change "typeis" to "type is". Thanks, Ralph! Regards, Richard Barr Hibbs wrote: > > > > At 02:33 PM 6/9/00 -0700, Barr Hibbs wrote: > > > > > > > >Is it appropriate to institute a "sunset" rule for option codes? > > > > Interesting idea - what are you trying to accomplish? > > > > I don't think it's likely that we can reuse the option codes (well, > > maybe the 'Impress server option') once they've leaked out into > > installed clients. There will likely *always* be some client out > > there that continues to use an option past its sunset date. > > > > > ...at one time, we were concerned enough about the possible exhaustion of > DHCPv4 option codes that we convened the futures panel, one of whose > recommendations was a means for declaring 16-bit option codes. Since then, > there doesn't seem to be as much urgency for preserving the remaining free > option codes, but I suspect it will become a concern sooner or later. > Rather than wait until we are faced with imminent exhaustion, I'm suggesting > how we might plan for the eventual deprecation of unused or under-used > option codes. For example, are there *really* any clients and servers that > make use of Default IRC Server or Default WWW Server? > > --Barr From owner-dhcp-v4@bucknell.edu Fri Jun 9 19:31:40 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20072 for ; Fri, 9 Jun 2000 19:31:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e59NTlW22163; Fri, 9 Jun 2000 19:29:47 -0400 (EDT) Received: from Arachnid.NTRG.com ([209.31.7.46]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e59NTaW14699 for ; Fri, 9 Jun 2000 19:29:36 -0400 (EDT) Received: from Buffalo (buffalo.ehsco.com [209.31.7.44]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with SMTP id 697; Fri, 9 Jun 2000 16:29:34 -0700 Message-ID: <002001bfd26a$92d71a00$2c071fd1@NTRG.com> From: "Eric A. Hall" To: DHCPv4 discussion list References: Subject: Re: Update to RFC 2489 (REMINDER!) Date: Fri, 9 Jun 2000 16:29:35 -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 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Reply-To: ehall@ehsco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > For example, are there *really* any clients and servers that > make use of Default IRC Server or Default WWW Server? By default no, but by configuration yes. Folks use non-stock options with scriptable clients all the time, and more folks are doing it as more clients become scriptable. From owner-dhcp-v4@bucknell.edu Mon Jun 12 06:46:38 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27848 for ; Mon, 12 Jun 2000 06:46:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5CAgsW02975; Mon, 12 Jun 2000 06:42:55 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5CAgfW10498 for ; Mon, 12 Jun 2000 06:42:42 -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 GAA27580; Mon, 12 Jun 2000 06:42:41 -0400 (EDT) Message-Id: <200006121042.GAA27580@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-nsso-04.txt Date: Mon, 12 Jun 2000 06:42:40 -0400 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --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 Name Service Search Option for DHCP Author(s) : C. Smith Filename : draft-ietf-dhc-nsso-04.txt Pages : 4 Date : 09-Jun-00 This document defines a new DHCP option which is passed from the DHCP Server to the DHCP Client to specify the order in which name services should be consulted when resolving hostnames and other information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-nsso-04.txt 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-nsso-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-nsso-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: <20000609131232.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-nsso-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-nsso-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000609131232.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Mon Jun 12 11:36:49 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04567 for ; Mon, 12 Jun 2000 11:36:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5CFX4W15738; Mon, 12 Jun 2000 11:33:04 -0400 (EDT) Received: from mail.ultradns.com (IDENT:qmailr@[64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5CFX0W26987 for ; Mon, 12 Jun 2000 11:33:00 -0400 (EDT) Received: (qmail 29622 invoked from network); 12 Jun 2000 15:36:20 -0000 Received: from ip-216-73-154-39.vantas.net (HELO ULTRADNS6PMNFK) (216.73.154.39) by mail.ultradns.com with SMTP; 12 Jun 2000 15:36:20 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: Update to RFC 2489 (REMINDER!) Date: Mon, 12 Jun 2000 08:36:08 -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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <002001bfd26a$92d71a00$2c071fd1@NTRG.com> Importance: Normal Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-dhcp-v4@bucknell.edu [mailto:owner-dhcp-v4@bucknell.edu]On > Behalf Of Eric A. Hall > Sent: Friday, June 09, 2000 4:30 PM > > > For example, are there *really* any clients and servers that > > make use of Default IRC Server or Default WWW Server? > > By default no, but by configuration yes. Folks use non-stock options with > scriptable clients all the time, and more folks are doing it as > more clients become scriptable. > > ...I think you missed my point: "are any clients and servers using the DHCP options for configuring default IRC or WWW servers?" For example, the popular mIRC client uses a local configuration file to determine which server(s) it will attempt to connect to, and neither Internet Explorer nor Netscape seem to request a WWW server [using DHCPINFORM]. --Barr From owner-dhcp-v4@bucknell.edu Mon Jun 12 11:43:52 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04706 for ; Mon, 12 Jun 2000 11:43:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5CFh6W22346; Mon, 12 Jun 2000 11:43:06 -0400 (EDT) Received: from mail.ultradns.com (IDENT:qmailr@[64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5CFh1W08479 for ; Mon, 12 Jun 2000 11:43:01 -0400 (EDT) Received: (qmail 29640 invoked from network); 12 Jun 2000 15:46:22 -0000 Received: from ip-216-73-154-39.vantas.net (HELO ULTRADNS6PMNFK) (216.73.154.39) by mail.ultradns.com with SMTP; 12 Jun 2000 15:46:22 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: "Sunsetting" options Date: Mon, 12 Jun 2000 08:46:10 -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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Importance: Normal Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-dhcp-v4@bucknell.edu [mailto:owner-dhcp-v4@bucknell.edu]On > Behalf Of Nathan Lane > Sent: Friday, June 09, 2000 3:01 PM > btw - whatever happened to the removal of options that had no RFC to > back them up? Anybody ever coordinate that one? > > Good memory, Nathan! I have this nagging feeling that several of the DHCP option codes may have been assigned by IANA as placeholders on direct request from individuals or organizations. While some, like Intel, made a good-faith effort to inform the DHC WG of what they were doing with the "PXE options" others appear to have been added without discussion. Ralph: can we reopen the matter with IANA, identifying the requestor(s) for option code assisgnments that did NOT originate either with the DHC WG or a current RFC? Nathan: I mentioned the Intel "PXE options" as an example of an organization trying to coordinate with the DHC WG. My best understanding of this particular set of options is that Intel proposed, and IANA accepted a sunset date on their use. Maybe Mike Henry or Thomas Narten will correct any misunderstanding I have about these options, but if my memory is correct, there is a precedent for planned obsolescence of option codes. --Barr From owner-dhcp-v4@bucknell.edu Mon Jun 12 11:53:54 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04997 for ; Mon, 12 Jun 2000 11:53:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5CFr9W06361; Mon, 12 Jun 2000 11:53:09 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5CFr2W11658 for ; Mon, 12 Jun 2000 11:53:02 -0400 (EDT) Received: from droms-mac (atlantis-dial-1-103.cisco.com [171.68.181.104]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA17533; Mon, 12 Jun 2000 11:52:26 -0400 (EDT) Message-Id: <4.2.2.20000612114733.00a47820@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 12 Jun 2000 11:51:31 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: RE: "Sunsetting" options In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 08:46 AM 6/12/00 -0700, Barr Hibbs wrote: > > -----Original Message----- > > From: owner-dhcp-v4@bucknell.edu [mailto:owner-dhcp-v4@bucknell.edu]On > > Behalf Of Nathan Lane > > Sent: Friday, June 09, 2000 3:01 PM > > > > btw - whatever happened to the removal of options that had no RFC to > > back them up? Anybody ever coordinate that one? > > > > > >Ralph: can we reopen the matter with IANA, identifying the requestor(s) for >option code assisgnments that did NOT originate either with the DHC WG or a >current RFC? Yes. I have a list of option codes that were assigned prior to the publication of RFC 2489 and contact persons, some of whom I've already been in touch with. I will reopen this process and develop a list of option codes that IANA can return to the pool of available option codes. - Ralph From owner-dhcp-v4@bucknell.edu Mon Jun 12 12:31:22 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06113 for ; Mon, 12 Jun 2000 12:31:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5CGSXW17265; Mon, 12 Jun 2000 12:28:33 -0400 (EDT) Received: from Arachnid.NTRG.com ([209.31.7.46]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5CGSMW12475 for ; Mon, 12 Jun 2000 12:28:23 -0400 (EDT) Received: from ehsco.com (nat-external.ehsco.com [209.31.7.42]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 475; Mon, 12 Jun 2000 09:28:20 -0700 Message-ID: <39450FA3.A1EA97D9@ehsco.com> Date: Mon, 12 Jun 2000 09:28:19 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list CC: DHCPv4 discussion list Subject: Re: Update to RFC 2489 (REMINDER!) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: ehall@ehsco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > For example, the popular mIRC client uses a local configuration file > to determine which server(s) it will attempt to connect to, and > neither Internet Explorer nor Netscape seem to request a WWW server > [using DHCPINFORM]. I understood, it's the same question and answer. Nobody is doing it "by default" as you describe it. However, there are people who are doing this by script-pushing lease data into external configuration files and the like. More people are doing it as more DHCP clients offer interfaces that can be scripted. OS/2 Warp led the way on this with a REXX interface to their client; it was fully scriptable. All of the UNIX systems that I have here provide some sort of interface that lets the client be configured with this kind of data (default NTP servers is a common example, default mail server is also easy to do). With NT & Win2k it is possible but not easy: you can extend the client and read the resulting option data from the registry, stuffing it into other registry entries or into external configuration files, but it isn't pretty. Windows 9x and the MacOS don't provide any end-user access to this data to my knowledge, so this can't be done with end-user tools on those platforms (although NTS' ShadowIP client solves the problem for Win9x), but the rest of them essentially allow a user or administrator to read lease data which can then be stuffed into some other configuration point. The biggest problem nowadays is not that clients cannot be extended but that it is a royal PITA to configure each of the applications. Some apps store data into user-specific configuration files that are kept in remote profiles that aren't available to the client, or which use LDAP, SLP and/or ACAP for the same thing. If you have Eudora and Navigator and are only using local configuration files for a single user, it's not hard to extend those apps on an NT system, but if you are using IE/OE or Communicator with user-specific configuration data stored on a remote server it is very hard to do. I use Communicator with the LDAP-based roaming profile here, there's no way I can do this easily. It's a sad joke: people are now able to actually get to the option data so they can use it, but they are now having a harder time of actually being able to use it as application data gets dispersed. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-dhcp-v4@bucknell.edu Mon Jun 12 13:45:12 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07684 for ; Mon, 12 Jun 2000 13:45:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5CHgDW25740; Mon, 12 Jun 2000 13:42:13 -0400 (EDT) Received: from superpuertos.homeip.net ([206.49.161.55]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5CHg3W27041 for ; Mon, 12 Jun 2000 13:42:04 -0400 (EDT) Received: from [172.16.2.1] (account ) by superpuertos.homeip.net (CommuniGate Pro WebUser 3.2.4) with HTTP id 93069 for ; Mon, 12 Jun 2000 12:41:40 -0500 From: Subject: hos define many routes To: DHCPv4 discussion list X-Mailer: CommuniGate Pro Web Mailer v.3.2.4 Date: Mon, 12 Jun 2000 12:41:40 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Reply-To: muskus@superpuertos.homeip.net Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 8bit Hi List ! Im Marco Muskus, new here, after all excuse me for my poor english ... ;) I have a 486Dx With 8MB RAM as my DHCP server for 50 clients (u can see at superpuertos.homeip.net), and i got many routes .. how i can set with DHCPD that parameter ? Thanks ! --- Marco Muskus muskus@superpuertos.homeip.net http://muskus.homepage.com/ "something pathetic here" From owner-dhcp-v4@bucknell.edu Mon Jun 12 13:46:09 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07720 for ; Mon, 12 Jun 2000 13:46:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5CHhSW22166; Mon, 12 Jun 2000 13:43:28 -0400 (EDT) Received: from mail.ultradns.com (IDENT:qmailr@[64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5CHhOW14982 for ; Mon, 12 Jun 2000 13:43:24 -0400 (EDT) Received: (qmail 31457 invoked from network); 12 Jun 2000 17:46:40 -0000 Received: from ip-216-73-154-39.vantas.net (HELO ULTRADNS6PMNFK) (216.73.154.39) by mail.ultradns.com with SMTP; 12 Jun 2000 17:46:40 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: "Sunsetting" options Date: Mon, 12 Jun 2000 10:46:27 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <4.2.2.20000612114733.00a47820@mail.bucknell.edu> Importance: Normal Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-dhcp-v4@bucknell.edu [mailto:owner-dhcp-v4@bucknell.edu]On > Behalf Of Ralph Droms > Sent: Monday, June 12, 2000 8:52 AM > > > >Ralph: can we reopen the matter with IANA, identifying the > requestor(s) for > >option code assisgnments that did NOT originate either with the > DHC WG or a > >current RFC? > > Yes. I have a list of option codes that were assigned prior to the > publication of RFC 2489 and contact persons, some of whom > I've already been in touch with. I will reopen this process and > develop a list of option codes that IANA can return to the pool > of available option codes. > > ...great!!! Thanks, Ralph! --Barr From owner-dhcp-v4@bucknell.edu Mon Jun 12 16:30:57 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10649 for ; Mon, 12 Jun 2000 16:30:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5CKRMW18656; Mon, 12 Jun 2000 16:27:22 -0400 (EDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5CKRHW19345; Mon, 12 Jun 2000 16:27:18 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id NAA04574; Mon, 12 Jun 2000 13:27:15 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 12 Jun 2000 13:27:15 -0700 Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id NAA02684; Mon, 12 Jun 2000 13:27:14 -0700 (PDT) Message-Id: <200006122027.NAA02684@scv1.apple.com> Subject: Re: DHCPNAK in response to DHCPRENEW Date: Mon, 12 Jun 2000 13:27:48 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: DHCPv4 discussion list Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Reply-To: cheshire@apple.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >Stuart - RFC2131 is not clear on the required behavior >of a DHCP client when it receives a DHCPNAK in response >to a DHCPRENEW or DHCPREBIND message. In practice, how >do the various MacOS clients react in this situation? > >Thanks for the information about the AirPort. Seems like >just the right thing for my home network... > >- Ralph In REQUESTING, RENEWING, REBINDING or INITREBOOT, a NAK puts the client back into INIT state and it sends a DISCOVER to get a new address. In INIT state, if the client gets no OFFERs, but it *does* get a NAK, and the NAK contains an ASCII text message option (option 56), then the message is displayed to the user. This is a slight extension to the spec, in that RFC 2131 does not specify a behaviour for a NAK received in response to a DISCOVER, but if you do decide to send one to a Mac, and you put a message in it, then the Mac will display it. This can be useful, for example, when you are aware of a problem and are already working on it, to avoid a flood of calls to the support desk, by configuring a message that says, "We are out of addresses on this subnet. We are aware of the problem and will have it fixed by 10:00am." If you want to test this, you'll need the latest Open Transport release, which is OT 2.6.2. I think it should be available for download on the web -- if not ask me and I can send you a copy. Stuart Cheshire * Wizard Without Portfolio, Apple Computer From owner-dhcp-v4@bucknell.edu Tue Jun 13 07:06:47 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02748 for ; Tue, 13 Jun 2000 07:06:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5DB33W26339; Tue, 13 Jun 2000 07:03:04 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5DB31W21511 for ; Tue, 13 Jun 2000 07:03:01 -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 HAA02296; Tue, 13 Jun 2000 07:03:00 -0400 (EDT) Message-Id: <200006131103.HAA02296@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-new-opt-msg-01.txt Date: Tue, 13 Jun 2000 07:02:59 -0400 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --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 : Procedure for Defining New DHCP Options and Message Types Author(s) : R. Droms Filename : draft-ietf-dhc-new-opt-msg-01.txt Pages : 7 Date : 12-Jun-00 The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in tagged data items that are stored in the 'options' field of the DHCP message. The data items themselves are also called 'options.' DHCP protocol messages are identified by the 'DHCP Message Type' option (option code 51). Each message type is defined by the data value carried in the 'DHCP Message Type' option. New DHCP options and message types may be defined after the publication of the DHCP specification to accommodate requirements for conveyance of new configuration parameters or to accommodate new protocol semantics. This document describes the procedure for defining new DHCP options and message types. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-new-opt-msg-01.txt 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-new-opt-msg-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-new-opt-msg-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: <20000612120944.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-new-opt-msg-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-new-opt-msg-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000612120944.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Tue Jun 13 07:07:09 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02766 for ; Tue, 13 Jun 2000 07:07:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5DB6DW24994; Tue, 13 Jun 2000 07:06:13 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5DB4pW23636 for ; Tue, 13 Jun 2000 07:04:51 -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 HAA02628; Tue, 13 Jun 2000 07:04:50 -0400 (EDT) Message-Id: <200006131104.HAA02628@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-authentication-13.txt Date: Tue, 13 Jun 2000 07:04:50 -0400 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --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 : Authentication for DHCP Messages Author(s) : R. Droms, W. Arbaugh Filename : draft-ietf-dhc-authentication-13.txt Pages : 16 Date : 12-Jun-00 The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. In some situations, network administrators may wish to constrain the allocation of addresses to authorized hosts. Additionally, some network administrators may wish to provide for authentication of the source and contents of DHCP messages. This document defines a new DHCP option through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-authentication-13.txt 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-authentication-13.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-authentication-13.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: <20000612143357.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-authentication-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-authentication-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000612143357.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Tue Jun 13 07:19:20 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03042 for ; Tue, 13 Jun 2000 07:19:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5DBHeW27310; Tue, 13 Jun 2000 07:17:40 -0400 (EDT) Received: from hygro.adsl.duke.edu (IDENT:root@hygro.adsl.duke.edu [152.16.64.159]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5DBHYW02490 for ; Tue, 13 Jun 2000 07:17:34 -0400 (EDT) Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1]) by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id HAA03188; Tue, 13 Jun 2000 07:17:44 -0400 Message-Id: <200006131117.HAA03188@hygro.adsl.duke.edu> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: "Sunsetting" options In-Reply-To: Message from "Barr Hibbs" of "Mon, 12 Jun 2000 08:46:10 PDT." Date: Tue, 13 Jun 2000 07:17:44 -0400 From: Thomas Narten Reply-To: narten@raleigh.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > > btw - whatever happened to the removal of options that had no RFC to > > back them up? Anybody ever coordinate that one? The best you can do is ask the owner of the allocated option code if they would give it back. If they don't agree, or don't respond, there is no way of knowing whether the code point is actually being used. If you don't know for sure it is not being used (i.e., you don't know for sure that it is NOT deployed somewhere in some implementation), do you *really* want *your* new option to reuse that value? Thomas From owner-dhcp-v4@bucknell.edu Wed Jun 14 03:14:27 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13583 for ; Wed, 14 Jun 2000 03:14:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5E7B8W29947; Wed, 14 Jun 2000 03:11:08 -0400 (EDT) Received: from hotmail.com (law2-f180.hotmail.com [216.32.181.180]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5E7B2W09521 for ; Wed, 14 Jun 2000 03:11:02 -0400 (EDT) Received: (qmail 13970 invoked by uid 0); 14 Jun 2000 07:10:46 -0000 Message-ID: <20000614071046.13969.qmail@hotmail.com> Received: from 195.77.235.2 by www.hotmail.com with HTTP; Wed, 14 Jun 2000 00:10:46 PDT X-Originating-IP: [195.77.235.2] From: "Marc" To: DHCPv4 discussion list Subject: Re: [mcse] DHCP Scope Date: Wed, 14 Jun 2000 09:10:46 CEST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Reply-To: marc_jaumandreu@hotmail.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I think you need decrease the subnet mask to allow more node IP's. I had the same problem, but i added a 2nd NIC and defined two scopes, one per NIC, but i'm in doubt: can i define the same gateway for both scopes (or NIC's)? or each scope (NIC) needs a gateway corresponding to appropiate network address?. If i need different gateways, how can i do everyone see each other? I can't add another scope using only one NIC due the complexity of the network, routers, tables, etc. That's the cause to use two NIC's. But it doesn't goes right!! Thanks. ----Original Message Follows---- From: "Walid El-Khawas" Reply-To: mcse@mail.saluki.com To: Subject: [mcse] DHCP Scope Date: Tue, 13 Jun 2000 14:14:22 -0400 Hi All, I ran out of IP's on my network, is it possible to add another scope on my networkon the same DHCP Server? the old scope is 192.168.10.x, and i wonna add another one, Lets say 192.168.11.x with the same subnet mask which is 255.255.255.0 , with the same options of the first scope. Would that work ?? Thanks ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-dhcp-v4@bucknell.edu Wed Jun 14 08:21:40 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17451 for ; Wed, 14 Jun 2000 08:21:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5ECJYW27607; Wed, 14 Jun 2000 08:19:35 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5ECJJW05163 for ; Wed, 14 Jun 2000 08:19:19 -0400 (EDT) Received: from droms-mac (ch2-dhcp133-175.cisco.com [161.44.133.175]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA21355 for ; Wed, 14 Jun 2000 08:19:01 -0400 (EDT) Message-Id: <4.2.2.20000613231312.00a39100@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 13 Jun 2000 23:19:14 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: WG last call for "Authentication for DHCP Messages" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message announces a DHC WG last call for "Authentication for DHCP Messages", . The WG discussed the previous revision in Adelaide and agreed to go to WG last call after some editorial changes, which have been incorporated into this latest revision of the spec: * edited "Discussion" in section 1 to eliminate references to expired Internet Drafts * exchanged RDM and Algorithm fields * fixed RDM values - 0x00 is counter method (as defined in draft); all other values are "reserved" * edited first sentence of 5.1 to clarify that protocol 1 is aimed at intradomain authentication and other protocols may address interdomain authentication * changed the two header diagrams in 5.2 to show "Algorithm" field (allowing for multiple algorithms) rather than specifying "00000000" (which didn't match with the specification that HMAC-MD5 use "0x01"). * Edited first sentence of 5.3 to refer more generally to the specified RDM, rather than explicitly desribing the use of RDM 1. * Also edited 5.3 to allow for different algorithms. * Edited section 6 to describe definition of new protocol. algorithm or RDM. Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, June 23. - Ralph Droms From owner-dhcp-v4@bucknell.edu Thu Jun 15 05:21:37 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25440 for ; Thu, 15 Jun 2000 05:21:37 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5F9HpW08599; Thu, 15 Jun 2000 05:17:51 -0400 (EDT) Received: from hotmail.com (law2-f126.hotmail.com [216.32.181.126]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5F9HlW08835 for ; Thu, 15 Jun 2000 05:17:47 -0400 (EDT) Received: (qmail 35422 invoked by uid 0); 15 Jun 2000 09:17:31 -0000 Message-ID: <20000615091731.35421.qmail@hotmail.com> Received: from 195.77.235.2 by www.hotmail.com with HTTP; Thu, 15 Jun 2000 02:17:31 PDT X-Originating-IP: [195.77.235.2] From: "Marc" To: DHCPv4 discussion list Subject: DHCP Server with 2 NIC's Date: Thu, 15 Jun 2000 11:17:31 CEST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Reply-To: marc_jaumandreu@hotmail.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi All, I ran out of IP's on my network, is it possible to add another NIC on my network on the same DHCP Server? the old scope is 190.160.10.x, the gateway is 190.160.10.2 and i wonna add another one scope to the new second NIC. Lets say 190.160.11.x with the same subnet mask which is 255.255.255.0, but which gateway??? And... how can i allow communication between the 2 NIC's? cenario: DHCP Server: NIC 1: IP:190.160.10.1 MASK:255.255.255.0 GATEWAY:190.160.10.2 (today) WINS and DNS:130.10.90.10 (remote) NIC 2: IP:190.160.11.1 MASK:255.255.255.0 GATEWAY:190.160.??.? (future) WINS and DNS:130.10.90.10 (remote) The gateway IP address of the 2nd NIC is my problem. Any help? I know i can do this with only one NIC and modifybg the subnet mask, but that option is not possible due the network complexity. Im forced to do this using two network adapters on the same machine (NT Server 4.0) containing the DHCP Server. Thanks in advanced. ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-dhcp-v6@bucknell.edu Fri Jun 16 00:05:44 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23851 for ; Fri, 16 Jun 2000 00:05:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5G40nW25309; Fri, 16 Jun 2000 00:00:53 -0400 (EDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5G40dW20184 for ; Fri, 16 Jun 2000 00:00:39 -0400 (EDT) Received: by zmamail05.zma.compaq.com (Postfix, from userid 12345) id 5204C3A14; Fri, 16 Jun 2000 00:00:24 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 1548B3980 for ; Fri, 16 Jun 2000 00:00:24 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id AAA0000834320; Fri, 16 Jun 2000 00:00:22 -0400 (EDT) From: Jim Bound Message-Id: <200006160400.AAA0000834320@anw.zk3.dec.com> To: DHCPv6 discussion list Subject: our updated drafts ... Date: Fri, 16 Jun 2000 00:00:21 -0400 X-Mts: smtp Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN hi folks, pretty quiet so does every love our new drafts :-----).... thanks /jim From owner-dhcp-v4@bucknell.edu Mon Jun 19 11:20:18 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10282 for ; Mon, 19 Jun 2000 11:20:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5JFGdW30102; Mon, 19 Jun 2000 11:16:39 -0400 (EDT) Received: from hotmail.com (law2-f87.hotmail.com [216.32.181.87]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5JFGMW29871 for ; Mon, 19 Jun 2000 11:16:26 -0400 (EDT) Received: (qmail 90839 invoked by uid 0); 19 Jun 2000 15:15:48 -0000 Message-ID: <20000619151548.90838.qmail@hotmail.com> Received: from 195.77.235.2 by www.hotmail.com with HTTP; Mon, 19 Jun 2000 08:15:48 PDT X-Originating-IP: [195.77.235.2] From: "Marc" To: DHCPv4 discussion list Subject: Define path in startup.bat Date: Mon, 19 Jun 2000 17:15:48 CEST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Reply-To: marc_jaumandreu@hotmail.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Can i define a specific path in the startup.bat? I need that workstations change their local path with a new path served by startup.bat. Workstations are NT Workstation 4.0 and Windows 95. Is it possible? Thanks to all ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-dhcp-v4@bucknell.edu Mon Jun 19 15:51:38 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21944 for ; Mon, 19 Jun 2000 15:51:37 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5JJm7W07192; Mon, 19 Jun 2000 15:48:07 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5JJm2W02599 for ; Mon, 19 Jun 2000 15:48:02 -0400 (EDT) Received: from grosse.bisbee.fugue.com (a0.pm3-28.theriver.com [206.102.195.16]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id VAA14535 for ; Sun, 18 Jun 2000 21:08:05 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id MAA01220 for ; Mon, 19 Jun 2000 12:48:15 -0700 (MST) Message-Id: <200006191948.MAA01220@grosse.bisbee.fugue.com> To: DHCPv4 discussion list Subject: Classless Static Routes option, final discussion (I hope)! Date: Mon, 19 Jun 2000 12:48:15 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I've just submitted what I hope will be the final version of the classless static routes option. I clarified some text about how the client must behave - it was sufficiently ambiguous that I think there was room for non-interoperating implementations, unfortunately. I also fixed an example so that it made sense given the more compact encoding - it wasn't actually possible to encode the previous example. :'} Diffs are included below, FYA. There is one remaining bug that I just noticed - I said "should" twice in the last significant diff when I should have said "SHOULD" and "[should] not" when I should have said "SHOULD NOT". If it's acceptable to the group, I can fix these when the IANA issues us an option code. _MelloN_ *** draft-ietf-dhc-csr-01.txt Wed Mar 15 10:48:05 2000 --- draft-ietf-dhc-csr-02.txt Mon Jun 19 11:48:41 2000 *************** *** 2,13 **** Network Working Group Ted Lemon Internet Draft Nominum, Inc. ! Obsoletes: draft-ietf-dhc-csr-00.txt March, 2000 ! Expires September 2000 The Classless Static Route Option for DHCP ! Status of this Memo --- 2,13 ---- Network Working Group Ted Lemon Internet Draft Nominum, Inc. ! Obsoletes: draft-ietf-dhc-csr-01.txt June, 2000 ! Expires January 2001 The Classless Static Route Option for DHCP ! Status of this Memo *************** *** 162,172 **** DHCP Client Behavior ! The DHCP client MAY use this option to install a set of static ! routes in its routing table. A DHCP client that implements this ! option SHOULD use this option in preference to the Static routes ! option if both are present in a reply from the DHCP server. The ! client MAY request both options. After deriving a subnet number and subnet mask from each destination descriptor, the DHCP client SHOULD check each route to --- 162,179 ---- DHCP Client Behavior ! DHCP clients that do not support this option MUST ignore it if it ! is received from a DHCP server. DHCP clients that support this ! option MUST install the routes specified in the option. ! ! DHCP clients that support this option and that send a DHCP ! Parameter Request List option MUST request both this option and ! the Routers option [2] in the DHCP Parameter Request List. ! ! If the DHCP server returns a Routers option, clients that support ! the Classless Static Routes option MUST use the default route(s) ! listed in the Routers option in addition to the routes listed ! in the Classless Static Routes option. After deriving a subnet number and subnet mask from each destination descriptor, the DHCP client SHOULD check each route to *************** *** 174,180 **** value is one whose corresponding value in the subnet mask is zero, and SHOULD NOT install any routes for which this is the case. For example, the client should not install a route with a destination ! of 129.210.377.4 and a subnet mask of 255.255.255.0. Because a full routing table can be quite large, the standard 576 octet maximum size for a DHCP message may be too short to contain --- 181,187 ---- value is one whose corresponding value in the subnet mask is zero, and SHOULD NOT install any routes for which this is the case. For example, the client should not install a route with a destination ! of 129.210.377.4 and a subnet mask of 255.255.255.128. Because a full routing table can be quite large, the standard 576 octet maximum size for a DHCP message may be too short to contain *************** *** 187,209 **** DHCP Server administrator responsibilities ! The client's behaviour if both a Routers option and a Classless ! Static Routes option default route (network number 0.0.0.0, network ! mask 0.0.0.0) are specified is not defined in this document, so as ! to avoid placing onerous requirements on the client and server ! implementations. Therefore, the DHCP server administrator SHOULD ! NOT configure the DHCP server so that it sends both a Routers ! option and a Classless Static Routes option containing a default ! route. Either no Routers option should be configured (this is ! probably preferable in the near term, since only newer DHCP clients ! will implement this option), or the Classless Static Routes option ! should not contain a default route. ! ! The client's behaviour is also not defined in the case where the ! server sends a classless static route in which some bits in the ! network number are 1, and corresponding bits in the subnet mask are ! zero. Therefore, DHCP server administrators SHOULD NOT configure ! the DHCP server to send such a route. Security Considerations --- 194,205 ---- DHCP Server administrator responsibilities ! Many clients may not implement the Classless Static Routes option. ! DHCP server administrators should therefore configure their DHCP ! servers to send both a Routers option and a Classless Static ! Routes option, and should specify all default routes in the Routers ! option, and not specify any default routes in the Classless ! Static Routes option. Security Considerations *************** *** 247,253 **** Expiration ! This document will expire on July 31, 2000. Full Copyright Statement --- 243,249 ---- Expiration ! This document will expire on January 31, 2001. Full Copyright Statement From owner-dhcp-v4@bucknell.edu Tue Jun 20 08:25:53 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19028 for ; Tue, 20 Jun 2000 08:25:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5KCLNW27089; Tue, 20 Jun 2000 08:21:23 -0400 (EDT) Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5KCLAW00048 for ; Tue, 20 Jun 2000 08:21:10 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-166.cisco.com [161.44.133.166]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id IAA01157 for ; Tue, 20 Jun 2000 08:21:08 -0400 (EDT) Message-Id: <4.3.1.2.20000620082308.00b0e180@funnel.cisco.com> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 20 Jun 2000 08:23:24 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: WG last call for "Authentication for DHCP Messages" (REMINDER) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message announces a DHC WG last call for "Authentication for DHCP Messages", . The WG discussed the previous revision in Adelaide and agreed to go to WG last call after some editorial changes, which have been incorporated into this latest revision of the spec: * edited "Discussion" in section 1 to eliminate references to expired Internet Drafts * exchanged RDM and Algorithm fields * fixed RDM values - 0x00 is counter method (as defined in draft); all other values are "reserved" * edited first sentence of 5.1 to clarify that protocol 1 is aimed at intradomain authentication and other protocols may address interdomain authentication * changed the two header diagrams in 5.2 to show "Algorithm" field (allowing for multiple algorithms) rather than specifying "00000000" (which didn't match with the specification that HMAC-MD5 use "0x01"). * Edited first sentence of 5.3 to refer more generally to the specified RDM, rather than explicitly desribing the use of RDM 1. * Also edited 5.3 to allow for different algorithms. * Edited section 6 to describe definition of new protocol. algorithm or RDM. Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, June 23. - Ralph Droms From owner-dhcp-v4@bucknell.edu Wed Jun 21 06:50:13 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25872 for ; Wed, 21 Jun 2000 06:50:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5LAjhW01014; Wed, 21 Jun 2000 06:45:43 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5LAjcW23491 for ; Wed, 21 Jun 2000 06:45:38 -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 GAA25632; Wed, 21 Jun 2000 06:45:38 -0400 (EDT) Message-Id: <200006211045.GAA25632@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-pv4-reconfigure-01.txt Date: Wed, 21 Jun 2000 06:45:38 -0400 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Dynamic host configuration : DHCP reconfigure extension Author(s) : P. De Schrijver, Y. T'Joens, C. Hublet Filename : draft-ietf-dhc-pv4-reconfigure-01.txt Pages : 5 Date : 20-Jun-00 This draft defines extensions to DHCP [DHCP] to allow dynamic reconfiguration of a single host triggered by the DHCP server (eg. a new IP address). This is achieved by introducing a unicast DHCP FORCERENEW message which forces the client to the RENEW state. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-pv4-reconfigure-01.txt 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-pv4-reconfigure-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-pv4-reconfigure-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: <20000620112024.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-pv4-reconfigure-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-pv4-reconfigure-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000620112024.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Wed Jun 21 06:50:14 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25883 for ; Wed, 21 Jun 2000 06:50:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5LAnQW20034; Wed, 21 Jun 2000 06:49:26 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5LAjgW16772 for ; Wed, 21 Jun 2000 06:45:42 -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 GAA25646; Wed, 21 Jun 2000 06:45:42 -0400 (EDT) Message-Id: <200006211045.GAA25646@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-csr-02.txt Date: Wed, 21 Jun 2000 06:45:42 -0400 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --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 Filename : draft-ietf-dhc-csr-02.txt Pages : 5 Date : 20-Jun-00 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. This option supersedes the Static Route option (option 33) defined in [2]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-csr-02.txt 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-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-csr-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000620112036.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-csr-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-csr-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000620112036.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Wed Jun 21 09:59:10 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02062 for ; Wed, 21 Jun 2000 09:59:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5LDtaW22406; Wed, 21 Jun 2000 09:55:36 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5LDtTW11819 for ; Wed, 21 Jun 2000 09:55:29 -0400 (EDT) Received: by LESPAUL with Internet Mail Service (5.5.2650.21) id ; Wed, 21 Jun 2000 09:55:13 -0400 Received: by LESPAUL with Internet Mail Service (5.5.2650.21) id ; Wed, 21 Jun 2000 09:53:33 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBE2D@LESPAUL> From: Bernie Volz To: DHCPv4 discussion list Cc: "'dhcpv4@bucknell.edu'" Subject: RE: draft-ietf-dhc-csr-02.txt Date: Wed, 21 Jun 2000 09:53:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Volz@ipworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ted: draft-ietf-dhc-csr-02.txt looks good. I do have one issue with it however. Why do you want to use the following policy? If the DHCP server returns a Routers option, clients that support the Classless Static Routes option MUST use the default route(s) listed in the Routers option in addition to the routes listed in the Classless Static Routes option. >From a server configuration standpoint, wouldn't it be better if the CSR option was just and the Routers option ignored? In this way, one can configure both options for a server (the Routers option can carry a less-than-optimal routing list because of the limitations of representing the data and the CSR option can contain the full routing information). A client can request both (if it supports both) since it does not know if the server supports CSR or not. The server then sends back both (since the client requested them) and the client uses the more optimial option (CSR) if it is present and ignores the Routers (if present). Otherwise, the configuration gets messy since you might have the following situations: A) Client supports only Router option. B) Client supports both Router and CSR option. This means that the server's configuration would have to allow for a Router option if CSR not support and a Router option if CSR supported by client. So, I'd recommend the text to read: If the DHCP server returns both the Routers and Classless Static Routes options, clients that support the Classless Static Routes option MUST NOT use the default route(s) listed in the Routers option; they MUST use only the routes listed in the Classless Static Routes option. Again, that's my only issue. Regards, - Bernie Volz IPWorks, Inc From owner-dhcp-v4@bucknell.edu Wed Jun 21 10:36:30 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03087 for ; Wed, 21 Jun 2000 10:36:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5LEXjW12811; Wed, 21 Jun 2000 10:33:45 -0400 (EDT) Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5LEXdW09542 for ; Wed, 21 Jun 2000 10:33:39 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-166.cisco.com [161.44.133.166]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id KAA01834 for ; Wed, 21 Jun 2000 10:33:38 -0400 (EDT) Message-Id: <4.3.1.2.20000621102821.00b181b0@funnel.cisco.com> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 21 Jun 2000 10:32:21 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: WG last call for "Dynamic host configuration : DHCP reconfigure extension" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message announces a DHC WG last call for "Dynamic host configuration : DHCP reconfigure extension", . The WG discussed the previous revision in Adelaide and agreed to go to WG last call after some editorial changes, which have been incorporated into this latest revision of the spec: * In the security section, changed to: "the DHCPFORCERENEW message MUST be authenticated using a shared secret based mechanism as described in [DHCP-AUTH]" * An update to RFC2489 has been submitted to specify the mechanism for allocation of new DHCP message codes Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, June 30. - Ralph Droms From owner-dhcp-v4@bucknell.edu Wed Jun 21 13:05:30 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08674 for ; Wed, 21 Jun 2000 13:05:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5LH28W02243; Wed, 21 Jun 2000 13:02:08 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5LH1vW04619 for ; Wed, 21 Jun 2000 13:01:57 -0400 (EDT) Received: from grosse.bisbee.fugue.com (a30.pm3-28.theriver.com [206.102.195.46]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id SAA22809 for ; Tue, 20 Jun 2000 18:22:00 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id KAA00583 for ; Wed, 21 Jun 2000 10:02:16 -0700 (MST) Message-Id: <200006211702.KAA00583@grosse.bisbee.fugue.com> To: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-csr-02.txt In-Reply-To: Message from Bernie Volz of "Wed, 21 Jun 2000 09:53:28 -0400." <63D30D6E10CFD11190A90000F805FE8602BEBE2D@LESPAUL> Date: Wed, 21 Jun 2000 10:02:16 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > From a server configuration standpoint, wouldn't it be better if the CSR > option was just and the Routers option ignored? Yes, it would. However, the problem with this is that it creates an insoluble interoperability problem. By stating the requirements for the server and client the way I did, we can be certain that if people follow these requirements, clients that support CSR and clients that do not will continue to work. Without following these requirements, it's easy to imagine situations where some clients won't get a correct default route. I think that in an ideal world, we'd just use CSR and not the routers option, but the world we live in is unfortunately not ideal in this one small way. :'} _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Jun 21 13:05:44 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08693 for ; Wed, 21 Jun 2000 13:05:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5LH4mW26968; Wed, 21 Jun 2000 13:04:48 -0400 (EDT) Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5LH4ZW00929 for ; Wed, 21 Jun 2000 13:04:35 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-166.cisco.com [161.44.133.166]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id NAA01925 for ; Wed, 21 Jun 2000 13:04:34 -0400 (EDT) Message-Id: <4.3.1.2.20000621103528.00b19d40@funnel.cisco.com> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 21 Jun 2000 13:06:47 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: WG last call for "The Classless Static Route Option for DHCP" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message announces a DHC WG last call for "The Classless Static Route Option for DHCP" . The WG discussed the previous revision in Adelaide and agreed to go to WG last call after some editorial changes, which have been incorporated into this latest revision of the spec. Ted posted the diffs for the new rev earlier this week. Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, June 30. - Ralph Droms From owner-dhcp-v4@bucknell.edu Wed Jun 21 13:20:47 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09132 for ; Wed, 21 Jun 2000 13:20:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5LHJlW10002; Wed, 21 Jun 2000 13:19:47 -0400 (EDT) Received: from postal.metaip.checkpoint.com (metaip.checkpoint.com [204.29.28.25]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5LHJVW09285 for ; Wed, 21 Jun 2000 13:19:31 -0400 (EDT) Received: from cartman.metainfo.com (cartman.metainfo.com [204.29.28.145]) by postal.metaip.checkpoint.com (8.9.3/8.9.3VRJ666) with ESMTP id KAA14239; Thu, 22 Jun 2000 10:16:43 -0700 Received: from metaip.checkpoint.com (sneakers.metainfo.com [204.29.28.213]) by cartman.metainfo.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MLNKN850; Wed, 21 Jun 2000 10:13:16 -0700 Sender: owner-dhcp-v4@bucknell.edu Message-ID: <3950EC02.1B7BD02D@metaip.checkpoint.com> Date: Wed, 21 Jun 2000 09:23:30 -0700 From: Richard Jones Organization: Checkpoint Software Technologies X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list CC: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-csr-02.txt References: <200006211702.KAA00583@grosse.bisbee.fugue.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: richardj@metaip.checkpoint.com X-Sender: richardj@postal.metaip.checkpoint.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit I thought the same thing at first, but after a few minutes I came to agree that from an interoperability standpoint, Ted's language is the broadest and safest, even though it does mean configuration gets more difficult. A couple of non-protocol editorial suggestions: in paragraph 1 sentence 2 of the Introduction, you might remove the first instance of the phrase "to see if" to make it clearer, i.e. "it first checks the IP address of the destination" And in paragraph 6, make 'seperate' into 'separate'. By the way, if this type of feedback isn't considered useful or necessary, please let me know and I'll quit natting the documents ;-). Richard Ted Lemon wrote: > > From a server configuration standpoint, wouldn't it be better if the CSR > > option was just and the Routers option ignored? > > Yes, it would. However, the problem with this is that it creates an > insoluble interoperability problem. By stating the requirements for > the server and client the way I did, we can be certain that if people > follow these requirements, clients that support CSR and clients that > do not will continue to work. Without following these requirements, > it's easy to imagine situations where some clients won't get a correct > default route. I think that in an ideal world, we'd just use CSR and > not the routers option, but the world we live in is unfortunately not > ideal in this one small way. :'} > > _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Jun 21 13:43:23 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09612 for ; Wed, 21 Jun 2000 13:43:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5LHeYW15482; Wed, 21 Jun 2000 13:40:34 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5LHeVW09721 for ; Wed, 21 Jun 2000 13:40:31 -0400 (EDT) Received: by LESPAUL with Internet Mail Service (5.5.2650.21) id ; Wed, 21 Jun 2000 13:40:16 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBE37@LESPAUL> From: Bernie Volz To: DHCPv4 discussion list Subject: RE: draft-ietf-dhc-csr-02.txt Date: Wed, 21 Jun 2000 13:40:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Volz@ipworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ted: I don't follow. What interop problem? A server is configured with both the Router and CSR options. The router option might not have the best information because of its limitations - some routes may be less than optimum. The CSR has the full routing information. Now, a client either supports CSR or it doesn't. - If it doesn't it won't request the option and/or ignores it when it is received. - If it does, if the server doesn't send it, router is used as before. If server does send it, then CSR is used. What's the interop problem? Are you saying that someone messed up and didn't set the options up correctly and thus a client that uses CSR won't have the same information as one that uses Router? That may be intentional. An example might be if I'm using 10 networks but I only have 10.1/16 and 10.2/16 defined, why can't I set router to have a route for 10.0.0.0 and CSR to have routes only for 10.1 and 10.2 (*NO* 10/8 route at all). Having the 10/8 route installed does me no good since I have no addresses other than 10.1 and 10.2. Sure, if I later add 10.3/8 the older clients (using Router) might continue to work whereas the newer clients using CSR won't until I "fix" the configuration. But, that's what I'm supposed to do anyway. There are likely better "real-world" situations that others may come up with?? - Bernie Volz IPWorks, Inc. -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, June 21, 2000 1:02 PM To: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-csr-02.txt > From a server configuration standpoint, wouldn't it be better if the CSR > option was just and the Routers option ignored? Yes, it would. However, the problem with this is that it creates an insoluble interoperability problem. By stating the requirements for the server and client the way I did, we can be certain that if people follow these requirements, clients that support CSR and clients that do not will continue to work. Without following these requirements, it's easy to imagine situations where some clients won't get a correct default route. I think that in an ideal world, we'd just use CSR and not the routers option, but the world we live in is unfortunately not ideal in this one small way. :'} _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Jun 21 13:44:21 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09649 for ; Wed, 21 Jun 2000 13:44:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5LHfYW04301; Wed, 21 Jun 2000 13:41:34 -0400 (EDT) Received: from postal.metaip.checkpoint.com (metaip.checkpoint.com [204.29.28.25]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5LHfLW19782; Wed, 21 Jun 2000 13:41:21 -0400 (EDT) Received: from cartman.metainfo.com (cartman.metainfo.com [204.29.28.145]) by postal.metaip.checkpoint.com (8.9.3/8.9.3VRJ666) with ESMTP id KAA14439; Thu, 22 Jun 2000 10:38:41 -0700 Received: from metaip.checkpoint.com (sneakers.metainfo.com [204.29.28.213]) by cartman.metainfo.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MLNKN88B; Wed, 21 Jun 2000 10:35:14 -0700 Sender: owner-dhcp-v4@bucknell.edu Message-ID: <3950F129.D1D8DE97@metaip.checkpoint.com> Date: Wed, 21 Jun 2000 09:45:29 -0700 From: Richard Jones Organization: Checkpoint Software Technologies X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list CC: DHCPv4 discussion list Subject: Re: WG last call for "Authentication for DHCP Messages" References: <4.2.2.20000613231312.00a39100@mail.bucknell.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: richardj@metaip.checkpoint.com X-Sender: richardj@postal.metaip.checkpoint.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Some questions about the draft: In the first format diagram (Section 2) there are two fields labelled 'Algorithm'. Should the second one be RDM, or do I misunderstand? The last paragraph of Section 5.2 (Format) states that the authentication request can only appear in a DHCPDISCOVER message, while section 5.5.5 (DHCPINFORM) suggests that the client SHOULD use the request in that message type. I'm fine with using it in both messages, but wonder if the wording of section 5.2 should be changed to avoid confusion. In the second paragraph of Section 5.6.4, the implication seems to be that if a server doesn't have a shared secret value with a client sending a DHCPINFORM with authentication request, it needs to either ACK or NAK the message. But ignoring the message seems like a valid option too. Perhaps this is too obvious, but I thought it would be good for the sake of clarity to state it. Editorial stuff: Section 5, sentence 2, you might want to remove the second 'information'. Section 5.3, sentence 2, should start "Next the receiver..."? Thanks, Richard Ralph Droms wrote: > This message announces a DHC WG last call for "Authentication for DHCP > Messages", . The WG discussed the > previous revision in Adelaide and agreed to go to WG last call after some > editorial changes, which have been incorporated into this latest revision > of the spec: > > * edited "Discussion" in section 1 to eliminate references to expired > Internet Drafts > * exchanged RDM and Algorithm fields > * fixed RDM values - 0x00 is counter method (as defined in draft); all > other values are "reserved" > * edited first sentence of 5.1 to clarify that protocol 1 is aimed at > intradomain authentication and other protocols may address > interdomain authentication > * changed the two header diagrams in 5.2 to show "Algorithm" field > (allowing for multiple algorithms) rather than specifying "00000000" > (which didn't match with the specification that HMAC-MD5 use > "0x01"). > * Edited first sentence of 5.3 to refer more generally to the > specified RDM, rather than explicitly desribing the use of RDM 1. > * Also edited 5.3 to allow for different algorithms. > * Edited section 6 to describe definition of new protocol. algorithm > or RDM. > > Please forward any comments you may have on this draft to > dhcp-v4@bucknell.edu by Friday, June 23. > > - Ralph Droms From owner-dhcp-v4@bucknell.edu Wed Jun 21 16:35:26 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12395 for ; Wed, 21 Jun 2000 16:35:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5LKWHW24649; Wed, 21 Jun 2000 16:32:17 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5LKW4W07880 for ; Wed, 21 Jun 2000 16:32:04 -0400 (EDT) Received: from grosse.bisbee.fugue.com (a28.pm3-30.theriver.com [206.102.195.140]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id VAA23053; Tue, 20 Jun 2000 21:52:06 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id NAA00337; Wed, 21 Jun 2000 13:32:20 -0700 (MST) Message-Id: <200006212032.NAA00337@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-csr-02.txt In-Reply-To: Message from Bernie Volz of "Wed, 21 Jun 2000 13:40:15 -0400." <63D30D6E10CFD11190A90000F805FE8602BEBE37@LESPAUL> Date: Wed, 21 Jun 2000 13:32:20 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I don't follow. What interop problem? Consider these three server configurations: - Server A is configured with just a routers option. - Server B is configured with just a CSR option. - Server C is configured with all the default routes in the routers option and any other routes in the CSR option. Now consider the following three clients: - Client A asks for and can handle the CSR option, but does not ask for or handle the routers option. - Client B asks for both the CSR option and the routers option, and will use both. - Client C asks for just the routers option, because it's an old client that doesn't support CSR. Client A will not interoperate with Server A - the server will not send it any routes at all. Nor will it interoperate with server C - server C will send it only the CSR option, but the CSR option doesn't contain any default routes. So client A will only successfully interoperate with server B. Client B will interoperate with server A - it'll get its default routes. It will interoperate with server B as well - if there are default routes, it will get them from the CSR option. It will also interoperate with Server C. Client C (remember, this is all currently-deployed clients) will interoperate with server A or server C, although in the case that some of the routes in the CSR option are required, it won't be able to get to those networks. It will not interoperate at all with server B. Here's a chart: Server A B C Client A NO YES NO B YES YES YES C YES NO YES Client A is the client you're proposing. It's a new client, so it should work well in as many situations as possible. As you can see, there's only one situation where it will work. Client B is the client specified in the draft. Client B will work with any server, even one that is incorrectly configured (server B). Client C is the standard client that we all expect to deal with now. It will not interoperate with server B - the server you propose - but will interoperate with server A - a server configured the way most servers are now configured, and also with server C - a server configured as specified in the draft. This is why the draft specifically excludes clients like A and servers like B. If we exclude both of these implementations, we are left with only boxes containing "YES". :'} You could propose some kind of adaptive strategy for allowing a B-like server to deal with a C-like client, or an A-like client to deal with an A- or C-like server, but to do this would make the draft quite a bit more complicated, and would require special handling of the CSR option in the server. Right now, other than the encoding, the handling of the CSR option in the server requires no special decision making. A CSR-capable client has to be able to handle the routers option so that it can interoperate with an A-like server, so we're not introducing any significant additional complexity in the client by requiring client B rather than client A. _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Jun 21 16:53:47 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12688 for ; Wed, 21 Jun 2000 16:53:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5LKr3W13325; Wed, 21 Jun 2000 16:53:03 -0400 (EDT) Received: from web904.mail.yahoo.com (web904.mail.yahoo.com [128.11.23.79]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5LKqxW08765 for ; Wed, 21 Jun 2000 16:52:59 -0400 (EDT) Received: (qmail 21050 invoked by uid 60001); 21 Jun 2000 20:52:58 -0000 Message-ID: <20000621205258.21049.qmail@web904.mail.yahoo.com> Received: from [129.188.33.222] by web904.mail.yahoo.com; Wed, 21 Jun 2000 13:52:58 PDT Date: Wed, 21 Jun 2000 13:52:58 -0700 (PDT) From: jie weng Subject: router configuration To: DHCPv4 discussion list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Reply-To: jie1723@yahoo.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi all, I have a question concerning the scope of the DHCP protocol. In RFC (2131) section 1.3, it states that "DHCP is not intended for use in configuring routers." My question is can DHCP be used for router configuration and if not why?? Thanks Jie __________________________________________________ Do You Yahoo!? Send instant messages with Yahoo! Messenger. http://im.yahoo.com/ From owner-dhcp-v4@bucknell.edu Wed Jun 21 17:05:00 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12899 for ; Wed, 21 Jun 2000 17:04:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5LL4EW14497; Wed, 21 Jun 2000 17:04:14 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5LL4DW12010 for ; Wed, 21 Jun 2000 17:04:13 -0400 (EDT) Received: by LESPAUL with Internet Mail Service (5.5.2650.21) id ; Wed, 21 Jun 2000 17:03:57 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBE3F@LESPAUL> From: Bernie Volz To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: RE: draft-ietf-dhc-csr-02.txt Date: Wed, 21 Jun 2000 17:03:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Volz@ipworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ted: I'd consider some of the clients and servers broken/misconfigured. Client A is not at all what I'm proposing. My position regarding Clients is: - If a Client supports the CSR option, it MUST also support the Routers option. And it MUST ask for both options. - However, if that Client receives a CSR option, it MUST use only the CSR option (the Router option is ignored). My position regarding Servers is: - If they support the CSR option, they MUST support the Router option. - When configured, its is HIGHLY suggested that BOTH the Router and CSR option be configured with appropriate routes. CSR for those clients that support it; Router for others. One could add the following statement for servers as well: - If a Server receives a client request where both the Router and CSR options are requested and it has both these options configured, it MAY chose to not send the Router option to these clients to conserve packet space. [Since it knows that these clients will not use it anyway.] I guess in thinking about this some more, in general, adding the routes in the Router option probably won't hurt - it might cause some unnecessary routes to be installed. Though I haven't thought thru all the routing cases and for some reason my gut says that supernetting (such as having multiple Class C's) might cause problems in some instances (certainly you could have multiple or unnecessary routes). I just don't like the idea of merging these two lists. - Bernie Volz IPWorks, Inc. -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, June 21, 2000 4:32 PM To: Bernie Volz Cc: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-csr-02.txt > I don't follow. What interop problem? Consider these three server configurations: - Server A is configured with just a routers option. - Server B is configured with just a CSR option. - Server C is configured with all the default routes in the routers option and any other routes in the CSR option. Now consider the following three clients: - Client A asks for and can handle the CSR option, but does not ask for or handle the routers option. - Client B asks for both the CSR option and the routers option, and will use both. - Client C asks for just the routers option, because it's an old client that doesn't support CSR. Client A will not interoperate with Server A - the server will not send it any routes at all. Nor will it interoperate with server C - server C will send it only the CSR option, but the CSR option doesn't contain any default routes. So client A will only successfully interoperate with server B. Client B will interoperate with server A - it'll get its default routes. It will interoperate with server B as well - if there are default routes, it will get them from the CSR option. It will also interoperate with Server C. Client C (remember, this is all currently-deployed clients) will interoperate with server A or server C, although in the case that some of the routes in the CSR option are required, it won't be able to get to those networks. It will not interoperate at all with server B. Here's a chart: Server A B C Client A NO YES NO B YES YES YES C YES NO YES Client A is the client you're proposing. It's a new client, so it should work well in as many situations as possible. As you can see, there's only one situation where it will work. Client B is the client specified in the draft. Client B will work with any server, even one that is incorrectly configured (server B). Client C is the standard client that we all expect to deal with now. It will not interoperate with server B - the server you propose - but will interoperate with server A - a server configured the way most servers are now configured, and also with server C - a server configured as specified in the draft. This is why the draft specifically excludes clients like A and servers like B. If we exclude both of these implementations, we are left with only boxes containing "YES". :'} You could propose some kind of adaptive strategy for allowing a B-like server to deal with a C-like client, or an A-like client to deal with an A- or C-like server, but to do this would make the draft quite a bit more complicated, and would require special handling of the CSR option in the server. Right now, other than the encoding, the handling of the CSR option in the server requires no special decision making. A CSR-capable client has to be able to handle the routers option so that it can interoperate with an A-like server, so we're not introducing any significant additional complexity in the client by requiring client B rather than client A. _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Jun 21 17:08:47 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12967 for ; Wed, 21 Jun 2000 17:08:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5LL61W15362; Wed, 21 Jun 2000 17:06:01 -0400 (EDT) Received: from Arachnid.NTRG.com ([209.31.7.46]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5LL60W24697 for ; Wed, 21 Jun 2000 17:06:00 -0400 (EDT) Received: from ehsco.com (nat-external.ehsco.com [209.31.7.42]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 628; Wed, 21 Jun 2000 14:05:56 -0700 Message-ID: <39512E33.573D0F62@ehsco.com> Date: Wed, 21 Jun 2000 14:05:56 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list CC: DHCPv4 discussion list Subject: Re: router configuration References: <20000621205258.21049.qmail@web904.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: ehall@ehsco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > I have a question concerning the scope of the > DHCP protocol. In RFC (2131) section 1.3, it states > that "DHCP is not intended for use in configuring > routers." My question is can DHCP be used for router > configuration and if not why?? Thanks Routers are required for relaying bootp/dhcp messages, so you don't want to configure them with dhcp just like you don't want to configure dhcp servers with dhcp. If the device' lease expires, all of the downstream dhcp clients will be negatively affected by it, to say the least. Given that disclaimer, there is some benefit to be had from it. I would love to be able to configure my Cisco router's DNS, NTP, and various other agents using bootp/dhcp instead of having to manually reconfig the boxes everytime I change my infrastructure. But at the same time, I certainly wouldn't want the device' addressing services to rely on it. Unfortunately, there isn't any easy way to decouple configuration data from an address assignment with DHCP. If you want the icing you have to take the cake, too. Although I suppose an address could just be held as a "ticket" without requiring that it be used, the device would also have to answer to ping and ARP requests to prevent pre-lease queries from going unanswered. Not that any of this matters, the last time I tried talking Cisco into this I got a big shrug. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-dhcp-v4@bucknell.edu Wed Jun 21 17:09:41 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12997 for ; Wed, 21 Jun 2000 17:09:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5LL98W30824; Wed, 21 Jun 2000 17:09:08 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5LL8rW08424 for ; Wed, 21 Jun 2000 17:08:53 -0400 (EDT) Received: by LESPAUL with Internet Mail Service (5.5.2650.21) id ; Wed, 21 Jun 2000 17:08:37 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBE40@LESPAUL> From: Bernie Volz To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: RE: router configuration Date: Wed, 21 Jun 2000 17:08:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Volz@ipworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Fundamentally, you could use DHCP to configure routers. I don't really see any reason you couldn't. But, you certainly would NOT want to use fully dynamic addresses since then you won't know where your router was. But, if you have fixed addresses assigned to the MAC addresses/client identifiers for each interface, you could use it to assign addresses. However, routers typically require a lot more configuration and DHCP was never designed to communicate the remainder of that configuration information. Routers are also thought of as the plumbing for IP and therefore they are usually assumed to be up and running as quickly as possible and hence use flash memory to store configuration information (such as interface addresses). Also, routers might be required to provide DHCP services (relaying) - since otherwise you'd need a DHCP server on each "subnetwork". - Bernie Volz IPWorks, Inc -----Original Message----- From: jie weng [mailto:jie1723@YAHOO.COM] Sent: Wednesday, June 21, 2000 4:53 PM To: DHCPv4 discussion list Subject: router configuration Hi all, I have a question concerning the scope of the DHCP protocol. In RFC (2131) section 1.3, it states that "DHCP is not intended for use in configuring routers." My question is can DHCP be used for router configuration and if not why?? Thanks Jie __________________________________________________ Do You Yahoo!? Send instant messages with Yahoo! Messenger. http://im.yahoo.com/ From owner-dhcp-v4@bucknell.edu Wed Jun 21 17:46:39 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13563 for ; Wed, 21 Jun 2000 17:46:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5LLhaW18100; Wed, 21 Jun 2000 17:43:36 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5LLhNW09695 for ; Wed, 21 Jun 2000 17:43:23 -0400 (EDT) Received: from grosse.bisbee.fugue.com (a28.pm3-30.theriver.com [206.102.195.140]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id XAA23231; Tue, 20 Jun 2000 23:03:25 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id OAA00447; Wed, 21 Jun 2000 14:43:40 -0700 (MST) Message-Id: <200006212143.OAA00447@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-csr-02.txt In-Reply-To: Message from Bernie Volz of "Wed, 21 Jun 2000 17:03:57 -0400." <63D30D6E10CFD11190A90000F805FE8602BEBE3F@LESPAUL> Date: Wed, 21 Jun 2000 14:43:39 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > My position regarding Servers is: > - If they support the CSR option, they MUST support the Router option. > - When configured, its is HIGHLY suggested that BOTH the Router and CSR > option be configured with appropriate routes. CSR for those clients that > support it; Router for others. So you either have to hack the server to special-case this particular configuration, or you have to require the server administrator to configure the same information in two seperate locations. > One could add the following statement for servers as well: > - If a Server receives a client request where both the Router and CSR > options are requested and it has both these options configured, it MAY chose > to not send the Router option to these clients to conserve packet space. > [Since it knows that these clients will not use it anyway.] This means adding complexity to the server. > I guess in thinking about this some more, in general, adding the routes in > the Router option probably won't hurt - it might cause some unnecessary > routes to be installed. Though I haven't thought thru all the routing cases > and for some reason my gut says that supernetting (such as having multiple > Class C's) might cause problems in some instances (certainly you could have > multiple or unnecessary routes). I just don't like the idea of merging these > two lists. Routes is routes. What's the difference? There's nothing wrong with what you're proposing in terms of functionality, Bernie, and it does make the contents of conforming server responses contain one less option, at the possible savings of one byte. But I think that the potential one-byte penalty for doing it as stated in the draft is a small price to pay for the reduced complexity of specification and implementation, and the reduced likelihood of mistakes that this reduction in complexity brings. :') _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Jun 21 18:22:14 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14045 for ; Wed, 21 Jun 2000 18:22:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5LMJNW19601; Wed, 21 Jun 2000 18:19:23 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5LMJFW04948 for ; Wed, 21 Jun 2000 18:19:15 -0400 (EDT) Received: by LESPAUL with Internet Mail Service (5.5.2650.21) id ; Wed, 21 Jun 2000 18:19:00 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBE42@LESPAUL> From: Bernie Volz To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: RE: draft-ietf-dhc-csr-02.txt Date: Wed, 21 Jun 2000 18:18:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Volz@ipworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >Routes is routes. What's the difference? Hum ... maybe we aren't discussing the same issue and I'm confused??? When, in the draft, you say "Routers option", are you referring to "Router option" (code 3) or the "Static Route option" (code 33)? There technically is no "Routers option" in RFC 2132. I guess the CSR draft should be clear about which option it is speaking of (giving the code numbers wouldn't hurt for clarity). I was assuming the "Static Route option (33)" and therefore you're saying to merge the classful list of routes with the CSR (class-less) ones. If you're talking about the "Router option" (code 3), then I certainly have no problems in applying those as the default routers to whatever is received with the CSR. However, the Static Route option (33) explicitly forbids the default route. Yet, CSR allows it. And, why not just use the Router option for default routes? If you're talking about the "Static Route option (33)", then I still have an issue that the list you might supply in the Static Route option, because it is class based, it is perhaps not always optimim for classless systems. For example, with class based addresses, you'd be required to specify 4 routes for a 192.1.0/22 network (192.1.0.0, 192.1.1.0, 192.1.2.0, 192.1.3.0). With classless, this is ONE route. [And, the classful one might restrict you in installing routes, such as having 192.1.1.1 be the router for 192.1.0.0 traffic.] And, if you merge the lists the classful ones are used first (in this case) and hence potentially better route via the 192.1.0/22 route is never used. (Routing tables are searched starting at the most explicit (/32, /31, ...) to least explicit (default route)). This is that supernetting issue that I mentioned previously. In a classless environment, the Static Route option (33) either becomes useless and one is forced to using default routes; or, if one really needs routes, one must construct the network configuration carefully and then it becomes less than optimal for classless systems. - Bernie Volz IPWorks, Inc -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, June 21, 2000 5:44 PM To: Bernie Volz Cc: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-csr-02.txt > My position regarding Servers is: > - If they support the CSR option, they MUST support the Router option. > - When configured, its is HIGHLY suggested that BOTH the Router and CSR > option be configured with appropriate routes. CSR for those clients that > support it; Router for others. So you either have to hack the server to special-case this particular configuration, or you have to require the server administrator to configure the same information in two seperate locations. > One could add the following statement for servers as well: > - If a Server receives a client request where both the Router and CSR > options are requested and it has both these options configured, it MAY chose > to not send the Router option to these clients to conserve packet space. > [Since it knows that these clients will not use it anyway.] This means adding complexity to the server. > I guess in thinking about this some more, in general, adding the routes in > the Router option probably won't hurt - it might cause some unnecessary > routes to be installed. Though I haven't thought thru all the routing cases > and for some reason my gut says that supernetting (such as having multiple > Class C's) might cause problems in some instances (certainly you could have > multiple or unnecessary routes). I just don't like the idea of merging these > two lists. Routes is routes. What's the difference? There's nothing wrong with what you're proposing in terms of functionality, Bernie, and it does make the contents of conforming server responses contain one less option, at the possible savings of one byte. But I think that the potential one-byte penalty for doing it as stated in the draft is a small price to pay for the reduced complexity of specification and implementation, and the reduced likelihood of mistakes that this reduction in complexity brings. :') _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Jun 21 18:40:06 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14268 for ; Wed, 21 Jun 2000 18:40:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5LMdPW25886; Wed, 21 Jun 2000 18:39:25 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5LMdCW25750 for ; Wed, 21 Jun 2000 18:39:12 -0400 (EDT) Received: from grosse.bisbee.fugue.com (a28.pm3-30.theriver.com [206.102.195.140]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id XAA23416; Tue, 20 Jun 2000 23:59:14 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id PAA00582; Wed, 21 Jun 2000 15:39:29 -0700 (MST) Message-Id: <200006212239.PAA00582@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-csr-02.txt In-Reply-To: Message from Bernie Volz of "Wed, 21 Jun 2000 18:18:59 -0400." <63D30D6E10CFD11190A90000F805FE8602BEBE42@LESPAUL> Date: Wed, 21 Jun 2000 15:39:29 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > When, in the draft, you say "Routers option", are you referring to "Router > option" (code 3) or the "Static Route option" (code 33)? There technically > is no "Routers option" in RFC 2132. I guess the CSR draft should be clear > about which option it is speaking of (giving the code numbers wouldn't hurt > for clarity). Oops. I was referring to the router option. I thought it was plural. Sorry about that. > If you're talking about the "Router option" (code 3), then I certainly have > no problems in applying those as the default routers to whatever is received > with the CSR. Okay, sounds like we actually agree, then. > However, the Static Route option (33) explicitly forbids the default > route. Yet, CSR allows it. And, why not just use the Router option > for default routes? Right. I don't know why the Static Route option explicitly forbids the default route, but it makes a certain amount of sense, anyway... :'} > In a classless environment, the Static Route option (33) either becomes > useless and one is forced to using default routes; or, if one really needs > routes, one must construct the network configuration carefully and then it > becomes less than optimal for classless systems. I'm not sure what to suggest about the static routes option. I know that some companies *try* to make use of it, but I don't think anybody is _really_ making use of it, and I can't see any reason why anybody would implement a client that tried to use both. I guess it might not be a bad idea to explicitly forbid it - that hadn't occurred to me. _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Jun 21 18:54:22 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14360 for ; Wed, 21 Jun 2000 18:54:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5LMpXW00193; Wed, 21 Jun 2000 18:51:33 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5LMpOW19677 for ; Wed, 21 Jun 2000 18:51:24 -0400 (EDT) Received: by LESPAUL with Internet Mail Service (5.5.2650.21) id ; Wed, 21 Jun 2000 18:51:08 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBE43@LESPAUL> From: Bernie Volz To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: RE: draft-ietf-dhc-csr-02.txt Date: Wed, 21 Jun 2000 18:51:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Volz@ipworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ted: OK ... I feel a lot better now that it is the Router Option (3) and not the Static Route Option. Sorry for the confusion but I guess it shows that the draft could use some fine tuning. And, it does raise the question about what to do with the Static Route option. My recommendations regarding the draft: - Fix references to Router Option and specify the option code (3) to assure clarity. - We can debate this, but I think it best to leave default routes in the Router Option and, as the Static Route Option (33) does, disallow default routes in the CSR option. I think it is cleaner and less likely to lead to configuration errors or problems (after all, that's what you're trying to do). Put a piece of data in only one place is usually a good rule. - Regarding the Static Route Option, I'd suggest: - If a client receives a Static Route Option (33) and a CSR option (and it supports both), it MUST ignore the Static Route Option and install the CSR option routes. - If a server receives a parameter list request from a client for both the Static Route Option and the CSR option and it has configuration information for both, it SHOULD only send the CSR option (to conserve packet space). - Bernie Volz IPWorks, Inc. -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, June 21, 2000 6:39 PM To: Bernie Volz Cc: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-csr-02.txt > When, in the draft, you say "Routers option", are you referring to "Router > option" (code 3) or the "Static Route option" (code 33)? There technically > is no "Routers option" in RFC 2132. I guess the CSR draft should be clear > about which option it is speaking of (giving the code numbers wouldn't hurt > for clarity). Oops. I was referring to the router option. I thought it was plural. Sorry about that. > If you're talking about the "Router option" (code 3), then I certainly have > no problems in applying those as the default routers to whatever is received > with the CSR. Okay, sounds like we actually agree, then. > However, the Static Route option (33) explicitly forbids the default > route. Yet, CSR allows it. And, why not just use the Router option > for default routes? Right. I don't know why the Static Route option explicitly forbids the default route, but it makes a certain amount of sense, anyway... :'} > In a classless environment, the Static Route option (33) either becomes > useless and one is forced to using default routes; or, if one really needs > routes, one must construct the network configuration carefully and then it > becomes less than optimal for classless systems. I'm not sure what to suggest about the static routes option. I know that some companies *try* to make use of it, but I don't think anybody is _really_ making use of it, and I can't see any reason why anybody would implement a client that tried to use both. I guess it might not be a bad idea to explicitly forbid it - that hadn't occurred to me. _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Jun 21 19:11:34 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14634 for ; Wed, 21 Jun 2000 19:11:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5LNAvW28934; Wed, 21 Jun 2000 19:10:57 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5LNAtW24124 for ; Wed, 21 Jun 2000 19:10:55 -0400 (EDT) Received: from grosse.bisbee.fugue.com (a28.pm3-30.theriver.com [206.102.195.140]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id AAA23483; Wed, 21 Jun 2000 00:30:56 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id QAA00636; Wed, 21 Jun 2000 16:11:10 -0700 (MST) Message-Id: <200006212311.QAA00636@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-csr-02.txt In-Reply-To: Message from Bernie Volz of "Wed, 21 Jun 2000 18:51:07 -0400." <63D30D6E10CFD11190A90000F805FE8602BEBE43@LESPAUL> Date: Wed, 21 Jun 2000 16:11:10 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > - We can debate this, but I think it best to leave default routes in the > Router Option and, as the Static Route Option (33) does, disallow default > routes in the CSR option. I think it is cleaner and less likely to lead to > configuration errors or problems (after all, that's what you're trying to > do). Put a piece of data in only one place is usually a good rule. I don't want to specifically disallow putting static routes in the CSR option because it places an unnecessary requirement on the server. Given how unlikely it is that anybody would use the old static routes option in this day and age, I think that simply stating it as an operational requirement is sufficient. > - If a client receives a Static Route Option (33) and a CSR option > (and it supports both), it MUST ignore the Static Route Option and install > the CSR option routes. I think we should just say that no client that implements the CSR option should implement the SR option. Can you see any advantage to a client that supports both? > - If a server receives a parameter list request from a client for > both the Static Route Option and the CSR option and it has configuration > information for both, it SHOULD only send the CSR option (to conserve packet > space). I would strongly resist placing this sort of restriction on the server. In general, right now, there are only a few options that DHCP servers need to treat specially in terms of how they're handled in the parameter request list. Adding this requirement would be a significant burden on implementors, and I don't think it would add value. So what I would suggest, based on your message, is that we do as you say and explicitly mention the router option code as well as making it singular, not plural. In addition, I would suggest that we add the requirement that any client that implements the CSR option MUST ignore the SR option if received, and MUST NOT request the SR option. _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Jun 21 19:28:23 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14836 for ; Wed, 21 Jun 2000 19:28:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5LNPkW30375; Wed, 21 Jun 2000 19:25:46 -0400 (EDT) Received: from Arachnid.NTRG.com ([209.31.7.46]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5LNPZW22073 for ; Wed, 21 Jun 2000 19:25:35 -0400 (EDT) Received: from ehsco.com (nat-external.ehsco.com [209.31.7.42]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 633; Wed, 21 Jun 2000 16:25:32 -0700 Message-ID: <39514EEC.4936BCB2@ehsco.com> Date: Wed, 21 Jun 2000 16:25:32 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list CC: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-csr-02.txt References: <200006212311.QAA00636@grosse.bisbee.fugue.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: ehall@ehsco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > I think we should just say that no client that implements the CSR > option should implement the SR option. Can you see any advantage to > a client that supports both? I can't see any disadvantages from supporting both, since the code for maintaining either will still have to be there. If a client asks for both and gets one or the other, what's the difference if it gets both? It should still be able to deal with both kinds of routes, passing them to the stack as net/mask pairs (or whatever) in either case. What end-user benefit is there in saying "clients MUST not do both" other than to simplify the code for client programmers a very wee bit? If that's not the goal, maybe just deprecating 33 is the best thing to do. Since the predominate client(s) don't support 33 that's no loss to most of the end-users. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-dhcp-v4@bucknell.edu Wed Jun 21 19:36:45 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14932 for ; Wed, 21 Jun 2000 19:36:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5LNZwW18054; Wed, 21 Jun 2000 19:35:58 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5LNZpW03097 for ; Wed, 21 Jun 2000 19:35:51 -0400 (EDT) Received: from grosse.bisbee.fugue.com (a28.pm3-30.theriver.com [206.102.195.140]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id AAA23537; Wed, 21 Jun 2000 00:55:52 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id QAA00924; Wed, 21 Jun 2000 16:35:58 -0700 (MST) Message-Id: <200006212335.QAA00924@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-csr-02.txt In-Reply-To: Message from "Eric A. Hall" of "Wed, 21 Jun 2000 16:25:32 MST." <39514EEC.4936BCB2@ehsco.com> Date: Wed, 21 Jun 2000 16:35:58 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > If that's not the goal, maybe just deprecating 33 is the best thing to > do. Since the predominate client(s) don't support 33 that's no loss to > most of the end-users. This is precisely the point, and this is what the proposed language effectively does. Classed routes effectively don't exist anymore. If you happen to have them, they can easily be supported by the CSR option - you just have to include a netmask. So there's no benefit to the end user of the DHCP client in having the DHCP client support both options. You could say that there might be some benefit to some server administrator. But in practice it seems unlikely that there would be any such benefit - usually when we hear about option 33, it's somebody asking how you specify the netmask, and then giving up once they confirm that you can't. So the number of server administrators that would be required to upgrade in order to provide similar functionality to new clients on an existing network where option 33 is being used seems likely to be quite small, and I wouldn't want to use them as a justification for requiring extra complexity in the client. _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Jun 21 19:44:21 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14981 for ; Wed, 21 Jun 2000 19:44:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5LNhlW26296; Wed, 21 Jun 2000 19:43:47 -0400 (EDT) Received: from Arachnid.NTRG.com ([209.31.7.46]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5LNheW31641 for ; Wed, 21 Jun 2000 19:43:40 -0400 (EDT) Received: from ehsco.com (nat-external.ehsco.com [209.31.7.42]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 576; Wed, 21 Jun 2000 16:43:37 -0700 Message-ID: <39515328.920F90B2@ehsco.com> Date: Wed, 21 Jun 2000 16:43:36 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list CC: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-csr-02.txt References: <200006212335.QAA00924@grosse.bisbee.fugue.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: ehall@ehsco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > > If that's not the goal, maybe just deprecating 33 is the best thing > > to do. Since the predominate client(s) don't support 33 that's no > > loss to most of the end-users. > > This is precisely the point, and this is what the proposed language > effectively does. It should state it explicitly if the justification can withstand debate. If it cannot, then both of them should continue to be supported. At the very least, support for both would at least allow admins with complex networks and 33-capable clients to transition from one to the other. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-dhcp-v4@bucknell.edu Wed Jun 21 20:21:19 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15488 for ; Wed, 21 Jun 2000 20:21:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5M0ITW29583; Wed, 21 Jun 2000 20:18:29 -0400 (EDT) Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5M0IEW18631 for ; Wed, 21 Jun 2000 20:18:14 -0400 (EDT) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id RAA00885; Wed, 21 Jun 2000 17:18:09 -0700 (PDT) Received: by internaut.com (NX5.67e/NeXT-3.0) id AA01749; Wed, 21 Jun 00 16:42:12 -0800 Date: Wed, 21 Jun 2000 16:42:09 -0800 (GMT-0800) From: "Bernard D. Aboba" To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: Re: WG last call for "Authentication for DHCP Messages" In-Reply-To: <3950F129.D1D8DE97@metaip.checkpoint.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: aboba@internaut.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I have some general comments on the draft. The Key Management Technique presented in Appendix A results in all DHCP clients knowing the master key (MK). Thus any DHCP client can impersonate any other DHCP client. I do not feel that this technique provides much protection other than avoidance of accidentally configured rogue DHCP servers. Having encountered other standards (e.g. 802.11 WEP) that used this global key model, I have to say that it is quite unwieldy to deploy. For example, if any DHCP client were to be compromised, all clients would need to obtain a new master key. No mechanism is described in the draft for how this would be accomplished. Even assuming that the technique in Appendix A is not used, I have difficulty imagining the deployment model for the authentication techniques described in this draft. For example, while it is conceivable that a DHCP server might locally hold a list of client identifiers and corresponding shared secrets, for an organization with many DHCP servers, this would be awkward. As a result, a more likely model would be that a centralized authentication server would be used. However, since the draft requires the DHCP server to sign and verify DHCP messages, if the DHCP server does not have access to cleartext secrets, it will typically be necessary to ship a received DHCP packet off to the authentication server for verification. In addition, the proposed response would need to be composed and sent off to the authentication server as well, so that the authentication server could compute the MAC. This requires the authentication server to have knowledge of DHCP, which is typically not the case. A similar approach was taken with Mobile IP (RFC 2002), and failed to garner significant deployment. As a result, challenge-response approach is now being proposed, which does not require a centralized authentication server to have knowledge of Mobile IP. I recommend that the DHC WG consider addition of a technique that works along the same lines. > > Please forward any comments you may have on this draft to > > dhcp-v4@bucknell.edu by Friday, June 23. > > > > - Ralph Droms > > From owner-dhcp-v4@bucknell.edu Wed Jun 21 21:00:09 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15815 for ; Wed, 21 Jun 2000 21:00:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5M0vZW03240; Wed, 21 Jun 2000 20:57:35 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5M0vUW00653 for ; Wed, 21 Jun 2000 20:57:30 -0400 (EDT) Received: from grosse.bisbee.fugue.com (a28.pm3-30.theriver.com [206.102.195.140]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id CAA23719 for ; Wed, 21 Jun 2000 02:17:32 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id RAA01523 for ; Wed, 21 Jun 2000 17:57:44 -0700 (MST) Message-Id: <200006220057.RAA01523@grosse.bisbee.fugue.com> To: DHCPv4 discussion list Subject: Does anybody object to deprecating the static routes option? Date: Wed, 21 Jun 2000 17:57:44 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN The Classless Static Routes option states quite explicitly that Option 33, the Static Routes option, is obsolete, but does not specifically deprecate it. It has been suggested that this draft formally deprecate the Static Routes option (option 33) for clients that implement the Classless Static Routes option as described in the draft. The implications of this are that as new clients that implement the CSR option are deployed, sites that are currently using the Static Routes option, option 33, would have to upgrade to DHCP servers that support the Classless Static Routes option in addition to the Static Routes option. In order to configure a server to support both options, it is likely that some duplicate configuration information would have to be entered. Does anybody see this as a problem? _MelloN_ From owner-dhcp-v4@bucknell.edu Thu Jun 22 13:34:39 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11188 for ; Thu, 22 Jun 2000 13:34:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5MHRbW07985; Thu, 22 Jun 2000 13:27:37 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5MHRWW10968 for ; Thu, 22 Jun 2000 13:27:32 -0400 (EDT) Received: by LESPAUL with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 13:27:17 -0400 Received: by LESPAUL with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 11:37:21 -0400 Received: by LESPAUL with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 11:36:24 -0400 Received: by LESPAUL with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 10:19:37 -0400 Received: by LESPAUL with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 09:54:47 -0400 Received: by LESPAUL with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 09:37:08 -0400 Received: by LESPAUL with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 09:36:11 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBE44@LESPAUL> From: Bernie Volz To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: RE: draft-ietf-dhc-csr-02.txt Date: Thu, 22 Jun 2000 09:36:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Volz@ipworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ted: >I don't want to specifically disallow putting static routes in the CSR >option because it places an unnecessary requirement on the server. >Given how unlikely it is that anybody would use the old static routes >option in this day and age, I think that simply stating it as an >operational requirement is sufficient. I think disallowing and forcing use of the existing option for this purpose is best. It avoids misconfiguration errors. Question: Why was it not allowed in the Static Route Option? Perhaps because it wasted 4-bytes per route, but perhaps also they didn't want the same piece of information to be configured two different ways. >I think we should just say that no client that implements the CSR >option should implement the SR option. Can you see any advantage to >a client that supports both? No you can't do this. The client has NO idea what the server supports. So, the only thing the client can do is request both and hope that the server supports CSR and sends that back. So, a client must implement both options. >I would strongly resist placing this sort of restriction on the >server. In general, right now, there are only a few options that >DHCP servers need to treat specially in terms of how they're handled >in the parameter request list. Adding this requirement would be a >significant burden on implementors, and I don't think it would add >value. It is a SHOULD or MAY. It is not a requirement as the client will process only the CSR option anyway. It is just that I'd like a statement that says a server MAY (or SHOULD) not send both as that means the packet doesn't contain useless data - any savings in bytes may be desireable under certain cases (such as with restricted MTU sizes, etc). -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, June 21, 2000 7:11 PM To: Bernie Volz Cc: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-csr-02.txt > - We can debate this, but I think it best to leave default routes in the > Router Option and, as the Static Route Option (33) does, disallow default > routes in the CSR option. I think it is cleaner and less likely to lead to > configuration errors or problems (after all, that's what you're trying to > do). Put a piece of data in only one place is usually a good rule. I don't want to specifically disallow putting static routes in the CSR option because it places an unnecessary requirement on the server. Given how unlikely it is that anybody would use the old static routes option in this day and age, I think that simply stating it as an operational requirement is sufficient. > - If a client receives a Static Route Option (33) and a CSR option > (and it supports both), it MUST ignore the Static Route Option and install > the CSR option routes. I think we should just say that no client that implements the CSR option should implement the SR option. Can you see any advantage to a client that supports both? > - If a server receives a parameter list request from a client for > both the Static Route Option and the CSR option and it has configuration > information for both, it SHOULD only send the CSR option (to conserve packet > space). I would strongly resist placing this sort of restriction on the server. In general, right now, there are only a few options that DHCP servers need to treat specially in terms of how they're handled in the parameter request list. Adding this requirement would be a significant burden on implementors, and I don't think it would add value. So what I would suggest, based on your message, is that we do as you say and explicitly mention the router option code as well as making it singular, not plural. In addition, I would suggest that we add the requirement that any client that implements the CSR option MUST ignore the SR option if received, and MUST NOT request the SR option. _MelloN_ From owner-dhcp-v4@bucknell.edu Thu Jun 22 13:34:43 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11199 for ; Thu, 22 Jun 2000 13:34:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5MHWiW08073; Thu, 22 Jun 2000 13:32:44 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5MHRfW07882 for ; Thu, 22 Jun 2000 13:27:41 -0400 (EDT) Received: by LESPAUL with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 13:27:25 -0400 Received: by LESPAUL with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 11:37:32 -0400 Received: by LESPAUL with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 11:36:41 -0400 Received: by LESPAUL with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 11:06:31 -0400 Received: by LESPAUL with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 09:41:00 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBE46@LESPAUL> From: Bernie Volz To: DHCPv4 discussion list Subject: RE: draft-ietf-dhc-csr-02.txt Date: Thu, 22 Jun 2000 09:40:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Volz@ipworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I have no problem if we were to deprecate option 33. However, there will likely always be clients that continue to support just it (at least for a while). And, while those clients exist and if SOME routing information must be given to them (other than default routes), then all you may have is Option 33. Also, when new clients that support CSR are released, servers may not yet be configured with this new option data and thus these clients may need to continue to use option 33 for "limited" routing information. So co-existance is necessary. - Bernie -----Original Message----- From: Eric A. Hall [mailto:ehall@ehsco.com] Sent: Wednesday, June 21, 2000 7:44 PM To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-csr-02.txt > > If that's not the goal, maybe just deprecating 33 is the best thing > > to do. Since the predominate client(s) don't support 33 that's no > > loss to most of the end-users. > > This is precisely the point, and this is what the proposed language > effectively does. It should state it explicitly if the justification can withstand debate. If it cannot, then both of them should continue to be supported. At the very least, support for both would at least allow admins with complex networks and 33-capable clients to transition from one to the other. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-dhcp-v4@bucknell.edu Thu Jun 22 13:39:11 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11315 for ; Thu, 22 Jun 2000 13:39:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5MHb6W14115; Thu, 22 Jun 2000 13:37:06 -0400 (EDT) Received: from codex.cis.upenn.edu (CODEX.CIS.UPENN.EDU [158.130.6.15]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5MHb5W02713 for ; Thu, 22 Jun 2000 13:37:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by codex.cis.upenn.edu (8.9.3/8.9.3) with ESMTP id NAA24082; Thu, 22 Jun 2000 13:36:55 -0400 (EDT) Date: Thu, 22 Jun 2000 13:36:55 -0400 (EDT) From: "William A. Arbaugh" To: DHCPv4 discussion list cc: DHCPv4 discussion list , waa@cs.umd.edu Subject: Re: WG last call for "Authentication for DHCP Messages" In-Reply-To: <3950F129.D1D8DE97@metaip.checkpoint.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: waa@dsl.cis.upenn.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN On Wed, 21 Jun 2000, Richard Jones wrote: > Some questions about the draft: > > In the first format diagram (Section 2) there are two fields labelled > 'Algorithm'. Should the second one be RDM, or do I misunderstand? > The second one should be RDM. > The last paragraph of Section 5.2 (Format) states that the authentication > request can only appear in a DHCPDISCOVER message, while section > 5.5.5 (DHCPINFORM) suggests that the client SHOULD use the request > in that message type. I'm fine with using it in both messages, but > wonder if the wording of section 5.2 should be changed to avoid > confusion. > Agreed. > In the second paragraph of Section 5.6.4, the implication seems to be > that if a server doesn't have a shared secret value with a client sending > a DHCPINFORM with authentication request, it needs to either ACK or > NAK the message. But ignoring the message seems like a valid option > too. Perhaps this is too obvious, but I thought it would be good for > the sake of clarity to state it. > Fine with me- although I usually like to have some kind of feedback. > Editorial stuff: > > Section 5, sentence 2, you might want to remove the second 'information'. > Section 5.3, sentence 2, should start "Next the receiver..."? > Thanks. Thanks for the good comments and thorough review! Bill From owner-dhcp-v4@bucknell.edu Thu Jun 22 13:49:27 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11590 for ; Thu, 22 Jun 2000 13:49:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5MHlJW16294; Thu, 22 Jun 2000 13:47:19 -0400 (EDT) Received: from dtctxexch9.ins.com ([208.164.93.33]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5MHl0W14630 for ; Thu, 22 Jun 2000 13:47:04 -0400 (EDT) Received: from ragan-c (svl-as5300-dyn-32.ins.com [207.12.157.32]) by dtctxexch9.ins.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NKD661M0; Thu, 22 Jun 2000 12:46:57 -0500 Message-Id: <4.1.20000622105131.00c2da20@pop9.ins.com> X-Sender: ragan_c@pop9.ins.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 22 Jun 2000 10:51:35 -0700 To: DHCPv4 discussion list From: Charles Ragan Subject: RE: draft-ietf-dhc-csr-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: charles_ragan@ins.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi, Are these messages archived somewhere....? I'm joining in a bit late and I want to see what the reasoning is for additional routes in the clients. I've considered the following: 1-same physical network, same logical- would still use the default gateway - probable icmp redirect to 'other' routing host on physical net (router being 'more knowing') 2-same physical network, different logical - default gateway does NOT participate in the second logical (i.e. secondary addressing)...I could see the use here, but would entire dhcp scope carry route information for this 'other' logical subnet? 3-if the dhcp scope became a 'more' focal point for modifiying routes, based on the typical environment (i.e. dhcp is owned by a different group than the router jockeys, I could see where routing information mods could cause confusion amongst the two groups.)....where it seems that >90% of the traffic would still traverse a local (more knowing) router anyways.... Sorry for the 'jumping in late'.... Charles At 09:40 AM 06/22/2000 -0400, Bernie Volz wrote: >I have no problem if we were to deprecate option 33. > >However, there will likely always be clients that continue to support just >it (at least for a while). And, while those clients exist and if SOME >routing information must be given to them (other than default routes), then >all you may have is Option 33. > >Also, when new clients that support CSR are released, servers may not yet be >configured with this new option data and thus these clients may need to >continue to use option 33 for "limited" routing information. > >So co-existance is necessary. > >- Bernie > >-----Original Message----- >From: Eric A. Hall [mailto:ehall@ehsco.com] >Sent: Wednesday, June 21, 2000 7:44 PM >To: DHCPv4 discussion list >Cc: DHCPv4 discussion list >Subject: Re: draft-ietf-dhc-csr-02.txt > > > >> > If that's not the goal, maybe just deprecating 33 is the best thing >> > to do. Since the predominate client(s) don't support 33 that's no >> > loss to most of the end-users. >> >> This is precisely the point, and this is what the proposed language >> effectively does. > >It should state it explicitly if the justification can withstand debate. >If it cannot, then both of them should continue to be supported. At the >very least, support for both would at least allow admins with complex >networks and 33-capable clients to transition from one to the other. > >-- >Eric A. Hall http://www.ehsco.com/ >Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ "There is no 'i' in TEAM!" Charles Ragan Principal Consultant NetCare/Lucent Technologies 800-467-1467 Pager 509-546-0899 Fax http://www.lucent.com/netcare From owner-dhcp-v4@bucknell.edu Thu Jun 22 13:59:54 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11725 for ; Thu, 22 Jun 2000 13:59:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5MHvvW13679; Thu, 22 Jun 2000 13:57:58 -0400 (EDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5MHvrW02961 for ; Thu, 22 Jun 2000 13:57:53 -0400 (EDT) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 22 Jun 2000 10:51:54 -0700 (Pacific Daylight Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Thu, 22 Jun 2000 10:51:47 -0700 Message-ID: From: Matthew Williamson To: DHCPv4 discussion list Subject: RE: draft-ietf-dhc-csr-02.txt Date: Thu, 22 Jun 2000 10:51:42 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Reply-To: mattwi@microsoft.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Charles, Think about it in the situation of Split tunnel scenarios. It's a lot more efficient to route only company related material into the Intranet you're logging in to, and send internet bound traffic directly to the ISP instead of going through the tunnel. Just one feature that I'm hearing a lot of requests for. Thanks, m@ -----Original Message----- From: Charles Ragan [mailto:charles_ragan@INS.COM] Sent: Thursday, June 22, 2000 10:52 AM To: DHCPv4 discussion list Subject: RE: draft-ietf-dhc-csr-02.txt Hi, Are these messages archived somewhere....? I'm joining in a bit late and I want to see what the reasoning is for additional routes in the clients. I've considered the following: 1-same physical network, same logical- would still use the default gateway - probable icmp redirect to 'other' routing host on physical net (router being 'more knowing') 2-same physical network, different logical - default gateway does NOT participate in the second logical (i.e. secondary addressing)...I could see the use here, but would entire dhcp scope carry route information for this 'other' logical subnet? 3-if the dhcp scope became a 'more' focal point for modifiying routes, based on the typical environment (i.e. dhcp is owned by a different group than the router jockeys, I could see where routing information mods could cause confusion amongst the two groups.)....where it seems that >90% of the traffic would still traverse a local (more knowing) router anyways.... Sorry for the 'jumping in late'.... Charles At 09:40 AM 06/22/2000 -0400, Bernie Volz wrote: >I have no problem if we were to deprecate option 33. > >However, there will likely always be clients that continue to support just >it (at least for a while). And, while those clients exist and if SOME >routing information must be given to them (other than default routes), then >all you may have is Option 33. > >Also, when new clients that support CSR are released, servers may not yet be >configured with this new option data and thus these clients may need to >continue to use option 33 for "limited" routing information. > >So co-existance is necessary. > >- Bernie > >-----Original Message----- >From: Eric A. Hall [mailto:ehall@ehsco.com] >Sent: Wednesday, June 21, 2000 7:44 PM >To: DHCPv4 discussion list >Cc: DHCPv4 discussion list >Subject: Re: draft-ietf-dhc-csr-02.txt > > > >> > If that's not the goal, maybe just deprecating 33 is the best thing >> > to do. Since the predominate client(s) don't support 33 that's no >> > loss to most of the end-users. >> >> This is precisely the point, and this is what the proposed language >> effectively does. > >It should state it explicitly if the justification can withstand debate. >If it cannot, then both of them should continue to be supported. At the >very least, support for both would at least allow admins with complex >networks and 33-capable clients to transition from one to the other. > >-- >Eric A. Hall http://www.ehsco.com/ >Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ "There is no 'i' in TEAM!" Charles Ragan Principal Consultant NetCare/Lucent Technologies 800-467-1467 Pager 509-546-0899 Fax http://www.lucent.com/netcare From owner-dhcp-v4@bucknell.edu Thu Jun 22 14:01:38 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11847 for ; Thu, 22 Jun 2000 14:01:37 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5MHxXW05789; Thu, 22 Jun 2000 13:59:33 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5MHxOW03386 for ; Thu, 22 Jun 2000 13:59:24 -0400 (EDT) Received: from grosse.bisbee.fugue.com (a46.pm3-29.theriver.com [206.102.195.110]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id TAA26988; Wed, 21 Jun 2000 19:19:25 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id KAA00765; Thu, 22 Jun 2000 10:59:39 -0700 (MST) Message-Id: <200006221759.KAA00765@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-csr-02.txt In-Reply-To: Message from Bernie Volz of "Thu, 22 Jun 2000 09:40:57 -0400." <63D30D6E10CFD11190A90000F805FE8602BEBE46@LESPAUL> Date: Thu, 22 Jun 2000 10:59:39 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I have no problem if we were to deprecate option 33. > > However, there will likely always be clients that continue to support just > it (at least for a while). And, while those clients exist and if SOME > routing information must be given to them (other than default routes), then > all you may have is Option 33. Right. What I'm suggesting is that we obsolete option 33 *for clients that support CSR*. Servers should still be capable of supporting it, and clients that do not support CSR can continue to use it. Sites that have a mix of CSR-capable and non-CSR-capable clients and that need to send custom routing tables to DHCP clients will have to configure both the SR option and the CSR option into CSR-capable servers. > Also, when new clients that support CSR are released, servers may not yet be > configured with this new option data and thus these clients may need to > continue to use option 33 for "limited" routing information. The ISC DHCP server and the Microsoft DHCP server are both capable of being configured to send raw hex data for an option, and I suspect other servers are as well. So the problem we are potentially causing a site that is using SR and suddenly gets some CSR-capable clients is _very_ small. Adding complexity to the draft to eliminate this potential problem strikes me as a very bad idea. _MelloN_ From owner-dhcp-v4@bucknell.edu Thu Jun 22 14:09:40 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12001 for ; Thu, 22 Jun 2000 14:09:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5MI5dW12126; Thu, 22 Jun 2000 14:05:39 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5MI5PW21129 for ; Thu, 22 Jun 2000 14:05:25 -0400 (EDT) Received: by LESPAUL with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 14:05:10 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBE52@LESPAUL> From: Bernie Volz To: DHCPv4 discussion list Subject: RE: draft-ietf-dhc-csr-02.txt Date: Thu, 22 Jun 2000 14:05:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Volz@ipworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Don't know if they are archived. The existing (RFC 2132) Static Route option only specifies / pairs and therefore has no means to communicate a class-less network. You do ask a good point ... why give the client routing information other than the default route. In general, there is no need to give the client specific routes since it can learn them via ICMP redirects from the default router. However, there are other cases where that is not true. For example, with multiple networks on a single cable, you might want to let the clients know that this is the case (since ICMP redirects aren't really great at communicating this information). BTW: That does raise a good question ... how about allowing the address to be 0.0.0.0 in the CSR option to specify "this network is local to the interface"? - Bernie Volz -----Original Message----- From: Charles Ragan [mailto:charles_ragan@ins.com] Sent: Thursday, June 22, 2000 1:52 PM To: DHCPv4 discussion list Subject: RE: draft-ietf-dhc-csr-02.txt Hi, Are these messages archived somewhere....? I'm joining in a bit late and I want to see what the reasoning is for additional routes in the clients. I've considered the following: 1-same physical network, same logical- would still use the default gateway - probable icmp redirect to 'other' routing host on physical net (router being 'more knowing') 2-same physical network, different logical - default gateway does NOT participate in the second logical (i.e. secondary addressing)...I could see the use here, but would entire dhcp scope carry route information for this 'other' logical subnet? 3-if the dhcp scope became a 'more' focal point for modifiying routes, based on the typical environment (i.e. dhcp is owned by a different group than the router jockeys, I could see where routing information mods could cause confusion amongst the two groups.)....where it seems that >90% of the traffic would still traverse a local (more knowing) router anyways.... Sorry for the 'jumping in late'.... Charles At 09:40 AM 06/22/2000 -0400, Bernie Volz wrote: >I have no problem if we were to deprecate option 33. > >However, there will likely always be clients that continue to support just >it (at least for a while). And, while those clients exist and if SOME >routing information must be given to them (other than default routes), then >all you may have is Option 33. > >Also, when new clients that support CSR are released, servers may not yet be >configured with this new option data and thus these clients may need to >continue to use option 33 for "limited" routing information. > >So co-existance is necessary. > >- Bernie > >-----Original Message----- >From: Eric A. Hall [mailto:ehall@ehsco.com] >Sent: Wednesday, June 21, 2000 7:44 PM >To: DHCPv4 discussion list >Cc: DHCPv4 discussion list >Subject: Re: draft-ietf-dhc-csr-02.txt > > > >> > If that's not the goal, maybe just deprecating 33 is the best thing >> > to do. Since the predominate client(s) don't support 33 that's no >> > loss to most of the end-users. >> >> This is precisely the point, and this is what the proposed language >> effectively does. > >It should state it explicitly if the justification can withstand debate. >If it cannot, then both of them should continue to be supported. At the >very least, support for both would at least allow admins with complex >networks and 33-capable clients to transition from one to the other. > >-- >Eric A. Hall http://www.ehsco.com/ >Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ "There is no 'i' in TEAM!" Charles Ragan Principal Consultant NetCare/Lucent Technologies 800-467-1467 Pager 509-546-0899 Fax http://www.lucent.com/netcare From owner-dhcp-v4@bucknell.edu Thu Jun 22 14:14:56 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12119 for ; Thu, 22 Jun 2000 14:14:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5MICbW17241; Thu, 22 Jun 2000 14:12:37 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5MICMW29472 for ; Thu, 22 Jun 2000 14:12:22 -0400 (EDT) Received: from grosse.bisbee.fugue.com (a46.pm3-29.theriver.com [206.102.195.110]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id TAA27038; Wed, 21 Jun 2000 19:32:24 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id LAA00840; Thu, 22 Jun 2000 11:12:41 -0700 (MST) Message-Id: <200006221812.LAA00840@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-csr-02.txt In-Reply-To: Message from Charles Ragan of "Thu, 22 Jun 2000 10:51:35 MST." <4.1.20000622105131.00c2da20@pop9.ins.com> Date: Thu, 22 Jun 2000 11:12:41 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I'm joining in a bit late and I want to see what the reasoning is for > additional routes in the clients. Because the network administrator wants them, basically. Sometimes a network topology requires more complexity than can be represented with just a default route. This particular point is really moot anyway - we already provide the ability to load a routing table. What we don't provide is the ability to load a routing table with subnet masks. That is what CSR adds. :') _MelloN_ From owner-dhcp-v4@bucknell.edu Thu Jun 22 14:15:30 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12139 for ; Thu, 22 Jun 2000 14:15:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5MIDMW12632; Thu, 22 Jun 2000 14:13:22 -0400 (EDT) Received: from mail-srv1.micron.com (masquerade.micron.com [137.201.242.130]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5MICaW07555 for ; Thu, 22 Jun 2000 14:12:36 -0400 (EDT) Received: from mail-srv1.micron.com (localhost [127.0.0.1]) by mail-srv1.micron.com (8.9.2/8.9.2) with ESMTP id MAA10084 for ; Thu, 22 Jun 2000 12:12:20 -0600 (MDT) Received: from ntexchange01.micron.com (ntexchange01.micron.com [137.201.104.84]) by mail-srv1.micron.com (8.9.2/8.9.2) with ESMTP id MAA10074 for ; Thu, 22 Jun 2000 12:12:19 -0600 (MDT) Received: by ntexchange01.micron.com with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 12:12:19 -0600 Message-ID: <7D533CAFAAE3D21192C80008C7B25C93061801D9@ntexchange11.micron.com> From: sbabu To: DHCPv4 discussion list Subject: RE: draft-ietf-dhc-csr-02.txt Date: Thu, 22 Jun 2000 12:12:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: sbabu@micron.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Any ideas how I can get off this list. I tried unsubscribing from the online forms on www.isc.org and also sent an email to a support email link that showed up on the form (and nobody responded). Thanks, Sharath. -----Original Message----- From: Bernie Volz [mailto:Volz@ipworks.com] Sent: Thursday, June 22, 2000 12:05 PM To: DHCPv4 discussion list Subject: RE: draft-ietf-dhc-csr-02.txt Don't know if they are archived. The existing (RFC 2132) Static Route option only specifies / pairs and therefore has no means to communicate a class-less network. You do ask a good point ... why give the client routing information other than the default route. In general, there is no need to give the client specific routes since it can learn them via ICMP redirects from the default router. However, there are other cases where that is not true. For example, with multiple networks on a single cable, you might want to let the clients know that this is the case (since ICMP redirects aren't really great at communicating this information). BTW: That does raise a good question ... how about allowing the address to be 0.0.0.0 in the CSR option to specify "this network is local to the interface"? - Bernie Volz -----Original Message----- From: Charles Ragan [mailto:charles_ragan@ins.com] Sent: Thursday, June 22, 2000 1:52 PM To: DHCPv4 discussion list Subject: RE: draft-ietf-dhc-csr-02.txt Hi, Are these messages archived somewhere....? I'm joining in a bit late and I want to see what the reasoning is for additional routes in the clients. I've considered the following: 1-same physical network, same logical- would still use the default gateway - probable icmp redirect to 'other' routing host on physical net (router being 'more knowing') 2-same physical network, different logical - default gateway does NOT participate in the second logical (i.e. secondary addressing)...I could see the use here, but would entire dhcp scope carry route information for this 'other' logical subnet? 3-if the dhcp scope became a 'more' focal point for modifiying routes, based on the typical environment (i.e. dhcp is owned by a different group than the router jockeys, I could see where routing information mods could cause confusion amongst the two groups.)....where it seems that >90% of the traffic would still traverse a local (more knowing) router anyways.... Sorry for the 'jumping in late'.... Charles At 09:40 AM 06/22/2000 -0400, Bernie Volz wrote: >I have no problem if we were to deprecate option 33. > >However, there will likely always be clients that continue to support just >it (at least for a while). And, while those clients exist and if SOME >routing information must be given to them (other than default routes), then >all you may have is Option 33. > >Also, when new clients that support CSR are released, servers may not yet be >configured with this new option data and thus these clients may need to >continue to use option 33 for "limited" routing information. > >So co-existance is necessary. > >- Bernie > >-----Original Message----- >From: Eric A. Hall [mailto:ehall@ehsco.com] >Sent: Wednesday, June 21, 2000 7:44 PM >To: DHCPv4 discussion list >Cc: DHCPv4 discussion list >Subject: Re: draft-ietf-dhc-csr-02.txt > > > >> > If that's not the goal, maybe just deprecating 33 is the best thing >> > to do. Since the predominate client(s) don't support 33 that's no >> > loss to most of the end-users. >> >> This is precisely the point, and this is what the proposed language >> effectively does. > >It should state it explicitly if the justification can withstand debate. >If it cannot, then both of them should continue to be supported. At the >very least, support for both would at least allow admins with complex >networks and 33-capable clients to transition from one to the other. > >-- >Eric A. Hall http://www.ehsco.com/ >Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ "There is no 'i' in TEAM!" Charles Ragan Principal Consultant NetCare/Lucent Technologies 800-467-1467 Pager 509-546-0899 Fax http://www.lucent.com/netcare From owner-dhcp-v4@bucknell.edu Thu Jun 22 14:32:11 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12504 for ; Thu, 22 Jun 2000 14:32:11 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5MITdW17408; Thu, 22 Jun 2000 14:29:39 -0400 (EDT) Received: from codex.cis.upenn.edu (CODEX.CIS.UPENN.EDU [158.130.6.15]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5MITPW02886 for ; Thu, 22 Jun 2000 14:29:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by codex.cis.upenn.edu (8.9.3/8.9.3) with ESMTP id OAA24949; Thu, 22 Jun 2000 14:25:34 -0400 (EDT) Date: Thu, 22 Jun 2000 14:25:34 -0400 (EDT) From: "William A. Arbaugh" To: DHCPv4 discussion list cc: DHCPv4 discussion list , waa@cs.umd.edu Subject: Re: WG last call for "Authentication for DHCP Messages" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: waa@dsl.cis.upenn.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > The Key Management Technique presented in Appendix A results > in all DHCP clients knowing the master key (MK). Thus any > DHCP client can impersonate any other DHCP client. I do not > feel that this technique provides much protection other than > avoidance of accidentally configured rogue DHCP servers. > I don't agree. Each client is given K, where K = HMAC(MK, client_id). Provided that the size of MK is at least one half of the hash functions size, then the strength of the system relies on the either brute force on MK, or a birthday attack on the hash function. Provided |MK|>=|H()|/2, the best an attacker can do is 2**|H()|. With SHA1 at 160bits and MD5 at 128bits, that gives a strength of 2**80 for SHA1 and 2**64 for MD5. To summarize: If I've missed something, please let me know. > Having encountered other standards (e.g. 802.11 WEP) that > used this global key model, I have to say that it is quite > unwieldy to deploy. For example, if any DHCP client were > to be compromised, all clients would need to obtain a new > master key. No mechanism is described in the draft for how > this would be accomplished. > Agreed. Effective key management is always a pain in the tush. .... > A similar approach was taken with Mobile IP (RFC 2002), and > failed to garner significant deployment. As a result, > challenge-response approach is now being proposed, which > does not require a centralized authentication server to > have knowledge of Mobile IP. I recommend that the DHC > WG consider addition of a technique that works along > the same lines. > Please remember that the goal of the draft was to create a template that could be used to define any number of authentication approaches (without changing the underlying DHCP protocol), and I think we have achieved that since there are PKI and Kerberos approaches proposed using the draft. Can the Mobile IP approach be specified in a new draft? Bill From owner-dhcp-v4@bucknell.edu Thu Jun 22 14:52:56 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12974 for ; Thu, 22 Jun 2000 14:52:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5MImfW18140; Thu, 22 Jun 2000 14:48:41 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5MImRW20097 for ; Thu, 22 Jun 2000 14:48:27 -0400 (EDT) Received: from grosse.bisbee.fugue.com (a46.pm3-29.theriver.com [206.102.195.110]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id UAA27204; Wed, 21 Jun 2000 20:08:29 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id LAA01012; Thu, 22 Jun 2000 11:48:46 -0700 (MST) Message-Id: <200006221848.LAA01012@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-csr-02.txt In-Reply-To: Message from sbabu of "Thu, 22 Jun 2000 12:12:17 CST." <7D533CAFAAE3D21192C80008C7B25C93061801D9@ntexchange11.micron.com> Date: Thu, 22 Jun 2000 11:48:46 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN You have to send mail to listproc@bucknell.edu with "help" in the message, and it'll tell you what to do. The dhcp-v4 mailing list has nothing to do with the ISC mailing lists. _MelloN_ From owner-dhcp-v4@bucknell.edu Thu Jun 22 17:05:30 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15616 for ; Thu, 22 Jun 2000 17:05:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5ML2RW13874; Thu, 22 Jun 2000 17:02:27 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5ML2KW15421 for ; Thu, 22 Jun 2000 17:02:20 -0400 (EDT) Received: by LESPAUL with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 17:02:05 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBE5F@LESPAUL> From: Bernie Volz To: DHCPv4 discussion list Subject: Quick Poll - RE: draft-ietf-dhc-csr-02.txt - Allow router to be 0 .0.0.0? Date: Thu, 22 Jun 2000 17:02:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Volz@ipworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Folks: I have suggested to Ted that he consider adding text to Classless Static Routing (CSR) draft to allow the router IP address to be 0.0.0.0 for some routes. If the router IP address is 0.0.0.0, the client (if it supports it) should install a route such that the destination is directly reachable on the interface being configured. The concept behind this is that it easily allows for probably one of the most useful proposes of routing information to be given to clients in the first place. That of supporting multiple subnets on the same physical wire. This is often a difficult issue since there is no standard (at least to my knowledge) for ICMP Redirects to communicate this. If a client does not support the concept of such routes, it would ignore that particular route. Ted is somewhat cautious about adding this text as there is no precedent for it anywhere else yet and he (as I) would like to see the CSR draft go to the IESG as soon as possible. So, how do people feel about this? - Do you feel it is worth adding it? - Do you fear it would delay the draft? - Do you think it is a bad idea in the first place? Thanks for your prompt attention. - Bernie Volz IPWorks, Inc. From owner-dhcp-v4@bucknell.edu Thu Jun 22 17:41:45 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16190 for ; Thu, 22 Jun 2000 17:41:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5MLcGW06961; Thu, 22 Jun 2000 17:38:16 -0400 (EDT) Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5MLc5W16626 for ; Thu, 22 Jun 2000 17:38:05 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (pm3mi2-23.uplink.net [209.173.86.72]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id RAA02600; Thu, 22 Jun 2000 17:38:02 -0400 (EDT) Message-Id: <4.3.1.2.20000622173406.00b346a0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 22 Jun 2000 17:34:18 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Re: router configuration In-Reply-To: <20000621205258.21049.qmail@web904.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 01:52 PM 6/21/00 -0700, jie weng wrote: >In RFC (2131) section 1.3, it states >that "DHCP is not intended for use in configuring >routers." My question is can DHCP be used for router >configuration and if not why? We (I think I might be responsible, but who can remember that far back?) put that text in to explicitly limit the scope of the original development work on DHCP. So, the protocol police won't come knocking at your hub ("Put down that DHCPDISCOVER packet and step away from the LAN segment, please.") if you happen to send a DHCP packet to a router. Just don't count on DHCP to auto-architect your internet and configure your routers for you... - Ralph From owner-dhcp-v4@bucknell.edu Thu Jun 22 17:41:53 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16202 for ; Thu, 22 Jun 2000 17:41:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5MLbkW15981; Thu, 22 Jun 2000 17:37:46 -0400 (EDT) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5MLbiW10022 for ; Thu, 22 Jun 2000 17:37:44 -0400 (EDT) Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id OAA04759; Thu, 22 Jun 2000 14:37:25 -0700 (PDT) Message-Id: <4.1.20000622173414.00b87d70@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 22 Jun 2000 17:37:09 -0400 To: DHCPv4 discussion list From: John Schnizlein Subject: Re: Quick Poll - RE: draft-ietf-dhc-csr-02.txt - Allow router to be 0.0.0.0? In-Reply-To: <63D30D6E10CFD11190A90000F805FE8602BEBE5F@LESPAUL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: jschnizl@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 05:02 PM 06/22/2000 -0400, Bernie Volz wrote: >... If the router IP address is 0.0.0.0, the client (if it supports it) >should install a route such that the destination is directly reachable >on the interface being configured. You mean the host would ARP for the destination even though this host does not have an IP address on that subnet? If the host has an IP address on each subnet it is on (even if through the same interface) wouldn't it use its local routing function (not forwarding) to do the right thing on directly-attached subnets? John From owner-dhcp-v4@bucknell.edu Thu Jun 22 17:47:59 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16319 for ; Thu, 22 Jun 2000 17:47:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5MLl6W06747; Thu, 22 Jun 2000 17:47:06 -0400 (EDT) Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5MLl3W29481 for ; Thu, 22 Jun 2000 17:47:03 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (pm3mi2-23.uplink.net [209.173.86.72]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id RAA02621; Thu, 22 Jun 2000 17:47:00 -0400 (EDT) Message-Id: <4.3.1.2.20000622174822.00b3a730@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 22 Jun 2000 17:49:07 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: RE: draft-ietf-dhc-csr-02.txt In-Reply-To: <63D30D6E10CFD11190A90000F805FE8602BEBE52@LESPAUL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 02:05 PM 6/22/00 -0400, Bernie Volz wrote: >Don't know if they are archived. http://www.listproc.bucknell.edu/cgi-bin/archdex?list=dhcp-v4 From owner-dhcp-v4@bucknell.edu Thu Jun 22 17:49:07 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16343 for ; Thu, 22 Jun 2000 17:49:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5MLmUW17956; Thu, 22 Jun 2000 17:48:30 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5MLmMW31104 for ; Thu, 22 Jun 2000 17:48:22 -0400 (EDT) Received: by LESPAUL with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 17:48:07 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBE63@LESPAUL> From: Bernie Volz To: DHCPv4 discussion list Subject: RE: Quick Poll - RE: draft-ietf-dhc-csr-02.txt - Allow router to be 0.0.0.0? Date: Thu, 22 Jun 2000 17:48:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Volz@ipworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >You mean the host would ARP for the destination even though this host >does not have an IP address on that subnet? Correct. >If the host has an IP address on each subnet it is on (even if through >the same interface) wouldn't it use its local routing function (not >forwarding) to do the right thing on directly-attached subnets? That's a different case. And, it probably not as typical as the other case (where there are multiple physical subnets on a single wire and each host generally only has one address on that wire). - Bernie Volz IPWorks, Inc. -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com] Sent: Thursday, June 22, 2000 5:37 PM To: Volz@ipworks.com; DHCPv4 discussion list Subject: Re: Quick Poll - RE: draft-ietf-dhc-csr-02.txt - Allow router to be 0.0.0.0? At 05:02 PM 06/22/2000 -0400, Bernie Volz wrote: >... If the router IP address is 0.0.0.0, the client (if it supports it) >should install a route such that the destination is directly reachable >on the interface being configured. You mean the host would ARP for the destination even though this host does not have an IP address on that subnet? If the host has an IP address on each subnet it is on (even if through the same interface) wouldn't it use its local routing function (not forwarding) to do the right thing on directly-attached subnets? John From owner-dhcp-v4@bucknell.edu Thu Jun 22 17:55:31 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16384 for ; Thu, 22 Jun 2000 17:55:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5MLsvW17389; Thu, 22 Jun 2000 17:54:57 -0400 (EDT) Received: from postal.metaip.checkpoint.com (metaip.checkpoint.com [204.29.28.25]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5MLssW27068 for ; Thu, 22 Jun 2000 17:54:55 -0400 (EDT) Received: from cartman.metainfo.com (cartman.metainfo.com [204.29.28.145]) by postal.metaip.checkpoint.com (8.9.3/8.9.3VRJ666) with ESMTP id OAA21046; Fri, 23 Jun 2000 14:51:52 -0700 Received: by cartman.metainfo.com with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 14:48:40 -0700 Message-ID: From: richardj@metaip.checkpoint.com To: DHCPv4 discussion list Subject: RE: Quick Poll - RE: draft-ietf-dhc-csr-02.txt - Allow router to be 0 .0.0.0? Date: Thu, 22 Jun 2000 14:48:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: richardj@metaip.checkpoint.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I don't think it's a bad idea at all, but I share the reservations about putting it into this draft. It feels like a substantial blurring of the DHCP protocol boundary, and I think it might well delay the acceptance of the draft. For that reason, I'd vote for leaving it out and trying in a separate effort to institute this. Regards, Richard Jones Check Point Software, Inc. -----Original Message----- From: Bernie Volz [SMTP:Volz@ipworks.com] Sent: Thursday, June 22, 2000 2:02 PM To: DHCPv4 discussion list Subject: Quick Poll - RE: draft-ietf-dhc-csr-02.txt - Allow router to be 0 .0.0.0? Folks: I have suggested to Ted that he consider adding text to Classless Static Routing (CSR) draft to allow the router IP address to be 0.0.0.0 for some routes. If the router IP address is 0.0.0.0, the client (if it supports it) should install a route such that the destination is directly reachable on the interface being configured. The concept behind this is that it easily allows for probably one of the most useful proposes of routing information to be given to clients in the first place. That of supporting multiple subnets on the same physical wire. This is often a difficult issue since there is no standard (at least to my knowledge) for ICMP Redirects to communicate this. If a client does not support the concept of such routes, it would ignore that particular route. Ted is somewhat cautious about adding this text as there is no precedent for it anywhere else yet and he (as I) would like to see the CSR draft go to the IESG as soon as possible. So, how do people feel about this? - Do you feel it is worth adding it? - Do you fear it would delay the draft? - Do you think it is a bad idea in the first place? Thanks for your prompt attention. - Bernie Volz IPWorks, Inc. From owner-dhcp-v4@bucknell.edu Thu Jun 22 18:00:08 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16442 for ; Thu, 22 Jun 2000 18:00:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5MLxbW03614; Thu, 22 Jun 2000 17:59:37 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5MLxZW04345 for ; Thu, 22 Jun 2000 17:59:36 -0400 (EDT) Received: from grosse.bisbee.fugue.com (a46.pm3-29.theriver.com [206.102.195.110]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id XAA27780; Wed, 21 Jun 2000 23:19:37 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id OAA01703; Thu, 22 Jun 2000 14:59:54 -0700 (MST) Message-Id: <200006222159.OAA01703@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Quick Poll - RE: draft-ietf-dhc-csr-02.txt - Allow router to be 0.0.0.0? In-Reply-To: Message from John Schnizlein of "Thu, 22 Jun 2000 17:37:09 -0400." <4.1.20000622173414.00b87d70@diablo.cisco.com> Date: Thu, 22 Jun 2000 14:59:54 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > If the host has an IP address on each subnet it is on (even if through > the same interface) wouldn't it use its local routing function (not > forwarding) to do the right thing on directly-attached subnets? The point is to be able to support more than one subnet on the wire without requiring hosts on the same wire to send packets to other hosts on the same wire through a router. DHCP doesn't provide a standard way to give a client more than one IP address per network interface, nor would you want to. So you can't really use the usual routing mechanism. What this is is a limited form of the proxy arp feature in Windows, where if you give a windows machine its own IP address as a default route, it ARPs for every IP address it tries to contact, whether or not that IP address is on its local subnet. _MelloN_ From owner-dhcp-v4@bucknell.edu Thu Jun 22 18:15:58 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16644 for ; Thu, 22 Jun 2000 18:15:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5MMAsW14057; Thu, 22 Jun 2000 18:10:54 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5MMAgW12549 for ; Thu, 22 Jun 2000 18:10:42 -0400 (EDT) Received: by LESPAUL with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 18:10:26 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBE64@LESPAUL> From: Bernie Volz To: DHCPv4 discussion list Subject: RE: Quick Poll - RE: draft-ietf-dhc-csr-02.txt - Allow router to be 0.0.0.0? Date: Thu, 22 Jun 2000 18:10:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Volz@ipworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN There are also other implementations that support this concept though the exact syntax to add the routes is often different. That's why specifying 0.0.0.0 is desireable. Note that with the CSR option as it is specified today, you COULD do this very easily by simply sending Windows clients the router as their IP address. However, that would mean the DHCP Server needs to generate the CSR option on the fly since it needs to substitute the client's assigned IP address for the router. One reason I'd like the router = 0.0.0.0 convention is that it won't require any special support in the server to do this. I'm sure if we DON'T do this, someone will do it anyway by simply having the server do this. By specifying 0.0.0.0, you set up a standard convention that prevents the need for the server to change the option data and makes it easy for clients to take whatever special action is needed for them to install these routes. - Bernie Volz IPWorks, Inc -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Thursday, June 22, 2000 6:00 PM To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: Re: Quick Poll - RE: draft-ietf-dhc-csr-02.txt - Allow router to be 0.0.0.0? > If the host has an IP address on each subnet it is on (even if through > the same interface) wouldn't it use its local routing function (not > forwarding) to do the right thing on directly-attached subnets? The point is to be able to support more than one subnet on the wire without requiring hosts on the same wire to send packets to other hosts on the same wire through a router. DHCP doesn't provide a standard way to give a client more than one IP address per network interface, nor would you want to. So you can't really use the usual routing mechanism. What this is is a limited form of the proxy arp feature in Windows, where if you give a windows machine its own IP address as a default route, it ARPs for every IP address it tries to contact, whether or not that IP address is on its local subnet. _MelloN_ From owner-dhcp-v4@bucknell.edu Thu Jun 22 20:54:52 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18037 for ; Thu, 22 Jun 2000 20:54:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5N0q6W18350; Thu, 22 Jun 2000 20:52:06 -0400 (EDT) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5N0q5W29624 for ; Thu, 22 Jun 2000 20:52:05 -0400 (EDT) Received: from jschnizl1-pc (rtp-dial-2-68.cisco.com [10.83.96.68]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id RAA08425; Thu, 22 Jun 2000 17:51:46 -0700 (PDT) Message-Id: <4.1.20000622203450.00bb0680@diablo.cisco.com> Message-Id: <4.1.20000622203450.00bb0680@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 22 Jun 2000 20:43:08 -0400 To: DHCPv4 discussion list From: John Schnizlein Subject: RE:... Allow router to be 0.0.0.0? In-Reply-To: <63D30D6E10CFD11190A90000F805FE8602BEBE64@LESPAUL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: jschnizl@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Please persuade me that this will not cause any confusion with the common use of 0.0.0.0 as a default route. It should not imply that the host infer proxy arp for all addresses, following Ted's explanation below. It should permit installing preferred routes through different routers on the directly-attached subnet. John At 06:10 PM 06/22/2000 -0400, Bernie Volz wrote: >... >By specifying 0.0.0.0, you set up a standard convention that >prevents the need for the server to change the option data and >makes it easy for clients to take whatever special action is >needed for them to install these routes. > >From: Ted Lemon [mailto:mellon@nominum.com] >... >What this is is a limited form of the proxy arp feature in Windows, >where if you give a windows machine its own IP address as a default >route, it ARPs for every IP address it tries to contact, whether or >not that IP address is on its local subnet. From owner-dhcp-v4@bucknell.edu Thu Jun 22 21:42:42 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18471 for ; Thu, 22 Jun 2000 21:42:42 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5N1dxW06843; Thu, 22 Jun 2000 21:39:59 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5N1dqW05705 for ; Thu, 22 Jun 2000 21:39:52 -0400 (EDT) Received: by LESPAUL with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 21:39:37 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBE67@LESPAUL> From: Bernie Volz To: DHCPv4 discussion list Subject: RE: ... Allow router to be 0.0.0.0? Date: Thu, 22 Jun 2000 21:39:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Volz@ipworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN John: The 0.0.0.0 as the default route convention is for the DESTINATION, not the ROUTER. We're talking about specifying the ROUTER'S IP ADDRESS as 0.0.0.0. That is, obviously, not a legal address for a router. Thus, there is no other use of that address. A default route, if allowed in CSR (as it is currently), is specified as a 0 subnet mask length. Thus, if you wanted to specify that all addresses should be ARPed for, you might send a CSR option with data as: 00:00:00:00:00. The means 0 subnet bits (hence no subnet number) followed by the 0.0.0.0 router IP address. If you wanted to install a route that say the 10 network is local, you'd use 08:0a:00:00:00:00. 08 for the subnet bits, 0a for the subnet number (10), and 0.0.0.0 for the router. If you wanted to install a routes that say the 10 network is local and for the 11 network use the router at 10.0.0.1, you'd specify: 08:0a:00:00:00:00:08:0b:0a:00:00:01. See the CSR document for encoding information. Hope that helps. - Bernie Volz IPWorks, Inc. -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com] Sent: Thursday, June 22, 2000 8:43 PM To: Volz@ipworks.com; DHCPv4 discussion list Subject: RE:... Allow router to be 0.0.0.0? Please persuade me that this will not cause any confusion with the common use of 0.0.0.0 as a default route. It should not imply that the host infer proxy arp for all addresses, following Ted's explanation below. It should permit installing preferred routes through different routers on the directly-attached subnet. John At 06:10 PM 06/22/2000 -0400, Bernie Volz wrote: >... >By specifying 0.0.0.0, you set up a standard convention that >prevents the need for the server to change the option data and >makes it easy for clients to take whatever special action is >needed for them to install these routes. > >From: Ted Lemon [mailto:mellon@nominum.com] >... >What this is is a limited form of the proxy arp feature in Windows, >where if you give a windows machine its own IP address as a default >route, it ARPs for every IP address it tries to contact, whether or >not that IP address is on its local subnet. From owner-dhcp-v4@bucknell.edu Fri Jun 23 10:34:30 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11636 for ; Fri, 23 Jun 2000 10:34:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5NET1W05889; Fri, 23 Jun 2000 10:29:01 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5NESnW02811 for ; Fri, 23 Jun 2000 10:28:49 -0400 (EDT) Received: by sentry.gw.tislabs.com; id KAA20462; Fri, 23 Jun 2000 10:30:50 -0400 (EDT) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma020457; Fri, 23 Jun 00 10:30:42 -0400 Received: from english.tislabs.com (clipper.gw.tislabs.com [10.33.1.2]) by clipper.gw.tislabs.com (8.10.1/8.10.1) with ESMTP id e5NEQ0m20532; Fri, 23 Jun 2000 10:26:00 -0400 (EDT) Message-Id: <4.3.2.7.2.20000623101659.00c9d920@localhost> X-Sender: ogud@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 23 Jun 2000 10:34:19 -0400 To: DHCPv4 discussion list From: Olafur Gudmundsson Subject: Re: WG last call for "Authentication for DHCP Messages" Cc: DHCPv4 discussion list , waa@cs.umd.edu In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: ogud@tislabs.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 02:25 PM 6/22/00, William A. Arbaugh wrote: > > The Key Management Technique presented in Appendix A results > > in all DHCP clients knowing the master key (MK). Thus any > > DHCP client can impersonate any other DHCP client. I do not > > feel that this technique provides much protection other than > > avoidance of accidentally configured rogue DHCP servers. > > >I don't agree. Each client is given K, where K = HMAC(MK, >client_id). Provided that the size of MK is at least one half of the hash >functions size, then the strength of the system relies on the either brute >force on MK, or a birthday attack on the hash function. Provided >|MK|>=|H()|/2, the best an attacker can do is 2**|H()|. With SHA1 at >160bits and MD5 at 128bits, that gives a strength of 2**80 for SHA1 and >2**64 for MD5. > >To summarize: > >If I've missed something, please let me know. > > > Having encountered other standards (e.g. 802.11 WEP) that > > used this global key model, I have to say that it is quite > > unwieldy to deploy. For example, if any DHCP client were > > to be compromised, all clients would need to obtain a new > > master key. No mechanism is described in the draft for how > > this would be accomplished. > > >Agreed. Effective key management is always a pain in the tush. The key management schema described is weak at least, I think you MUST put in a sentence that says that the Master Key MUST never be stored on clients. Clients MUST only be given their K. IF this is not made clear in the draft I'm sure someone will implement a client requiring MK. As far as I can tell the whole point of this schema is to allow the server to calculate the keys on the fly when it sees a new client. I think this motivation should also be stated more clearly. I think the section should also contain a warning that if MK is compromised all clients must be re keyed. Hopefully someone will propose soon a dynamic key management system for DHCP. Olafur From owner-dhcp-v4@bucknell.edu Fri Jun 23 10:37:25 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11818 for ; Fri, 23 Jun 2000 10:37:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5NEagW13290; Fri, 23 Jun 2000 10:36:42 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5NEaXW06716 for ; Fri, 23 Jun 2000 10:36:34 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA08908; Fri, 23 Jun 2000 07:36:28 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA11990; Fri, 23 Jun 2000 10:36:24 -0400 (EDT) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5NEa8J106860; Fri, 23 Jun 2000 10:36:08 -0400 (EDT) Message-Id: <200006231436.e5NEa8J106860@thunk.east.sun.com> From: Bill Sommerfeld To: DHCPv4 discussion list cc: DHCPv4 discussion list , waa@cs.umd.edu Subject: Re: WG last call for "Authentication for DHCP Messages" In-reply-to: Your message of "Fri, 23 Jun 2000 10:34:19 EDT." <4.3.2.7.2.20000623101659.00c9d920@localhost> Reply-to: sommerfeld@east.sun.com Date: Fri, 23 Jun 2000 10:36:08 -0400 Sender: owner-dhcp-v4@bucknell.edu X-Sender: sommerfeld@thunk.east.sun.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > The key management schema described is weak at least, I think you MUST > put in a sentence that says that the Master Key MUST never be stored on > clients. Clients MUST only be given their K. The fact that the client key is a function of the MK is completely invisible to the client and wire protocol; it falls into the realm of "implementation defined behavior" and should be documented as such in the draft. An interoperable server could store a separately generated key for each client and the clients couldn't tell the difference based on externally visible behavior. - Bill From owner-dhcp-v4@bucknell.edu Fri Jun 23 11:37:12 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13101 for ; Fri, 23 Jun 2000 11:37:11 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5NFY4W11132; Fri, 23 Jun 2000 11:34:04 -0400 (EDT) Received: from codex.cis.upenn.edu (CODEX.CIS.UPENN.EDU [158.130.6.15]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5NFXxW18891 for ; Fri, 23 Jun 2000 11:33:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by codex.cis.upenn.edu (8.10.1/8.10.1) with ESMTP id e5NFXwj04884 for ; Fri, 23 Jun 2000 11:33:58 -0400 (EDT) Date: Fri, 23 Jun 2000 11:33:58 -0400 (EDT) From: "William A. Arbaugh" To: DHCPv4 discussion list Subject: Re: WG last call for "Authentication for DHCP Messages" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: waa@dsl.cis.upenn.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > > The key management schema described is weak at least, I think you MUST > put in a sentence that says that the Master Key MUST never be stored on > clients. Clients MUST only be given their K. > IF this is not made clear in the draft I'm sure someone will implement > a client requiring MK. > As far as I can tell the whole point of this schema is to allow the > server to calculate the keys on the fly when it sees a new client. > I think this motivation should also be stated more clearly. > > I think the section should also contain a warning that if MK is > compromised all clients must be re keyed. > I agree that the scheme is weak from a key management perspective, and I'm fine with adding warning verbage. From owner-dhcp-v4@bucknell.edu Fri Jun 23 18:23:18 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21447 for ; Fri, 23 Jun 2000 18:23:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5NMJMW28486; Fri, 23 Jun 2000 18:19:22 -0400 (EDT) Received: from mail.ultradns.com (IDENT:qmailr@[64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5NMJEW12147 for ; Fri, 23 Jun 2000 18:19:15 -0400 (EDT) Received: (qmail 4061 invoked from network); 23 Jun 2000 22:24:47 -0000 Received: from ip-216-73-154-39.vantas.net (HELO ULTRADNS6PMNFK) (216.73.154.39) by mail.ultradns.com with SMTP; 23 Jun 2000 22:24:47 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: WG last call for "Authentication for DHCP Messages" Date: Fri, 23 Jun 2000 15:23:54 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4.2.2.20000613231312.00a39100@mail.bucknell.edu> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-dhcp-v4@bucknell.edu [mailto:owner-dhcp-v4@bucknell.edu]On > Behalf Of Ralph Droms > Sent: Tuesday, June 13, 2000 8:19 PM > This message announces a DHC WG last call for "Authentication for DHCP > Messages", . > Please forward any comments you may have on this draft to > dhcp-v4@bucknell.edu by Friday, June 23. > ...the draft can go forward with the editorial changes made by Bill in response to the other comments from Bernard and Richard.... it will be good to get this one finished!! --Barr From owner-dhcp-v4@bucknell.edu Sat Jun 24 12:33:45 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13871 for ; Sat, 24 Jun 2000 12:33:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5OGUeW13497; Sat, 24 Jun 2000 12:30:40 -0400 (EDT) Received: from monitor.internaut.com (mg-206191146-48.ricochet.net [206.191.146.48]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5OGUYW04969 for ; Sat, 24 Jun 2000 12:30:34 -0400 (EDT) Received: from kidneybean ([204.57.137.38]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id JAA49479; Sat, 24 Jun 2000 09:28:28 -0700 (PDT) From: aboba@internaut.com Reply-To: To: DHCPv4 discussion list Cc: "'DHCPv4 discussion list'" , Subject: RE: WG last call for "Authentication for DHCP Messages" Date: Sat, 24 Jun 2000 09:30:24 -0700 Message-ID: <004d01bfddf9$8008f890$268939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit >Each client is given K, where K = HMAC(MK, client_id). OK. So the master key is only known to the DHCP server, right? This makes more sense. This enables the DHCP server to calculate and verify the hashes without external help. However, it does mean that if the client_id is changed (say if a new NIC is used), that the client will need to get a new key. From owner-dhcp-v4@bucknell.edu Mon Jun 26 03:01:46 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27686 for ; Mon, 26 Jun 2000 03:01:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5Q6uJW13930; Mon, 26 Jun 2000 02:56:19 -0400 (EDT) Received: from fs-sd-exch2.coppermountain.com (fs-sd-exch1.coppermountain.com [209.246.224.234] (may be forged)) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5Q6uHW19582 for ; Mon, 26 Jun 2000 02:56:17 -0400 (EDT) Received: by mail.coppermountain.com with Internet Mail Service (5.5.2650.21) id ; Sun, 25 Jun 2000 23:58:10 -0700 Message-ID: <9FFFAB5D74FFD31191EA00D0B74178C89C5177@mail.coppermountain.com> From: Eric Michelsen To: DHCPv4 discussion list Subject: RE: ... Allow router to be 0.0.0.0? Date: Sun, 25 Jun 2000 23:58:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: emichelsen@coppermountain.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I believe Windows allows the same "convention" that Linux does: if you specify your own IP address as the *next-hop* for *any* route, then the machine ARPs directly for that address, regardless of its subnet. This has nothing to do with the destination value or mask. You never use a value of zero for the next-hop. For example, if my IP address is 192.168.1.2/24, then a route of dest=172.16.0.0/16 next-hop=192.168.1.2 causes me to ARP directly for anything on 172.16.0.0, even though it's not on my subnet. If it happens that I use my own IP address as the next-hop for the default route, then so be it. All destinations not covered by more specific routes get the "local ARP convention:" dest=0.0.0.0/0 next-hop=192.168.1.2. ------------------------------------------- Eric L. Michelsen, Copper Mountain Networks > -----Original Message----- > From: Bernie Volz [mailto:Volz@ipworks.com] > Sent: Thursday, June 22, 2000 18:40 > To: DHCPv4 discussion list > Subject: RE: ... Allow router to be 0.0.0.0? > > > John: > > The 0.0.0.0 as the default route convention is for the > DESTINATION, not the > ROUTER. We're talking about specifying the ROUTER'S IP > ADDRESS as 0.0.0.0. > That is, obviously, not a legal address for a router. Thus, > there is no > other use of that address. > > A default route, if allowed in CSR (as it is currently), is > specified as a 0 > subnet mask length. > > Thus, if you wanted to specify that all addresses should be > ARPed for, you > might send a CSR option with data as: 00:00:00:00:00. The > means 0 subnet > bits (hence no subnet number) followed by the 0.0.0.0 router > IP address. > > If you wanted to install a route that say the 10 network is > local, you'd use > 08:0a:00:00:00:00. 08 for the subnet bits, 0a for the subnet > number (10), > and 0.0.0.0 for the router. > > If you wanted to install a routes that say the 10 network is > local and for > the 11 network use the router at 10.0.0.1, you'd specify: > 08:0a:00:00:00:00:08:0b:0a:00:00:01. > > See the CSR document for encoding information. > > Hope that helps. > > - Bernie Volz > IPWorks, Inc. > > -----Original Message----- > From: John Schnizlein [mailto:jschnizl@cisco.com] > Sent: Thursday, June 22, 2000 8:43 PM > To: Volz@ipworks.com; DHCPv4 discussion list > Subject: RE:... Allow router to be 0.0.0.0? > > > Please persuade me that this will not cause any confusion > with the common use of 0.0.0.0 as a default route. > It should not imply that the host infer proxy arp for all > addresses, following Ted's explanation below. > It should permit installing preferred routes through > different routers on the directly-attached subnet. > John > > At 06:10 PM 06/22/2000 -0400, Bernie Volz wrote: > >... > >By specifying 0.0.0.0, you set up a standard convention that > >prevents the need for the server to change the option data and > >makes it easy for clients to take whatever special action is > >needed for them to install these routes. > > > >From: Ted Lemon [mailto:mellon@nominum.com] > >... > >What this is is a limited form of the proxy arp feature in Windows, > >where if you give a windows machine its own IP address as a default > >route, it ARPs for every IP address it tries to contact, whether or > >not that IP address is on its local subnet. > From owner-dhcp-v4@bucknell.edu Mon Jun 26 04:49:35 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28414 for ; Mon, 26 Jun 2000 04:49:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5Q8kVW00506; Mon, 26 Jun 2000 04:46:31 -0400 (EDT) Received: from hotmail.com (law2-f9.hotmail.com [216.32.181.9]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5Q8kHW29557 for ; Mon, 26 Jun 2000 04:46:17 -0400 (EDT) Received: (qmail 28211 invoked by uid 0); 26 Jun 2000 08:46:01 -0000 Message-ID: <20000626084601.28210.qmail@hotmail.com> Received: from 195.77.235.2 by www.hotmail.com with HTTP; Mon, 26 Jun 2000 01:46:01 PDT X-Originating-IP: [195.77.235.2] From: "Marc" To: DHCPv4 discussion list Subject: Incomplete list domains from Windows explorer Date: Mon, 26 Jun 2000 10:46:01 CEST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Reply-To: marc_jaumandreu@hotmail.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi all, On a Microsoft netrwork with multiple domains, i have the next problem: When i open network neighborough-entire network from windows explorer to see all network domains, (t is on a Nt server and Windows 9x and 2000), a lot of times only see an incomplete list, but not all the domains. At netbios level, it works fine, because a can do a ping command and i can connect to a server via netbios name, for example doing execute comand: \\name_server I can see the next: From any machine connected to the domain containing the WINS server. is possible to see all the list, but trying it from compùters of other domains than WIN server, the list appears incomplete on windows explorer. I don't know if ther is a problem with WINS server or their domain, but when i restart the computer taht can't see all the list, after restarting, it can see yet all the list. I could thibk that restart proccees causes the renewal of the server list resolution names from WINS, but when it see incomplete list, i don't know why!. Viewed domains are from internal cahe memory?Is aleatory the list i can see? If a WINS error exists, i could see an empty list, only with the owned domain, isn't it? Any help will be appreciated. Thanks to all ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-dhcp-v4@bucknell.edu Mon Jun 26 06:07:27 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28912 for ; Mon, 26 Jun 2000 06:07:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5QA49W07603; Mon, 26 Jun 2000 06:04:09 -0400 (EDT) Received: from hotmail.com (law2-f87.hotmail.com [216.32.181.87]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5QA45W03969 for ; Mon, 26 Jun 2000 06:04:05 -0400 (EDT) Received: (qmail 66891 invoked by uid 0); 26 Jun 2000 10:03:49 -0000 Message-ID: <20000626100349.66890.qmail@hotmail.com> Received: from 195.77.235.2 by www.hotmail.com with HTTP; Mon, 26 Jun 2000 03:03:49 PDT X-Originating-IP: [195.77.235.2] From: "Marc" To: DHCPv4 discussion list Subject: F12 fails in a shortcut as a short method Date: Mon, 26 Jun 2000 12:03:49 CEST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Reply-To: marc_jaumandreu@hotmail.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi all, On a NT Server 4, i assign F12 function key to execute a shotcut as a short method (pressing F12), and it fails. However, if i assign another key (for example F10, F11, etc), it goes right. I think F12 key is reserved to internal funcitons from NT, but i don't know. I tryed it on a Windows 9x system and it gores right. Any help? Thanks ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-dhcp-v6@bucknell.edu Mon Jun 26 11:18:43 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08214 for ; Mon, 26 Jun 2000 11:18:42 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5QFFcW21354; Mon, 26 Jun 2000 11:15:38 -0400 (EDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5QFFRW07517 for ; Mon, 26 Jun 2000 11:15:28 -0400 (EDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5QFF9K24159 for ; Mon, 26 Jun 2000 17:15:10 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA05867 for ; Mon, 26 Jun 2000 17:15:08 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id RAA02281 for ; Mon, 26 Jun 2000 17:15:48 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006261515.RAA02281@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: DHCPv6 discussion list Subject: solicit-ID Date: Mon, 26 Jun 2000 17:15:48 +0200 Sender: owner-dhcp-v6@bucknell.edu Reply-To: dhcp-v6@bucknell.edu X-Sender: Francis.Dupont@enst-bretagne.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN There is no rationate for the new solicit-ID introduced by the last I-D (draft-ietf-dhc-dhcpv6-15.txt). What is the need for "matching Advertise messages to the sent Solicit message"? Regards Francis.Dupont@enst-bretagne.fr PS: in the revised IPng WG charter you can find in new proposed items: - Support for multi-link subnets (single subnet spans multiple links) then as DHCPv6 doesn't support this, a statement should be added in specs. From owner-dhcp-v4@bucknell.edu Mon Jun 26 17:20:34 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15994 for ; Mon, 26 Jun 2000 17:20:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5QLHMW21775; Mon, 26 Jun 2000 17:17:22 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5QLH9W09123 for ; Mon, 26 Jun 2000 17:17:10 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dhcp-184.rc.vix.com [204.152.187.184]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id WAA14199; Sun, 25 Jun 2000 22:37:07 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id OAA00605; Mon, 26 Jun 2000 14:17:36 -0700 (MST) Message-Id: <200006262117.OAA00605@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Incomplete list domains from Windows explorer In-Reply-To: Message from "Marc" of "Mon, 26 Jun 2000 10:46:01 EST." <20000626084601.28210.qmail@hotmail.com> Date: Mon, 26 Jun 2000 14:17:36 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Your DHCP server may be sending the clients a node type that's wrong for your network. If you don't have a NetBIOS domain controller (not sure if that's precisely the right name) and your DHCP server is telling clients that they should be querying a domain controller, then it won't work, for example. So I'd run winipcfg and see how your clients are saying they have been configured, and make sure that matches what you actually have deployed on your network. _MelloN_ From owner-dhcp-v4@bucknell.edu Mon Jun 26 20:53:13 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17657 for ; Mon, 26 Jun 2000 20:53:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5R0oNW16057; Mon, 26 Jun 2000 20:50:23 -0400 (EDT) Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5R0oEW29180 for ; Mon, 26 Jun 2000 20:50:14 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-166.cisco.com [161.44.133.166]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id UAA04550; Mon, 26 Jun 2000 20:49:54 -0400 (EDT) Message-Id: <4.3.1.2.20000626204948.00b10140@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 26 Jun 2000 20:51:35 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Re: Quick Poll - RE: draft-ietf-dhc-csr-02.txt - Allow router to be 0 .0.0.0? In-Reply-To: <63D30D6E10CFD11190A90000F805FE8602BEBE5F@LESPAUL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I would be inclined to specify the list of networks local to the interface as a separate option. It's different information (and should be carried in a different option), there's no need to carry the 4 bytes of zeroes with every entry and it would slow down draft-ietf-dhc-csr-02.txt. - Ralph At 05:02 PM 6/22/00 -0400, Bernie Volz wrote: >I have suggested to Ted that he consider adding text to Classless Static >Routing (CSR) draft to allow the router IP address to be 0.0.0.0 for some >routes. If the router IP address is 0.0.0.0, the client (if it supports it) >should install a route such that the destination is directly reachable on >the interface being configured. > >So, how do people feel about this? >- Do you feel it is worth adding it? >- Do you fear it would delay the draft? >- Do you think it is a bad idea in the first place? From owner-dhcp-v4@bucknell.edu Mon Jun 26 21:00:22 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17717 for ; Mon, 26 Jun 2000 21:00:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5R0xuW00713; Mon, 26 Jun 2000 20:59:56 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5R0xlW24853 for ; Mon, 26 Jun 2000 20:59:47 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Jun 2000 20:59:32 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBE6C@lespaul.process.com> From: Bernie Volz To: DHCPv4 discussion list Cc: "'dhcp-v4@bucknell.edu'" Subject: RE: ... Allow router to be 0.0.0.0? Date: Mon, 26 Jun 2000 20:59:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Volz@ipworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Eric: I don't understand your comment. I'm saying that for a local route, we want to specify 0.0.0.0 as the router in the CSR option. The client would substitute ITS LOCAL IP ADDRESS to install that route, for the router, on Windows and Linux. For other platforms, it does whatever it needs to do. If we made the CSR option specify the host's IP Address, then the DHCP Server would have to construct a unique CSR option for each host. Not a nice thing, IMHO, since the server would (a) have to treat this option as special and (b) have some mechanism for the user to request the behavoir on a specific route. By using the 0.0.0.0 convention, you solve both these problems. Of course the host can't use 0.0.0.0 as the router and must do whatever is necessary for the destination to be local, if that is something it can support. - Bernie Volz -----Original Message----- From: Eric Michelsen [mailto:emichelsen@coppermountain.com] Sent: Monday, June 26, 2000 2:58 AM To: DHCPv4 discussion list Subject: RE: ... Allow router to be 0.0.0.0? I believe Windows allows the same "convention" that Linux does: if you specify your own IP address as the *next-hop* for *any* route, then the machine ARPs directly for that address, regardless of its subnet. This has nothing to do with the destination value or mask. You never use a value of zero for the next-hop. For example, if my IP address is 192.168.1.2/24, then a route of dest=172.16.0.0/16 next-hop=192.168.1.2 causes me to ARP directly for anything on 172.16.0.0, even though it's not on my subnet. If it happens that I use my own IP address as the next-hop for the default route, then so be it. All destinations not covered by more specific routes get the "local ARP convention:" dest=0.0.0.0/0 next-hop=192.168.1.2. ------------------------------------------- Eric L. Michelsen, Copper Mountain Networks > -----Original Message----- > From: Bernie Volz [mailto:Volz@ipworks.com] > Sent: Thursday, June 22, 2000 18:40 > To: DHCPv4 discussion list > Subject: RE: ... Allow router to be 0.0.0.0? > > > John: > > The 0.0.0.0 as the default route convention is for the > DESTINATION, not the > ROUTER. We're talking about specifying the ROUTER'S IP > ADDRESS as 0.0.0.0. > That is, obviously, not a legal address for a router. Thus, > there is no > other use of that address. > > A default route, if allowed in CSR (as it is currently), is > specified as a 0 > subnet mask length. > > Thus, if you wanted to specify that all addresses should be > ARPed for, you > might send a CSR option with data as: 00:00:00:00:00. The > means 0 subnet > bits (hence no subnet number) followed by the 0.0.0.0 router > IP address. > > If you wanted to install a route that say the 10 network is > local, you'd use > 08:0a:00:00:00:00. 08 for the subnet bits, 0a for the subnet > number (10), > and 0.0.0.0 for the router. > > If you wanted to install a routes that say the 10 network is > local and for > the 11 network use the router at 10.0.0.1, you'd specify: > 08:0a:00:00:00:00:08:0b:0a:00:00:01. > > See the CSR document for encoding information. > > Hope that helps. > > - Bernie Volz > IPWorks, Inc. > > -----Original Message----- > From: John Schnizlein [mailto:jschnizl@cisco.com] > Sent: Thursday, June 22, 2000 8:43 PM > To: Volz@ipworks.com; DHCPv4 discussion list > Subject: RE:... Allow router to be 0.0.0.0? > > > Please persuade me that this will not cause any confusion > with the common use of 0.0.0.0 as a default route. > It should not imply that the host infer proxy arp for all > addresses, following Ted's explanation below. > It should permit installing preferred routes through > different routers on the directly-attached subnet. > John > > At 06:10 PM 06/22/2000 -0400, Bernie Volz wrote: > >... > >By specifying 0.0.0.0, you set up a standard convention that > >prevents the need for the server to change the option data and > >makes it easy for clients to take whatever special action is > >needed for them to install these routes. > > > >From: Ted Lemon [mailto:mellon@nominum.com] > >... > >What this is is a limited form of the proxy arp feature in Windows, > >where if you give a windows machine its own IP address as a default > >route, it ARPs for every IP address it tries to contact, whether or > >not that IP address is on its local subnet. > From owner-dhcp-v4@bucknell.edu Mon Jun 26 21:06:07 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17790 for ; Mon, 26 Jun 2000 21:06:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5R15cW26360; Mon, 26 Jun 2000 21:05:38 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5R15TW06069; Mon, 26 Jun 2000 21:05:29 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Jun 2000 21:05:14 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBE6F@lespaul.process.com> From: Bernie Volz To: DHCPv4 discussion list Subject: RE: Quick Poll - RE: draft-ietf-dhc-csr-02.txt - Allow router to be 0 .0.0.0? Date: Mon, 26 Jun 2000 21:05:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Volz@ipworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ralph: To save option space, having a separate option (IMHO) is not a good idea. It is routing information - plain and simple. I don't really know why it would slow down the draft. - Bernie Volz IPWorks, Inc. -----Original Message----- From: Ralph Droms [mailto:droms@bucknell.edu] Sent: Monday, June 26, 2000 8:52 PM To: Volz@ipworks.com; DHCPv4 discussion list Subject: Re: Quick Poll - RE: draft-ietf-dhc-csr-02.txt - Allow router to be 0 .0.0.0? I would be inclined to specify the list of networks local to the interface as a separate option. It's different information (and should be carried in a different option), there's no need to carry the 4 bytes of zeroes with every entry and it would slow down draft-ietf-dhc-csr-02.txt. - Ralph At 05:02 PM 6/22/00 -0400, Bernie Volz wrote: >I have suggested to Ted that he consider adding text to Classless Static >Routing (CSR) draft to allow the router IP address to be 0.0.0.0 for some >routes. If the router IP address is 0.0.0.0, the client (if it supports it) >should install a route such that the destination is directly reachable on >the interface being configured. > >So, how do people feel about this? >- Do you feel it is worth adding it? >- Do you fear it would delay the draft? >- Do you think it is a bad idea in the first place? From owner-dhcp-v4@bucknell.edu Mon Jun 26 21:18:54 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17893 for ; Mon, 26 Jun 2000 21:18:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5R1FuW08817; Mon, 26 Jun 2000 21:15:56 -0400 (EDT) Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5R1FiW19688 for ; Mon, 26 Jun 2000 21:15:44 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-166.cisco.com [161.44.133.166]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id VAA04563; Mon, 26 Jun 2000 21:15:42 -0400 (EDT) Message-Id: <4.3.1.2.20000626211723.00ae76e0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 26 Jun 2000 21:17:57 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: RE: Quick Poll - RE: draft-ietf-dhc-csr-02.txt - Allow router to be 0 .0.0.0? In-Reply-To: <63D30D6E10CFD11190A90000F805FE8602BEBE6F@lespaul.process.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 09:05 PM 6/26/00 -0400, you wrote: >To save option space, having a separate option (IMHO) is not a good idea. It >is routing information - plain and simple. It would save option space to combine the local subnets information into the static routes option. In my opinion, we have option codes for both options and I think the two kinds of routing information are different. >I don't really know why it would slow down the draft. I think it already has (although not much!) - if we hadn't had this discussion, draft-ietf-dhc-csr-02.txt would have been ready to go for PS. - Ralph From owner-dhcp-v4@bucknell.edu Mon Jun 26 21:55:21 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19105 for ; Mon, 26 Jun 2000 21:55:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5R1oLW07161; Mon, 26 Jun 2000 21:50:21 -0400 (EDT) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5R1oDW11725 for ; Mon, 26 Jun 2000 21:50:13 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-166.cisco.com [161.44.133.166]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id VAA04578; Mon, 26 Jun 2000 21:50:12 -0400 (EDT) Message-Id: <4.3.1.2.20000625200831.00b62a10@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 26 Jun 2000 21:52:16 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Re: WG last call for "Authentication for DHCP Messages" Cc: waa@cs.umd.edu In-Reply-To: References: <3950F129.D1D8DE97@metaip.checkpoint.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN OK, based on comments received during the WG last call, I will make the following changes to the "Authentication for DHCP Messages" prior to submission for PS: * In the first diagram in section 2, change the second occurrence of 'Algorithm' to 'RDM' * Add text to section 5.2 indicating that an authentication request can appear in either a DHCPDISCOVER or a DHCPINFORM message * In section 5.6.4, add text allowing a server to ignore an authenticated DHCPINFORM message that the server cannot validate as well as replying with a DHCPNAK * Section 5, second sentence: remove second instance of 'information' * Section 5.3, second sentence: change to start with "Next, the receiver..." * Add text to Appendix A: To avoid compromise of this key management system, the master key, MK, MUST NOT be stored in the client. The client SHOULD only be given its key, K. If MK is compromised, a new MK must be chosen and all clients given new individual keys. - Ralph From owner-dhcp-v4@bucknell.edu Mon Jun 26 23:43:55 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21210 for ; Mon, 26 Jun 2000 23:43:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5R3bDW17302; Mon, 26 Jun 2000 23:37:13 -0400 (EDT) Received: from fs-sd-exch2.coppermountain.com (fs-sd-exch1.coppermountain.com [209.246.224.234] (may be forged)) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5R3b5W10796 for ; Mon, 26 Jun 2000 23:37:06 -0400 (EDT) Received: by mail.coppermountain.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Jun 2000 20:39:03 -0700 Message-ID: <9FFFAB5D74FFD31191EA00D0B74178C89C518F@mail.coppermountain.com> From: Eric Michelsen To: DHCPv4 discussion list Subject: RE: ... Allow router to be 0.0.0.0? Date: Mon, 26 Jun 2000 20:39:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: emichelsen@coppermountain.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Sorry, I think I misunderstood the question. Yes, I agree with Bernie, below. ------------------------------------------- Eric L. Michelsen, Copper Mountain Networks > -----Original Message----- > From: Bernie Volz [mailto:Volz@ipworks.com] > Sent: Monday, June 26, 2000 18:00 > To: DHCPv4 discussion list > Cc: 'dhcp-v4@bucknell.edu' > Subject: RE: ... Allow router to be 0.0.0.0? > > > Eric: > > I don't understand your comment. > > I'm saying that for a local route, we want to specify 0.0.0.0 > as the router > in the CSR option. The client would substitute ITS LOCAL IP ADDRESS to > install that route, for the router, on Windows and Linux. For other > platforms, it does whatever it needs to do. > > If we made the CSR option specify the host's IP Address, then the DHCP > Server would have to construct a unique CSR option for each > host. Not a nice > thing, IMHO, since the server would (a) have to treat this > option as special > and (b) have some mechanism for the user to request the behavoir on a > specific route. > > By using the 0.0.0.0 convention, you solve both these > problems. Of course > the host can't use 0.0.0.0 as the router and must do whatever > is necessary > for the destination to be local, if that is something it can support. > > - Bernie Volz > > -----Original Message----- > From: Eric Michelsen [mailto:emichelsen@coppermountain.com] > Sent: Monday, June 26, 2000 2:58 AM > To: DHCPv4 discussion list > Subject: RE: ... Allow router to be 0.0.0.0? > > > I believe Windows allows the same "convention" that Linux does: if you > specify your own IP address as the *next-hop* for *any* > route, then the > machine ARPs directly for that address, regardless of its > subnet. This has > nothing to do with the destination value or mask. You > never use a value > of zero for the next-hop. > > For example, if my IP address is 192.168.1.2/24, then a route of > > dest=172.16.0.0/16 next-hop=192.168.1.2 > > causes me to ARP directly for anything on 172.16.0.0, even > though it's not > on my subnet. > > If it happens that I use my own IP address as the next-hop > for the default > route, then so be it. All destinations not covered by more > specific routes > get the "local ARP convention:" > > dest=0.0.0.0/0 next-hop=192.168.1.2. > ------------------------------------------- > Eric L. Michelsen, Copper Mountain Networks > > > -----Original Message----- > > From: Bernie Volz [mailto:Volz@ipworks.com] > > Sent: Thursday, June 22, 2000 18:40 > > To: DHCPv4 discussion list > > Subject: RE: ... Allow router to be 0.0.0.0? > > > > > > John: > > > > The 0.0.0.0 as the default route convention is for the > > DESTINATION, not the > > ROUTER. We're talking about specifying the ROUTER'S IP > > ADDRESS as 0.0.0.0. > > That is, obviously, not a legal address for a router. Thus, > > there is no > > other use of that address. > > > > A default route, if allowed in CSR (as it is currently), is > > specified as a 0 > > subnet mask length. > > > > Thus, if you wanted to specify that all addresses should be > > ARPed for, you > > might send a CSR option with data as: 00:00:00:00:00. The > > means 0 subnet > > bits (hence no subnet number) followed by the 0.0.0.0 router > > IP address. > > > > If you wanted to install a route that say the 10 network is > > local, you'd use > > 08:0a:00:00:00:00. 08 for the subnet bits, 0a for the subnet > > number (10), > > and 0.0.0.0 for the router. > > > > If you wanted to install a routes that say the 10 network is > > local and for > > the 11 network use the router at 10.0.0.1, you'd specify: > > 08:0a:00:00:00:00:08:0b:0a:00:00:01. > > > > See the CSR document for encoding information. > > > > Hope that helps. > > > > - Bernie Volz > > IPWorks, Inc. > > > > -----Original Message----- > > From: John Schnizlein [mailto:jschnizl@cisco.com] > > Sent: Thursday, June 22, 2000 8:43 PM > > To: Volz@ipworks.com; DHCPv4 discussion list > > Subject: RE:... Allow router to be 0.0.0.0? > > > > > > Please persuade me that this will not cause any confusion > > with the common use of 0.0.0.0 as a default route. > > It should not imply that the host infer proxy arp for all > > addresses, following Ted's explanation below. > > It should permit installing preferred routes through > > different routers on the directly-attached subnet. > > John > > > > At 06:10 PM 06/22/2000 -0400, Bernie Volz wrote: > > >... > > >By specifying 0.0.0.0, you set up a standard convention that > > >prevents the need for the server to change the option data and > > >makes it easy for clients to take whatever special action is > > >needed for them to install these routes. > > > > > >From: Ted Lemon [mailto:mellon@nominum.com] > > >... > > >What this is is a limited form of the proxy arp feature in Windows, > > >where if you give a windows machine its own IP address as a default > > >route, it ARPs for every IP address it tries to contact, whether or > > >not that IP address is on its local subnet. > > > From owner-dhcp-v6@bucknell.edu Mon Jun 26 23:48:49 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21291 for ; Mon, 26 Jun 2000 23:48:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5R3idW08073; Mon, 26 Jun 2000 23:44:39 -0400 (EDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5R3iOW09583 for ; Mon, 26 Jun 2000 23:44:24 -0400 (EDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id C199D683; Mon, 26 Jun 2000 22:44:08 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 5B1AB637 for ; Mon, 26 Jun 2000 22:44:08 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id XAA0000739474; Mon, 26 Jun 2000 23:44:07 -0400 (EDT) From: Jim Bound Message-Id: <200006270344.XAA0000739474@anw.zk3.dec.com> To: DHCPv6 discussion list Cc: bound@ZK3.DEC.COM Subject: Re: solicit-ID In-reply-to: Your message of "Mon, 26 Jun 2000 17:15:48 +0200." <200006261515.RAA02281@givry.rennes.enst-bretagne.fr> Date: Mon, 26 Jun 2000 23:44:05 -0400 X-Mts: smtp Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi Francis, >There is no rationate for the new solicit-ID introduced by the last I-D >(draft-ietf-dhc-dhcpv6-15.txt). What is the need for "matching Advertise >messages to the sent Solicit message"? >From 10.3.1 If the client is prepared to process multiple Advertise messages in response to its Solicit message, the client will set the Solicit-ID field to 1. Every time the client initiates a new server solicitation attempt (not a retransmission), the client increments the Solicit-ID by one. If the 9-bit field rolls over to 0, then the client sets the Solicit-ID to 1. A client which will only accept the first Advertise message it receives leaves the Solicit-ID field initialized to zero. The idea was that the client may talk to different servers after a new solicit takes place? Comments? >PS: in the revised IPng WG charter you can find in new proposed items: > - Support for multi-link subnets (single subnet spans multiple links) >then as DHCPv6 doesn't support this, a statement should be added in specs. I saw that and see my mail the IPng list. I have no issue with subnets spanning multiple links if we can figure it out. But I do strongly object if the idea of a global address is gone!!! If that happens working on anything for IPv6 is just stupid the whole architeture is broken. I don't think that will happen. DHCPv6 must assume as we state in the draft that a server spanning multiple sites must use global addresses today, likewise we assume global addresses are in fact unique. IPng has not stated they will break that model. Also we cannot base our efforts to get to PS on IPng Working Group milestones. regards, /jim From owner-dhcp-v4@bucknell.edu Tue Jun 27 04:52:30 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05221 for ; Tue, 27 Jun 2000 04:52:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5R8g8W25236; Tue, 27 Jun 2000 04:42:08 -0400 (EDT) Received: from fs-sd-exch2.coppermountain.com (fs-sd-exch1.coppermountain.com [209.246.224.234] (may be forged)) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5R8g3W28358 for ; Tue, 27 Jun 2000 04:42:03 -0400 (EDT) Received: by mail.coppermountain.com with Internet Mail Service (5.5.2650.21) id ; Tue, 27 Jun 2000 01:44:05 -0700 Message-ID: <9FFFAB5D74FFD31191EA00D0B74178C89C5193@mail.coppermountain.com> From: Eric Michelsen To: DHCPv4 discussion list Subject: RE: Quick Poll - RE: draft-ietf-dhc-csr-02.txt - Allow router to be 0 .0.0.0? Date: Tue, 27 Jun 2000 01:44:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: emichelsen@coppermountain.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > -----Original Message----- > From: Bernie Volz [mailto:Volz@ipworks.com] > Sent: Thursday, June 22, 2000 14:02 > To: DHCPv4 discussion list > Subject: Quick Poll - RE: draft-ietf-dhc-csr-02.txt - Allow > router to be > 0 .0.0.0? > > > Folks: > > I have suggested to Ted that he consider adding text to > Classless Static > Routing (CSR) draft to allow the router IP address to be > 0.0.0.0 for some ... > So, how do people feel about this? > - Do you feel it is worth adding it? > - Do you fear it would delay the draft? > - Do you think it is a bad idea in the first place? I don't think it's worth adding, just because I don't see much value to it. I think there's a risk of slowing down the draft, because it's not standard, and will require frequent re-explanation. But I don't see any major problem with it, though. From owner-dhcp-v4@bucknell.edu Tue Jun 27 07:04:38 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07056 for ; Tue, 27 Jun 2000 07:04:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5RB1BW32034; Tue, 27 Jun 2000 07:01:11 -0400 (EDT) Received: from hygro.adsl.duke.edu (IDENT:root@hygro.adsl.duke.edu [152.16.64.159]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5RB10W24376 for ; Tue, 27 Jun 2000 07:01:05 -0400 (EDT) Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1]) by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id HAA01344; Tue, 27 Jun 2000 07:00:29 -0400 Message-Id: <200006271100.HAA01344@hygro.adsl.duke.edu> To: DHCPv4 discussion list cc: IP1394@mailbag.cps.intel.com, dhcp-v4@bucknell.edu Subject: Re: Next Interop Event In-Reply-To: Message from Peter Johansson of "Mon, 26 Jun 2000 11:05:02 PDT." <4.3.2.7.2.20000626110435.00b81b00@PacBell.net> Date: Tue, 27 Jun 2000 07:00:29 -0400 From: Thomas Narten Reply-To: narten@raleigh.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I think there is a need for another interoperability event, this time to be > focused upon DHCP and MCAP issues. For DHCP interoperability testing, I'd strongly urge that you involve the DHCP community. Indeed, they have done a lot of testing and I believe still do on occasion. I.e., this is a DHCP testing issue (relay agents and servers), more than a 1394 testing issue (which would just be the client part). You might want to contact Mike Carney , who has organized DHCP testing at Interop in the past. Thomas > Such an event probably needs some advance planning on what is to be tested > and the test matrix we intend to use. Of course, as all past coordinators > can attest, it also needs significant logistical support. > What if we defer the question of when and where (for the time being) and > focus on the following: > 1) Is there a perceived need for another event? Who would likely participate? > 2) What are the test scenarios, DHCP and MCAP, for which we should prepare? > 3) Is a possible outcome of the cumulative experience from these events a > compliance specification and/or tests? Has the IETF created such ancillary > documents and tests in the past? > Regards, > Peter Johansson > Congruent Software, Inc. > 98 Colorado Avenue > Berkeley, CA 94707 > (510) 527-3926 > (510) 527-3856 FAX > PJohansson@ACM.org From owner-dhcp-v6@bucknell.edu Tue Jun 27 13:27:46 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18766 for ; Tue, 27 Jun 2000 13:27:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5RHPBW29875; Tue, 27 Jun 2000 13:25:12 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5RHOxW30285 for ; Tue, 27 Jun 2000 13:24:59 -0400 (EDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA26769 for ; Tue, 27 Jun 2000 10:24:54 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.81.144]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id KAA29994 for ; Tue, 27 Jun 2000 10:24:51 -0700 (PDT) Received: from eng.sun.com (dhcp-174-237.East.Sun.COM [129.148.174.237]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RHOma679895 for ; Tue, 27 Jun 2000 10:24:48 -0700 (PDT) Sender: owner-dhcp-v6@bucknell.edu Message-ID: <3958E355.8A5A49CA@eng.sun.com> Date: Tue, 27 Jun 2000 10:24:37 -0700 From: "Michael W. Carney" Organization: Sun Microsystems, Inc X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list Subject: Re: solicit-ID References: <200006261515.RAA02281@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: dhcp-v6@bucknell.edu X-Sender: Michael.Carney@eng.sun.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hi Francis, Francis Dupont wrote: > > There is no rationate for the new solicit-ID introduced by the last I-D > (draft-ietf-dhc-dhcpv6-15.txt). What is the need for "matching Advertise > messages to the sent Solicit message"? Thank you, francis - if we don't include the rational for a feature (and it isn't clear), we have to either clarify it or remove it from the protocol. The reason we added the solicit ID is to enable clients to identify advertisements generated by specific solicits. There are two kinds of clients: 1) Simple - These clients accept the first advertisement received in response to a solicit. They ignore any other advertisements that are received. 2) Sophisticated - These clients are prepared to process multiple advertisements. They may set the 'P' bit to request that servers return subnet prefix extensions for those networks on the client's link that the server is configured to manage. They may have multiple solicitation events pending. The solicit ID is important for the second type of client. Since they are prepared to accept multiple advertisements, they need to be able to differentiate between advertisements received due to earlier solicitations vs those due the the most recent solicit (which is why the solicit id is incremented whenever a new solicitation is generated, not when one is retransmitted). In short, it lets the client connect advertisements to the solicitation event that generated them. Based upon the application requirements, the same dhcp client may operate as both types - e.g., I want to find any server, or I'm shopping for a server that can give me a network address of sufficient scope needed by the application. > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: in the revised IPng WG charter you can find in new proposed items: > - Support for multi-link subnets (single subnet spans multiple links) > then as DHCPv6 doesn't support this, a statement should be added in specs. Where can I find details about the rational for this topology? Thanks, Mike Carney From owner-dhcp-v4@bucknell.edu Tue Jun 27 14:31:07 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20873 for ; Tue, 27 Jun 2000 14:31:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5RIQhW08046; Tue, 27 Jun 2000 14:26:43 -0400 (EDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5RIQTW08681 for ; Tue, 27 Jun 2000 14:26:29 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA73408 for ; Tue, 27 Jun 2000 14:24:34 -0400 From: jjcorc@us.ibm.com Received: from D51MTA06.pok.ibm.com (d51mta06.pok.ibm.com [9.117.200.34]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.9) with SMTP id OAA145698 for ; Tue, 27 Jun 2000 14:26:26 -0400 Received: by D51MTA06.pok.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525690B.00654C22 ; Tue, 27 Jun 2000 14:26:26 -0400 X-Lotus-FromDomain: IBMUS To: DHCPv4 discussion list Message-ID: <8525690B.00654909.00@D51MTA06.pok.ibm.com> Date: Tue, 27 Jun 2000 13:26:20 -0500 Subject: Use of DHCID in draft-ietf-dhc-dhcp-dns-12 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Reply-To: jjcorc@us.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I have several questions concerning the use of the DHCID defined in the DHCP-DNS interaction draft, draft-ietf-dhc-dhcp-dns-12.txt. First, in section 8.2 it states.... "The DHCP server submits a DNS query which deletes all of the PTR RRs associated with the lease IP address, and adds a PTR RR whose data is the client's (possibly disambiguated) host name. The server also adds a DHCID RR specified in Section 4.3." It seems that the DHCID was created as a way to enforce a policy concerning name collisions. As such, most of the discussion in the draft centers around how the DHCID is used in performing A RR updates. Section 8.1 describes the prerequisite checking which takes place for A RR updates and mentions the decision that must be made (based on an administrative policy) as to whether an A RR should be updated if an existing A RR is found. However, for PTR record updates, it simply states that the server adds the DHCID RR (without any such pre-requisite checking and policy decisions). Therefore, what is the purpose of adding a DHCID RR when adding a PTR record? Secondly, what is the status of DHCID? I have been unable to find reference 12 (draft-ietf-dnsext-dhcid-rr-*) mentioned in the DHCP-DNS interaction draft. Does anyone know of any DNS servers that support a DHCID RR or if they intend to support it in the future? Thanks in advance for your responses! Jack Corcoran Email: jjcorc@us.ibm.com Ph 607-752-5570, T/L 852-5570, FAX: 607-752-5421 From owner-dhcp-v4@bucknell.edu Tue Jun 27 14:51:28 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21823 for ; Tue, 27 Jun 2000 14:51:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5RInMW04597; Tue, 27 Jun 2000 14:49:22 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5RIn8W08420 for ; Tue, 27 Jun 2000 14:49:08 -0400 (EDT) Received: from kkinnear-nt (ch2-dhcp133-151.cisco.com [161.44.133.151]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA19031; Tue, 27 Jun 2000 14:48:09 -0400 (EDT) Message-Id: <4.2.0.58.20000627144507.01465e70@funnel.cisco.com> X-Sender: kkinnear@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 27 Jun 2000 14:49:02 -0400 To: DHCPv4 discussion list From: Kim Kinnear Subject: Re: Next Interop Event Cc: kkinnear@cisco.com, dhcp-v4@bucknell.edu In-Reply-To: <200006271100.HAA01344@hygro.adsl.duke.edu> References: <4.3.2.7.2.20000626110435.00b81b00@PacBell.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: kkinnear@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This certainly sounds to me like a good candidate for testing at Connectathon early next year. There are typically several days of DHCP interoperability testing at Connectathon, and it continues to be a good venue such DHCP testing. Cheers -- Kim At 07:00 AM 6/27/00 -0400, Thomas Narten wrote: > > I think there is a need for another interoperability event, this time to be > > focused upon DHCP and MCAP issues. > >For DHCP interoperability testing, I'd strongly urge that you involve >the DHCP community. Indeed, they have done a lot of testing and I >believe still do on occasion. I.e., this is a DHCP testing issue >(relay agents and servers), more than a 1394 testing issue (which >would just be the client part). You might want to contact Mike Carney >, who has organized DHCP testing at >Interop in the past. > >Thomas > > > Such an event probably needs some advance planning on what is to be tested > > and the test matrix we intend to use. Of course, as all past coordinators > > can attest, it also needs significant logistical support. > > > What if we defer the question of when and where (for the time being) and > > focus on the following: > > > 1) Is there a perceived need for another event? Who would likely participate? > > > 2) What are the test scenarios, DHCP and MCAP, for which we should prepare? > > > 3) Is a possible outcome of the cumulative experience from these events a > > compliance specification and/or tests? Has the IETF created such ancillary > > documents and tests in the past? > > > Regards, > > > Peter Johansson > > > Congruent Software, Inc. > > 98 Colorado Avenue > > Berkeley, CA 94707 > > > (510) 527-3926 > > (510) 527-3856 FAX > > > PJohansson@ACM.org > From owner-dhcp-v4@bucknell.edu Wed Jun 28 16:09:52 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03201 for ; Wed, 28 Jun 2000 16:09:52 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5SK6LW03784; Wed, 28 Jun 2000 16:06:21 -0400 (EDT) Received: from quadntweb.quadritek.com ([198.200.138.211]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5SK6CW02231 for ; Wed, 28 Jun 2000 16:06:12 -0400 (EDT) Received: from agrabilnt ([198.200.138.254]) by quadntweb.quadritek.com (Post.Office MTA v3.5.3 release 223 ID# 0-59484U200L100S0V35) with SMTP id com for ; Wed, 28 Jun 2000 16:00:06 -0400 From: agrabil@quadritek.com (Greg Rabil) To: DHCPv4 discussion list Subject: Use of 'flags' in option 81 Date: Wed, 28 Jun 2000 16:05:01 -0400 Message-ID: <00d901bfe13c$245857c0$fe8ac8c6@quadritek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <3950F129.D1D8DE97@metaip.checkpoint.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Reply-To: agrabil@quadritek.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit I'd be interested in other folks that have implemented support for draft-ietf-dhc-dhcp-dns-11/12 in their servers. Particularly, I'm trying to determine the proper value to be set in the 'flags' field when the server is allowing the client to do the A RR update, and it (the server) is going to do the PTR RR update. I'm interested in what others have done in this case. It seems a bit unclear to me. The only relavent text I can find is the following at the end of paragraph 4 in Section 7 of the -12 draft: In either case, if the server intends to perform the DNS update and the client's REQUEST message included the FQDN option, the server SHOULD include the FQDN option in its ACK message, and MUST set the "S" bit in the option's Flags field. OK, but this paragraph is in the context of the server doing the A RR update. My question is what should be set if the server is "honoring" the client (W2K's default) request that the client do the A, and the server does the PTR. I assumed that the flags field in this case would look as follows (ignoring the DNS-encoding): 00000010 This, hopefully, indicating that yes, I (the server) will do the PTR RR update as indicated by the 1 in the 'O' bit. And leave the 'S' bit clear, again hopefully, indicating the I've honored the client's request, so I think it should perform the A RR update. Microsoft's documentation for W2K (the only client I'm aware of that has implemented this draft) mentions only values of 1(00000001) and 3(00000011) for 'flags'. Ideas, comments? Thanks, Greg From owner-dhcp-v6@bucknell.edu Thu Jun 29 04:06:37 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24203 for ; Thu, 29 Jun 2000 04:06:37 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5T83YW09329; Thu, 29 Jun 2000 04:03:34 -0400 (EDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5T83LW01185 for ; Thu, 29 Jun 2000 04:03:21 -0400 (EDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5T833K27598 for ; Thu, 29 Jun 2000 10:03:04 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA07166 for ; Thu, 29 Jun 2000 10:03:02 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id KAA15029 for ; Thu, 29 Jun 2000 10:04:02 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006290804.KAA15029@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: DHCPv6 discussion list Subject: Re: solicit-ID In-reply-to: Your message of Tue, 27 Jun 2000 10:24:37 PDT. <3958E355.8A5A49CA@eng.sun.com> Date: Thu, 29 Jun 2000 10:03:58 +0200 Sender: owner-dhcp-v6@bucknell.edu Reply-To: dhcp-v6@bucknell.edu X-Sender: Francis.Dupont@enst-bretagne.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN In your previous mail you wrote: > There is no rationate for the new solicit-ID introduced by the last I-D > (draft-ietf-dhc-dhcpv6-15.txt). What is the need for "matching Advertise > messages to the sent Solicit message"? 2) Sophisticated - These clients are prepared to process multiple advertisements. They may set the 'P' bit to request that servers return subnet prefix extensions for those networks on the client's link that the server is configured to manage. They may have multiple solicitation events pending. => the 'P' bit seems to be the key. The solicit ID is important for the second type of client. Since they are prepared to accept multiple advertisements, they need to be able to differentiate between advertisements received due to earlier solicitations vs those due the the most recent solicit (which is why the solicit id is incremented whenever a new solicitation is generated, not when one is retransmitted). In short, it lets the client connect advertisements to the solicitation event that generated them. => I believe you'd like to avoid some race conditions in case of a solicit during a renumbering. I think renumbering events have a large time scale but solicit/advertisement sequences with off-link servers must be done through relays (on the contrary request/reply can be done directly using global addresses for instance) then races can occur... > PS: in the revised IPng WG charter you can find in new proposed items: > - Support for multi-link subnets (single subnet spans multiple links) > then as DHCPv6 doesn't support this, a statement should be added in specs. Where can I find details about the rational for this topology? => there are some messages about this in the IPng mailing list. Multi-link subnets are in the revised charter and are used in draft-nordmark-ipv6-aaa-hooks-00.txt where they gives some kind of mobility supports with host routing. Regards Francis.Dupont@enst-bretagne.fr From owner-dhcp-v4@bucknell.edu Thu Jun 29 09:51:16 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07876 for ; Thu, 29 Jun 2000 09:51:16 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5TDe8W30958; Thu, 29 Jun 2000 09:40:08 -0400 (EDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5TDdtW29140 for ; Thu, 29 Jun 2000 09:39:55 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA141576 for ; Thu, 29 Jun 2000 09:37:45 -0400 From: hoyoung@us.ibm.com Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.9) with SMTP id JAA17670 for ; Thu, 29 Jun 2000 09:39:37 -0400 Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525690D.004B06F2 ; Thu, 29 Jun 2000 09:39:29 -0400 X-Lotus-FromDomain: IBMUS To: DHCPv4 discussion list Message-ID: <8525690D.004B042A.00@D51MTA04.pok.ibm.com> Date: Thu, 29 Jun 2000 08:39:25 -0500 Subject: Bootp "sname" field Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Reply-To: hoyoung@us.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN It seems to me RFC951 indicates that a client can specify a server name by using "sname" field. My question is that if a client directly requests a server that's not on the same subnet with the client, it will have to go through a router, will then the router still be considered as a relay agent? For example, I have two ranges of class c addresses. One is used for static (let's say it's 200.10.11, with 200.10.11.x as router interface), the other (let's see it's 200.10.10)is used for DHCP/Bootp. I have 200.10.10.x configured as relay agent for all 200.10.10.0. In above scenario, would the packets from the client goes through 200.10.10.x interface or go through 200.10.11.x interface? Thanks! HDay From owner-dhcp-v4@bucknell.edu Thu Jun 29 10:26:56 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08837 for ; Thu, 29 Jun 2000 10:26:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5TEMMW30947; Thu, 29 Jun 2000 10:22:22 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5TEMEW02994 for ; Thu, 29 Jun 2000 10:22:15 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Thu, 29 Jun 2000 10:21:59 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBE9D@lespaul.process.com> From: Bernie Volz To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: RE: Bootp "sname" field Date: Thu, 29 Jun 2000 10:21:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Volz@ipworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN See section 7.3, that might help explain some of the behavoir? I'm not exactly clear on your configuration. Where are you using BOOTP? If you're using BOOTP on the .10. network, then the relay agent would forward the packets to one or more BOOTP Servers. Section 7.3 then explains how a bootp server might handle this. - Bernie Volz -----Original Message----- From: hoyoung@us.ibm.com [mailto:hoyoung@us.ibm.com] Sent: Thursday, June 29, 2000 9:39 AM To: DHCPv4 discussion list Subject: Bootp "sname" field It seems to me RFC951 indicates that a client can specify a server name by using "sname" field. My question is that if a client directly requests a server that's not on the same subnet with the client, it will have to go through a router, will then the router still be considered as a relay agent? For example, I have two ranges of class c addresses. One is used for static (let's say it's 200.10.11, with 200.10.11.x as router interface), the other (let's see it's 200.10.10)is used for DHCP/Bootp. I have 200.10.10.x configured as relay agent for all 200.10.10.0. In above scenario, would the packets from the client goes through 200.10.10.x interface or go through 200.10.11.x interface? Thanks! HDay From owner-dhcp-v4@bucknell.edu Thu Jun 29 10:31:14 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08995 for ; Thu, 29 Jun 2000 10:31:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5TESoW08333; Thu, 29 Jun 2000 10:28:50 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5TESZW32245 for ; Thu, 29 Jun 2000 10:28:36 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Thu, 29 Jun 2000 10:28:20 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBE9F@lespaul.process.com> From: Bernie Volz To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: RE: Use of DHCID in draft-ietf-dhc-dhcp-dns-12 Date: Thu, 29 Jun 2000 10:28:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Volz@ipworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Jack: I believe the general concept is that the DHCP Server "owns" the address and therefore it "knows" who is using the address and the name associated with that address. That is why there is no need to check the DHCID information (it perhaps even need not store DHCID, but it may be useful information for administrators). The name (A RR), on the other hand, is owned by ???. Thus, the checks there have to be much more involved. I can't answer the question regarding DHCID. Likely, it is waiting for this draft to finalize? - Bernie Volz IPWorks, Inc -----Original Message----- From: jjcorc@us.ibm.com [mailto:jjcorc@us.ibm.com] Sent: Tuesday, June 27, 2000 2:26 PM To: DHCPv4 discussion list Subject: Use of DHCID in draft-ietf-dhc-dhcp-dns-12 I have several questions concerning the use of the DHCID defined in the DHCP-DNS interaction draft, draft-ietf-dhc-dhcp-dns-12.txt. First, in section 8.2 it states.... "The DHCP server submits a DNS query which deletes all of the PTR RRs associated with the lease IP address, and adds a PTR RR whose data is the client's (possibly disambiguated) host name. The server also adds a DHCID RR specified in Section 4.3." It seems that the DHCID was created as a way to enforce a policy concerning name collisions. As such, most of the discussion in the draft centers around how the DHCID is used in performing A RR updates. Section 8.1 describes the prerequisite checking which takes place for A RR updates and mentions the decision that must be made (based on an administrative policy) as to whether an A RR should be updated if an existing A RR is found. However, for PTR record updates, it simply states that the server adds the DHCID RR (without any such pre-requisite checking and policy decisions). Therefore, what is the purpose of adding a DHCID RR when adding a PTR record? Secondly, what is the status of DHCID? I have been unable to find reference 12 (draft-ietf-dnsext-dhcid-rr-*) mentioned in the DHCP-DNS interaction draft. Does anyone know of any DNS servers that support a DHCID RR or if they intend to support it in the future? Thanks in advance for your responses! Jack Corcoran Email: jjcorc@us.ibm.com Ph 607-752-5570, T/L 852-5570, FAX: 607-752-5421 From owner-dhcp-v4@bucknell.edu Thu Jun 29 10:45:49 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09439 for ; Thu, 29 Jun 2000 10:45:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5TEiXW13373; Thu, 29 Jun 2000 10:44:33 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5TEiVW14512 for ; Thu, 29 Jun 2000 10:44:31 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA366956; Thu, 29 Jun 2000 10:42:35 -0400 From: hoyoung@us.ibm.com Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.9) with SMTP id KAA219218; Thu, 29 Jun 2000 10:44:28 -0400 Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525690D.0050F83B ; Thu, 29 Jun 2000 10:44:24 -0400 X-Lotus-FromDomain: IBMUS To: DHCPv4 discussion list cc: DHCPv4 discussion list Message-ID: <8525690D.0050F5C5.00@D51MTA04.pok.ibm.com> Date: Thu, 29 Jun 2000 09:44:20 -0500 Subject: RE: Bootp "sname" field Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Reply-To: hoyoung@us.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN well, let's see if I can explain a bit better. If a bootp Client sends out a unicast packet to a bootp server which is not on the same subnet as the client, then this packet will have to be forwarded by a router who knows where the server is at. Let's say if I have to control which subnet can use bootp, and I have both .10 (dhcp/bootp) and .11(static) configured for subnets that are enabled for bootp, but only .11 (for static only) configured for subnets that aren't supposed to use bootp. If a client on the .11 subnet knows the bootp server name, it will be able to use the .11 interface on the router to get to the server and get configured by the server. Is this right? If so, then I won't be able to control the clients on the static only subnet from using bootp. Is this correct? Thanks Hday Bernie Volz on 06/29/2000 09:21:58 AM To: Hannah O Day/Rochester/IBM@IBMUS cc: DHCPv4 discussion list Subject: RE: Bootp "sname" field See section 7.3, that might help explain some of the behavoir? I'm not exactly clear on your configuration. Where are you using BOOTP? If you're using BOOTP on the .10. network, then the relay agent would forward the packets to one or more BOOTP Servers. Section 7.3 then explains how a bootp server might handle this. - Bernie Volz -----Original Message----- From: hoyoung@us.ibm.com [mailto:hoyoung@us.ibm.com] Sent: Thursday, June 29, 2000 9:39 AM To: DHCPv4 discussion list Subject: Bootp "sname" field It seems to me RFC951 indicates that a client can specify a server name by using "sname" field. My question is that if a client directly requests a server that's not on the same subnet with the client, it will have to go through a router, will then the router still be considered as a relay agent? For example, I have two ranges of class c addresses. One is used for static (let's say it's 200.10.11, with 200.10.11.x as router interface), the other (let's see it's 200.10.10)is used for DHCP/Bootp. I have 200.10.10.x configured as relay agent for all 200.10.10.0. In above scenario, would the packets from the client goes through 200.10.10.x interface or go through 200.10.11.x interface? Thanks! HDay From owner-dhcp-v4@bucknell.edu Thu Jun 29 10:56:25 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09853 for ; Thu, 29 Jun 2000 10:56:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5TEtgW30778; Thu, 29 Jun 2000 10:55:42 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5TEtSW09802 for ; Thu, 29 Jun 2000 10:55:28 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Thu, 29 Jun 2000 10:55:13 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBEA2@lespaul.process.com> From: Bernie Volz To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: RE: Bootp "sname" field Date: Thu, 29 Jun 2000 10:55:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Volz@ipworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This still sounds like a confusing configuration. Not sure I fully understand it. By "static", I assume you mean the addresses are preconfigured on the clients. And, I assume your clients are on BOTH subnets? I'm not sure what you mean by "control the clients on the static only subnet from using bootp". The bootp client also likely needs to be a bit special since it needs to send the MAC address of the .10. interface, yet it will send the packet out the .11. interface (since it knows the server's address, right). With bootp, you usually have a mac address to ip address list, so just don't put the .11. interface mac addresses in the table. Or, are you really trying to use dhcp? - Bernie -----Original Message----- From: hoyoung@us.ibm.com [mailto:hoyoung@us.ibm.com] Sent: Thursday, June 29, 2000 10:44 AM To: Bernie Volz Cc: DHCPv4 discussion list Subject: RE: Bootp "sname" field well, let's see if I can explain a bit better. If a bootp Client sends out a unicast packet to a bootp server which is not on the same subnet as the client, then this packet will have to be forwarded by a router who knows where the server is at. Let's say if I have to control which subnet can use bootp, and I have both .10 (dhcp/bootp) and .11(static) configured for subnets that are enabled for bootp, but only .11 (for static only) configured for subnets that aren't supposed to use bootp. If a client on the .11 subnet knows the bootp server name, it will be able to use the .11 interface on the router to get to the server and get configured by the server. Is this right? If so, then I won't be able to control the clients on the static only subnet from using bootp. Is this correct? Thanks Hday Bernie Volz on 06/29/2000 09:21:58 AM To: Hannah O Day/Rochester/IBM@IBMUS cc: DHCPv4 discussion list Subject: RE: Bootp "sname" field See section 7.3, that might help explain some of the behavoir? I'm not exactly clear on your configuration. Where are you using BOOTP? If you're using BOOTP on the .10. network, then the relay agent would forward the packets to one or more BOOTP Servers. Section 7.3 then explains how a bootp server might handle this. - Bernie Volz -----Original Message----- From: hoyoung@us.ibm.com [mailto:hoyoung@us.ibm.com] Sent: Thursday, June 29, 2000 9:39 AM To: DHCPv4 discussion list Subject: Bootp "sname" field It seems to me RFC951 indicates that a client can specify a server name by using "sname" field. My question is that if a client directly requests a server that's not on the same subnet with the client, it will have to go through a router, will then the router still be considered as a relay agent? For example, I have two ranges of class c addresses. One is used for static (let's say it's 200.10.11, with 200.10.11.x as router interface), the other (let's see it's 200.10.10)is used for DHCP/Bootp. I have 200.10.10.x configured as relay agent for all 200.10.10.0. In above scenario, would the packets from the client goes through 200.10.10.x interface or go through 200.10.11.x interface? Thanks! HDay From owner-dhcp-v4@bucknell.edu Thu Jun 29 15:08:50 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17992 for ; Thu, 29 Jun 2000 15:08:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5TJ5UW31993; Thu, 29 Jun 2000 15:05:30 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5TJ5SW25649 for ; Thu, 29 Jun 2000 15:05:28 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dhcp-218.rc.vix.com [204.152.187.218]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id UAA28408; Wed, 28 Jun 2000 20:25:26 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id MAA00613; Thu, 29 Jun 2000 12:05:53 -0700 (MST) Message-Id: <200006291905.MAA00613@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Bootp "sname" field In-Reply-To: Message from hoyoung@us.ibm.com of "Thu, 29 Jun 2000 09:44:20 EST." <8525690D.0050F5C5.00@D51MTA04.pok.ibm.com> Date: Thu, 29 Jun 2000 12:05:53 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Relay agents are only relevant for bootp. sname is the tftp boot server. Once you've gotten an IP address and default route using bootp, you can just use normal IP routing to get to a BOOTP server on another network. So this is a non-problem, if I understand what you are asking. _MelloN_ From owner-dhcp-v4@bucknell.edu Thu Jun 29 15:26:49 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18319 for ; Thu, 29 Jun 2000 15:26:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5TJOkW32639; Thu, 29 Jun 2000 15:24:46 -0400 (EDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5TJOfW08976 for ; Thu, 29 Jun 2000 15:24:41 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA206822 for ; Thu, 29 Jun 2000 15:22:46 -0400 From: hoyoung@us.ibm.com Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.9) with SMTP id PAA147622 for ; Thu, 29 Jun 2000 15:24:38 -0400 Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525690D.006A9FE2 ; Thu, 29 Jun 2000 15:24:37 -0400 X-Lotus-FromDomain: IBMUS To: DHCPv4 discussion list Message-ID: <8525690D.006A9E16.00@D51MTA04.pok.ibm.com> Date: Thu, 29 Jun 2000 14:24:37 -0500 Subject: Re: Bootp "sname" field Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Reply-To: hoyoung@us.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Thanks all of you who responded. I think I got my question answered... Hday From owner-dhcp-v4@bucknell.edu Thu Jun 29 17:34:04 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20542 for ; Thu, 29 Jun 2000 17:34:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5TLSPW15419; Thu, 29 Jun 2000 17:28:26 -0400 (EDT) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5TLSGW27057 for ; Thu, 29 Jun 2000 17:28:16 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id OAA12072 for ; Thu, 29 Jun 2000 14:28:15 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 29 Jun 2000 14:28:14 -0700 Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37]) by scv2.apple.com (8.9.3/8.9.3) with SMTP id OAA08209 for ; Thu, 29 Jun 2000 14:28:21 -0700 (PDT) Message-Id: <200006292128.OAA08209@scv2.apple.com> Subject: ASCII text message option (option 56) Date: Thu, 29 Jun 2000 14:29:13 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: DHCPv4 discussion list Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Reply-To: cheshire@apple.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Here at Apple, we're using the DHCP ASCII text message option (option 56) to display a "welcome message" when a user first connects to the network and acquires a DHCP address (a bit like the "Message Of The Day" when you log on to a unix system). However, in this modern world, some people want more than plain ascii text. They want the DHCP server to provide the URL of a web page that the client machine should fetch, render, and display in a window. I see two ways to do this: 1. Define a new DHCP option code for an explicit welcome page URL. 2. Overload the DHCP ASCII text message option, so that if you set the text message to be a string of the form: then the client recogises this string as "special" and instead of displaying that actual text in the window, it parses the URL and displays the web page instead. Solution 1 is better, but DHCP is running out of option codes, and the process of getting new ones allocated can be slow. Apple want to ship code that does this, like, yesterday. Solution 2 is ugly, but easy to do. Comments? Stuart Cheshire * Wizard Without Portfolio, Apple Computer From owner-dhcp-v4@bucknell.edu Thu Jun 29 17:59:02 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21013 for ; Thu, 29 Jun 2000 17:59:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5TLv9W09992; Thu, 29 Jun 2000 17:57:09 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5TLuwW16036 for ; Thu, 29 Jun 2000 17:56:58 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dhcp-218.rc.vix.com [204.152.187.218]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id XAA28802; Wed, 28 Jun 2000 23:16:55 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id OAA01107; Thu, 29 Jun 2000 14:57:22 -0700 (MST) Message-Id: <200006292157.OAA01107@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: ASCII text message option (option 56) In-Reply-To: Message from Stuart Cheshire of "Thu, 29 Jun 2000 14:29:13 MST." <200006292128.OAA08209@scv2.apple.com> Date: Thu, 29 Jun 2000 14:57:22 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I think it's a brilliant idea, but encourage you to write a draft and submit it to the WG rather than overloading the text message option. I'd also suggest in your security section that you say that the web browser that fetches this page MUST NOT (or at the very least SHOULD NOT) reveal any information about the user when it fetches the page. If you write up the draft, I'll second it, and argue for a quick turnaround. I can definitely think of applications for this, and if you implement it, everybody else probably will too! :') _MelloN_ From owner-dhcp-v4@bucknell.edu Thu Jun 29 18:01:44 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21123 for ; Thu, 29 Jun 2000 18:01:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5TLxuW13323; Thu, 29 Jun 2000 17:59:56 -0400 (EDT) Received: from mail.ultradns.com (IDENT:qmailr@[64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5TLwtW10698 for ; Thu, 29 Jun 2000 17:58:55 -0400 (EDT) Received: (qmail 510 invoked from network); 29 Jun 2000 22:05:37 -0000 Received: from ip-216-73-154-39.vantas.net (HELO ULTRADNS6PMNFK) (216.73.154.39) by mail.ultradns.com with SMTP; 29 Jun 2000 22:05:37 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: ASCII text message option (option 56) Date: Thu, 29 Jun 2000 15:04:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200006292128.OAA08209@scv2.apple.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > Here at Apple, we're using the DHCP ASCII text message option (option 56) > to display a "welcome message" when a user first connects to the network > and acquires a DHCP address (a bit like the "Message Of The Day" when you > log on to a unix system). > ...you're actually missing the point of this option a bit, I believe. [Ralph, please jump in here and correct any misstatements I make!] ...this option is more typically used to convey descriptive error messages when the server NAKs a client request. That's not to say that your use is wrong, but it does reflect my view that DHCP is an underlying service, not a replacement for MOTD or login banner messages. ...as we go forward, the English-centric nature of many network protocols will change, and with it, NVT-ASCII for messages will probably change to accommodate non-English speakers. ...I would oppose the creation of a new option for such a limited purpose as you are proposing, because I doubt its value in general, and don't believe the more common clients will handle it in a universally-acceptable way [having said that, I probably should run out and test my assertion....] ...I also oppose overloading it with a URL through redefinition of the option: not because a URL can't be expressed in an NVT-ASCII field, but because that would require client modifications to utilize effectively. As far as Apple shipping clients and servers that make some appropriate use of the existing option, and even recognize a URL embedded in it, I don't believe such a use is contrary to the nature of the option -- just don't expect non-Apple clients to effectively use this mechanism for broadcasting messages to your client users. --Barr From owner-dhcp-v4@bucknell.edu Thu Jun 29 18:10:51 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21274 for ; Thu, 29 Jun 2000 18:10:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5TM6mW07045; Thu, 29 Jun 2000 18:06:48 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5TM6kW02387 for ; Thu, 29 Jun 2000 18:06:46 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dhcp-218.rc.vix.com [204.152.187.218]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id XAA28837; Wed, 28 Jun 2000 23:25:14 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id PAA01169; Thu, 29 Jun 2000 15:05:41 -0700 (MST) Message-Id: <200006292205.PAA01169@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: ASCII text message option (option 56) In-Reply-To: Message from "Barr Hibbs" of "Thu, 29 Jun 2000 15:04:14 MST." Date: Thu, 29 Jun 2000 15:05:41 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > ...I would oppose the creation of a new option for such a limited purpose as Limited purpose? What about as the basis for a network sign-on? The potential here is huge, and IMHO entirely appropriate for DHCP. Where else would you put this? Invent an entirely new protocol? _MelloN_ From owner-dhcp-v4@bucknell.edu Thu Jun 29 18:21:16 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21361 for ; Thu, 29 Jun 2000 18:21:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5TMJFW19543; Thu, 29 Jun 2000 18:19:15 -0400 (EDT) Received: from mail.ultradns.com (IDENT:qmailr@[64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5TMJ1W31530 for ; Thu, 29 Jun 2000 18:19:02 -0400 (EDT) Received: (qmail 845 invoked from network); 29 Jun 2000 22:25:44 -0000 Received: from ip-216-73-154-39.vantas.net (HELO ULTRADNS6PMNFK) (216.73.154.39) by mail.ultradns.com with SMTP; 29 Jun 2000 22:25:44 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: ASCII text message option (option 56) Date: Thu, 29 Jun 2000 15:24:21 -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.2911.0) In-Reply-To: <200006292205.PAA01169@grosse.bisbee.fugue.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > > ...I would oppose the creation of a new option for such a > limited purpose as > > Limited purpose? What about as the basis for a network sign-on? > The potential here is huge, and IMHO entirely appropriate for DHCP. > Where else would you put this? Invent an entirely new protocol? > ...maybe I'm just a doddering old curmudgeon, but I don't see the value here. I really don't see the need for using DHCP as a network messaging system. As for network sign-on, look at the AAA (Accounting, Authentication, and Authorization) working group to see how network sign-on is being approached. --Barr From owner-dhcp-v4@bucknell.edu Thu Jun 29 18:51:05 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21889 for ; Thu, 29 Jun 2000 18:51:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5TMkqW13199; Thu, 29 Jun 2000 18:46:52 -0400 (EDT) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5TMkkW01683 for ; Thu, 29 Jun 2000 18:46:46 -0400 (EDT) Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id PAA23793; Thu, 29 Jun 2000 15:46:02 -0700 (PDT) Message-Id: <4.1.20000629183626.00b6e610@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 29 Jun 2000 18:45:49 -0400 To: DHCPv4 discussion list From: John Schnizlein Subject: AAA - was RE: ASCII text message option (option 56) In-Reply-To: References: <200006292205.PAA01169@grosse.bisbee.fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: jschnizl@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 03:24 PM 06/29/2000 -0700, Barr Hibbs wrote: >... I don't see the value here. >I really don't see the need for using DHCP as a network messaging system. >As for network sign-on, look at the AAA (Accounting, Authentication, >and Authorization) working group to see how network sign-on is being >approached. Are you advocating Diameter instead of DHCP to identify and give network parameters to hosts? While I agree that convergence between traditionally separate dial-up and LAN-attached startup parameters is inevitable, it is not clear that the DCHP WG should just defer to the Diameter WG. (-: Sorry, I guess it is actually still called the AAA WG. :-) I expected more of the time-honored competition between approaches. John going back to lurking mode now .. From owner-dhcp-v4@bucknell.edu Thu Jun 29 18:56:04 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21936 for ; Thu, 29 Jun 2000 18:56:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5TMs9W20789; Thu, 29 Jun 2000 18:54:09 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5TMs0W25461 for ; Thu, 29 Jun 2000 18:54:00 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dhcp-218.rc.vix.com [204.152.187.218]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id AAA28938; Thu, 29 Jun 2000 00:13:58 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id PAA01256; Thu, 29 Jun 2000 15:54:25 -0700 (MST) Message-Id: <200006292254.PAA01256@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: ASCII text message option (option 56) In-Reply-To: Message from "Barr Hibbs" of "Thu, 29 Jun 2000 15:24:21 MST." Date: Thu, 29 Jun 2000 15:54:25 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > ...maybe I'm just a doddering old curmudgeon, but I don't see the value > here. I wouldn't describe you as a doddering curmudgeon, but you do indeed seem to be missing the value of this. > I really don't see the need for using DHCP as a network messaging > system. As for network sign-on, look at the AAA (Accounting, > Authentication, and Authorization) working group to see how network sign-on > is being approached. That was probably a poor choice of words. I'm talking about network registration. You walk into a new site, plug in your laptop, and bang, up comes a registration page where you can identify yourself to the network and potentially register so that you can get access to it. I'm not talking about network signon in the sense of a known user authenticating him- or herself. This sort of thing would be a big boon for cable modem and DSL ISPs, for example, and could also be useful for things like the much-talked-about but rarely-seen airport 100baseT service. More to the point, this is an existing application that people already do - what Stuart is proposing would merely make telling the end-user how to register a lot easier - essentially, they would be able to say "just plug it in and follow the instructions that appear on your screen." I don't _think_ the AAA people are doing anything like this. _MelloN_ From owner-dhcp-v4@bucknell.edu Fri Jun 30 10:06:34 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17835 for ; Fri, 30 Jun 2000 10:06:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5UE1xW28636; Fri, 30 Jun 2000 10:01:59 -0400 (EDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5UE1pW04653 for ; Fri, 30 Jun 2000 10:01:51 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA244620 for ; Fri, 30 Jun 2000 09:59:55 -0400 From: jjcorc@us.ibm.com Received: from D51MTA06.pok.ibm.com (d51mta06.pok.ibm.com [9.117.200.34]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.9) with SMTP id KAA234612 for ; Fri, 30 Jun 2000 10:01:48 -0400 Received: by D51MTA06.pok.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525690E.004D1129 ; Fri, 30 Jun 2000 10:01:46 -0400 X-Lotus-FromDomain: IBMUS To: DHCPv4 discussion list Message-ID: <8525690E.004D0F6C.00@D51MTA06.pok.ibm.com> Date: Fri, 30 Jun 2000 09:01:46 -0500 Subject: RE: Use of DHCID in draft-ietf-dhc-dhcp-dns-12 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Reply-To: jjcorc@us.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Thanks for the reply. I do understand the concept of who owns each record. I just didn't see a purpose for the DHCID associated with the PTR, other than as you suggested, it being a mechanism for an administrator to try and tell who updated the record. Although, if it is "scrambled" via a hash algorithm, I'm still not sure how useful it would be. I guess I was just looking for a more definitive answer, like "oh that's there because in the next version of the draft you'll see...." or "Yes you are correct, and there really isn't a need for a DHCID record associated with a PTR record." Presently, since BIND8 DNS doesn't support DHCID (at least to my knowledge), does anyone see a problem with using the KEY RR in place of the DHCID which was the proposed method in a previous version of the subject draft? At least that way a DHCP server capable of dynamic DNS updates could be developed now that would interface to any BIND 8 DNS server. Jack Corcoran jjcorc@us.ibm.com Ph 607-752-5570, T/L 852-5570, FAX: 607-752-5421 From owner-dhcp-v4@bucknell.edu Fri Jun 30 11:00:48 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18800 for ; Fri, 30 Jun 2000 11:00:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5UEuOW19595; Fri, 30 Jun 2000 10:56:24 -0400 (EDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5UEuAW01625 for ; Fri, 30 Jun 2000 10:56:11 -0400 (EDT) Received: from earth.research.telcordia.com (earth [192.4.18.66]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e5UEtsF13575 for ; Fri, 30 Jun 2000 10:55:54 -0400 (EDT) Sender: owner-dhcp-v4@bucknell.edu Message-ID: <395CB4F8.50B5C65F@earth.research.telcordia.com> Date: Fri, 30 Jun 2000 10:55:54 -0400 From: Tony McAuley Organization: Telcordia X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 4.1.4 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: Re: ASCII text message option (option 56) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: mcauley@earth.research.telcordia.com X-Sender: mcauley@research.telcordia.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit I too like that the idea of a "welcome message" and "network sign-on." However, I agree with Barr Hibbs' comments on not putting it into DHCP, but into a separate registration (user-AAA) protocol, with DHCP only giving the IP address of the domain registration agent. Our motivation comes form liking the idea of using DHCP in 3G+ IP wireless networks. We now believe that registration and configuration should be done in two independent protocols, such as: . DHCP/DRCP for configuring a node with a new IP address when it moves to a new subnet, ... and optionally the IP address of a "Domain Registration Agent." . URAP (User Registration and Authentication Protocol) sent to the "Domain Registration Agent" when a node first moves into a domain. URAP then interfaces to inter-domain AAA protocols such as DIAMETER. RADIUS/DIAMETER main user interface Today is through PPP (which also does configuration and framing). URAP is a new idea (so far as we know the AAA group has not yet looked at a user-AAA protocol like this for IPv4). Appreciate any thoughts on the idea. Thanks Tony ---------------------------------------------------------------------------- Anthony J. McAuley email: mcauley@research.telcordia.com MCC 1C235B, Telcordia Technologies phone: +1 973 829 4698 445 South Street, Morristown, NJ 07960 fax: +1 973 829 5888 ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- > Date: Thu, 29 Jun 2000 15:54:25 -0700 > From: Ted Lemon > > That was probably a poor choice of words. I'm talking about network > registration. You walk into a new site, plug in your laptop, and > bang, up comes a registration page where you can identify yourself to > the network and potentially register so that you can get access to > it. I'm not talking about network signon in the sense of a known > user authenticating him- or herself. > > This sort of thing would be a big boon for cable modem and DSL ISPs, > for example, and could also be useful for things like the > much-talked-about but rarely-seen airport 100baseT service. More to > the point, this is an existing application that people already do - > what Stuart is proposing would merely make telling the end-user how to > register a lot easier - essentially, they would be able to say "just > plug it in and follow the instructions that appear on your screen." > I don't _think_ the AAA people are doing anything like this. ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- > Date: Thu, 29 Jun 2000 18:45:49 -0400 > From: John Schnizlein > Subject: AAA - was RE: ASCII text message option (option 56) > > Are you advocating Diameter instead of DHCP to identify and give network > parameters to hosts? While I agree that convergence between traditionally > separate dial-up and LAN-attached startup parameters is inevitable, it is > not clear that the DCHP WG should just defer to the Diameter WG. > (-: Sorry, I guess it is actually still called the AAA WG. :-) > I expected more of the time-honored competition between approaches. ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- > From: "Barr Hibbs" > Date: Thu, 29 Jun 2000 15:24:21 -0700 > > I really don't see the need for using DHCP as a network messaging > system. As for network sign-on, look at the AAA (Accounting, > Authentication, and Authorization) working group to see how network sign-on > is being approached. ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- > Date: Thu, 29 Jun 2000 15:05:41 -0700 > From: Ted Lemon > > Limited purpose? What about as the basis for a network sign-on? > The potential here is huge, and IMHO entirely appropriate for DHCP. > Where else would you put this? Invent an entirely new protocol? ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- > From: "Barr Hibbs" > Date: Thu, 29 Jun 2000 15:04:14 -0700 > > ...you're actually missing the point of this option a bit, I believe. > [Ralph, please jump in here and correct any misstatements I make!] > > ...this option is more typically used to convey descriptive error messages > when the server NAKs a client request. That's not to say that your use is > wrong, but it does reflect my view that DHCP is an underlying service, not a > replacement for MOTD or login banner messages. > > ...as we go forward, the English-centric nature of many network protocols > will change, and with it, NVT-ASCII for messages will probably change to > accommodate non-English speakers. > > ...I would oppose the creation of a new option for such a limited purpose as > you are proposing, because I doubt its value in general, and don't believe > the more common clients will handle it in a universally-acceptable way > [having said that, I probably should run out and test my assertion....] > > ...I also oppose overloading it with a URL through redefinition of the > option: not because a URL can't be expressed in an NVT-ASCII field, but > because that would require client modifications to utilize effectively. As > far as Apple shipping clients and servers that make some appropriate use of > the existing option, and even recognize a URL embedded in it, I don't > believe such a use is contrary to the nature of the option -- just don't > expect non-Apple clients to effectively use this mechanism for broadcasting > messages to your client users. > > --Barr ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- > Date: Thu, 29 Jun 2000 14:57:22 -0700 > From: Ted Lemon > > I think it's a brilliant idea, but encourage you to write a draft and > submit it to the WG rather than overloading the text message option. > I'd also suggest in your security section that you say that the web > browser that fetches this page MUST NOT (or at the very least SHOULD > NOT) reveal any information about the user when it fetches the page. > If you write up the draft, I'll second it, and argue for a quick > turnaround. I can definitely think of applications for this, and if > you implement it, everybody else probably will too! :') ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- > From: Stuart Cheshire > Date: Thu, 29 Jun 2000 14:29:13 -0700 > > Here at Apple, we're using the DHCP ASCII text message option (option 56) > to display a "welcome message" when a user first connects to the network > and acquires a DHCP address (a bit like the "Message Of The Day" when you > log on to a unix system). > > However, in this modern world, some people want more than plain ascii > text. They want the DHCP server to provide the URL of a web page that the > client machine should fetch, render, and display in a window. > > I see two ways to do this: > > 1. Define a new DHCP option code for an explicit welcome page URL. > > 2. Overload the DHCP ASCII text message option, so that if you set the > text message to be a string of the form: > > > > then the client recogises this string as "special" and instead of > displaying that actual text in the window, it parses the URL and displays > the web page instead. > > Solution 1 is better, but DHCP is running out of option codes, and the > process of getting new ones allocated can be slow. Apple want to ship > code that does this, like, yesterday. > > Solution 2 is ugly, but easy to do. > > Comments? ---------------------------------------------------------------------------- From owner-dhcp-v4@bucknell.edu Fri Jun 30 12:45:51 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21986 for ; Fri, 30 Jun 2000 12:45:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5UGfSW08216; Fri, 30 Jun 2000 12:41:28 -0400 (EDT) Received: from Arachnid.NTRG.com ([209.31.7.46]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5UGfHW13539 for ; Fri, 30 Jun 2000 12:41:18 -0400 (EDT) Received: from ehsco.com (nat-external.ehsco.com [209.31.7.42]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 661 for ; Fri, 30 Jun 2000 09:41:15 -0700 Message-ID: <395CCDAA.63A52823@ehsco.com> Date: Fri, 30 Jun 2000 09:41:14 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 CC: DHCPv4 discussion list Subject: Re: ASCII text message option (option 56) References: <395CB4F8.50B5C65F@earth.research.telcordia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: ehall@ehsco.com Sender: owner-dhcp-v4@bucknell.edu To: DHCPv4 discussion list X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit MOTD messages should either be associated with a login prompt or with a system messaging protocol, but not with system boot. Messages like "printer nn is being serviced today" are messages that all users that login to the network should see, not something that only the first user to login on that system should see. Conversely, something like "company meeting at 3pm" may be something that you want to broadcast or multicast to all users a couple of times during the day, not something you want to rely on a week-old DHCP lease for. Unless you are tying DHCP leases to logins somehow then DHCP messages just aren't the best place for this kind of notification. In general, I'd say that network-wide announcements should either use a multicast messaging service (a wall derivative or IMSP or something similar that allows for easy sending by admins, and easy ignoring by users) or should use login banners as part of an access protocol. For automated network-access events (plugging in to airport networks), that sounds good but it's such a special case scenario I'm not sure. It doesn't make sense for corporate or home users if the leases renew overnight, or if the cable modem is renewing a lease that the user never sees because their PC is NAT-attached. There are a lot of assumptions all around that, and the special case where it would actually be meaningful is extremely narrow... I'd say if there's a really good reason for it, then overflow the text but please document the usage somewhere and keep it as simple as possible. But I am having trouble thinking of a good reason for using DHCP for this. Stuart, can you share with us what the idea is in a general way? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-dhcp-v4@bucknell.edu Fri Jun 30 14:04:41 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23314 for ; Fri, 30 Jun 2000 14:04:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5UHwMW09625; Fri, 30 Jun 2000 13:58:22 -0400 (EDT) Received: from honts307.wal-mart.com (honts307.wal-mart.com [146.132.234.37]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5UHwFW14812 for ; Fri, 30 Jun 2000 13:58:15 -0400 (EDT) Received: from honts385.homeoffice.wal-mart.com (fwnts002.wal-mart.com [146.132.235.8]) by honts307.wal-mart.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id N5BXLS4M; Fri, 30 Jun 2000 13:02:05 -0500 Received: from honts305.homeoffice.wal-mart.com (unverified) by honts385.homeoffice.wal-mart.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Fri, 30 Jun 2000 12:51:10 -0500 Received: by HONTS305.homeoffice.wal-mart.com with Internet Mail Service (5.5.2650.21) id ; Fri, 30 Jun 2000 12:57:59 -0500 Message-ID: From: Nathan Lane To: DHCPv4 discussion list Subject: RE: ASCII text message option (option 56) Date: Fri, 30 Jun 2000 12:57:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Reply-To: ndlane@wal-mart.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN But how does AAA work when the DHCP server has already denied any network connectivity at all? Or placed you in a different class (i.e., more limited) of service than you expected? This option is ideal for it...I could put up a message saying "Oops, you plugged your Mac into a network that doesn't have Appletalk turned on." This option is something I can use right now, in any form and applies to me both in the limited sense that Apple is doing it and, if others adopt it, I could apply it more generally. -Nathan Lane Wal-Mart Stores, Inc. (501) 277-5786 > -----Original Message----- > From: Barr Hibbs [SMTP:rbhibbs@ultraDNS.com] > Sent: Thursday, June 29, 2000 5:24 PM > To: DHCPv4 discussion list > Subject: RE: ASCII text message option (option 56) > > > > > ...I would oppose the creation of a new option for such a > > limited purpose as > > > > Limited purpose? What about as the basis for a network sign-on? > > The potential here is huge, and IMHO entirely appropriate for DHCP. > > Where else would you put this? Invent an entirely new protocol? > > > > ...maybe I'm just a doddering old curmudgeon, but I don't see the value > here. I really don't see the need for using DHCP as a network messaging > system. As for network sign-on, look at the AAA (Accounting, > Authentication, and Authorization) working group to see how network > sign-on > is being approached. > > --Barr ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please notify the Wal-Mart E-mail administrator at " postmaster@wal-mart.com ". ********************************************************************** From owner-dhcp-v4@bucknell.edu Fri Jun 30 14:24:27 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23521 for ; Fri, 30 Jun 2000 14:24:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5UIMXW11389; Fri, 30 Jun 2000 14:22:33 -0400 (EDT) Received: from mail.ultradns.com (IDENT:qmailr@[64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5UIMSW11402 for ; Fri, 30 Jun 2000 14:22:28 -0400 (EDT) Received: (qmail 10272 invoked from network); 30 Jun 2000 18:29:21 -0000 Received: from ip-216-73-154-39.vantas.net (HELO ULTRADNS6PMNFK) (216.73.154.39) by mail.ultradns.com with SMTP; 30 Jun 2000 18:29:21 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: ASCII text message option (option 56) Date: Fri, 30 Jun 2000 11:28:04 -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.2911.0) In-reply-to: Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Nathan Lane > Sent: Friday, June 30, 2000 10:58 AM > To: DHCPv4 discussion list > But how does AAA work when the DHCP server has already denied any network > connectivity at all? Or placed you in a different class (i.e., > more limited) of service than you expected? > ...admittedly, if DHCP doesn't provide an IP address lease to a client there is no way for AAA to work, although if a DHCP server sends a NAK (rather than just ignoring the DISCOVER) option 56 can provide useful information. I don't understand your point about class of service: DHCP really doesn't support that functionality in the way I understand it (e.g., delay, packet loss, and bandwidth characteristics.) > This option is ideal for it...I could put up a message saying "Oops, you > plugged your Mac into a network that doesn't have Appletalk turned on." > ...forgive me, Nathan, but how can DHCP do this, given that it is largely protocol independent? I don't think we should be cognizant of anything in the protocol stack above the IP layer. > This option is something I can use right now, in any form and > applies to me both in the limited sense that Apple is doing it > and, if others adopt it, I could apply it more generally. > ...I don't see how we could implement this without some fairly fundamental changes to the protocol: specifically, requiring the DHCP server to reply (with a NAK or a new message type) rather than ignoring DISCOVERs and REQUESTs in some circumstances, and requiring DHCP clients to react to the contents of this option (rather than merely displaying it, would have to start a web browser following Stuart's suggestion, but without an IP address, how does that work?) --Barr From owner-dhcp-v4@bucknell.edu Fri Jun 30 14:38:39 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23819 for ; Fri, 30 Jun 2000 14:38:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5UIWkW11706; Fri, 30 Jun 2000 14:32:46 -0400 (EDT) Received: from honts308.wal-mart.com (honts308.wal-mart.com [146.132.234.38]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5UIWZW08253 for ; Fri, 30 Jun 2000 14:32:35 -0400 (EDT) Received: from honts386.homeoffice.wal-mart.com (fwnts002.wal-mart.com [146.132.235.8]) by honts308.wal-mart.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id N6GR2NPP; Fri, 30 Jun 2000 13:38:55 -0500 Received: from honts305.homeoffice.wal-mart.com (unverified) by honts386.homeoffice.wal-mart.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Fri, 30 Jun 2000 13:29:03 -0500 Received: by HONTS305.homeoffice.wal-mart.com with Internet Mail Service (5.5.2650.21) id ; Fri, 30 Jun 2000 13:32:12 -0500 Message-ID: From: Nathan Lane To: DHCPv4 discussion list Subject: RE: ASCII text message option (option 56) Date: Fri, 30 Jun 2000 13:32:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Reply-To: ndlane@wal-mart.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > -----Original Message----- > From: Barr Hibbs [SMTP:rbhibbs@ultraDNS.com] > Sent: Friday, June 30, 2000 1:28 PM > To: ndlane@WAL-MART.COM; DHCPv4 discussion list > Subject: RE: ASCII text message option (option 56) > > > > From: Nathan Lane > > > But how does AAA work when the DHCP server has already denied any > network > > connectivity at all? Or placed you in a different class (i.e., > > more limited) of service than you expected? > > > I don't understand your point about class of service: DHCP really doesn't > support that functionality in the way I understand it (e.g., delay, packet > loss, and bandwidth characteristics.) > [Nathan Lane] DHCP the protocol does not. DHCP how I configure it does. I have an internal CID specification that, in lieu of yet to be widely deployed user-class option, can drive the DHCP server to allocate a different range of IP addresses for certain classes of workstation. I'd like a message or way to direct a user to know why he can't access a certain resource instead of generating a help desk call. Many times, said user cannot even access an authentication server, so this would have to be very early in the process. Note that something similar can be done now with faking out DNS servers to point to a "registration" web page or other clever things, but this clubs the client over the head, so to speak. > > > This option is ideal for it...I could put up a message saying "Oops, you > > plugged your Mac into a network that doesn't have Appletalk turned on." > > > ...forgive me, Nathan, but how can DHCP do this, given that it is largely > protocol independent? I don't think we should be cognizant of anything in > the protocol stack above the IP layer. > Isn't that up to me? DHCP the protocol does not have to be cognizant of it, but DHCP should be able to communicate what it did to a device in a way that gets back to the actual user. I see the "user message" option more as a "this is why you didn't get an IP"; this new option as a way to communicate what I mentioned above. > > This option is something I can use right now, in any form and > > applies to me both in the limited sense that Apple is doing it > > and, if others adopt it, I could apply it more generally. > > > start a web browser following Stuart's suggestion, but without an IP > address, how does that work?) > User message (56) would be used in the case of a NAK, and therefore the lack of an IP. The new option would be used to communicate additional information...in my view, directly related to the IP allocation that did occur, but it needn't be. -Nathan ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please notify the Wal-Mart E-mail administrator at " postmaster@wal-mart.com ". ********************************************************************** From owner-dhcp-v4@bucknell.edu Fri Jun 30 14:55:10 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24222 for ; Fri, 30 Jun 2000 14:55:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5UIp7W29841; Fri, 30 Jun 2000 14:51:07 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5UIp3W00844 for ; Fri, 30 Jun 2000 14:51:03 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dhcp-218.rc.vix.com [204.152.187.218]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id UAA03552; Thu, 29 Jun 2000 20:11:00 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id LAA03387; Fri, 30 Jun 2000 11:51:25 -0700 (MST) Message-Id: <200006301851.LAA03387@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: ASCII text message option (option 56) In-Reply-To: Message from "Barr Hibbs" of "Fri, 30 Jun 2000 11:28:04 MST." Date: Fri, 30 Jun 2000 11:51:25 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I don't understand your point about class of service: DHCP really doesn't > support that functionality in the way I understand it (e.g., delay, packet > loss, and bandwidth characteristics.) I think he means class in the sense of ISC DHCP classes and allocation pools, not in the sense of different levels of service implemented in IP. It's a very common application for people to set up a net 10 subnet on each wire and a routeable subnet on each wire and give you a net 10 address if you haven't registered, but a routable address if you have. It makes perfect sense to me that Telcordia isn't very interested in this, and that you aren't either, but I definitely wouldn't describe this as an obscure application with limited applicability. Please, folks, try to think of other peoples' requirements as well as your own... :'} _MelloN_ From owner-dhcp-v4@bucknell.edu Fri Jun 30 16:02:57 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25489 for ; Fri, 30 Jun 2000 16:02:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5UJwdW15257; Fri, 30 Jun 2000 15:58:39 -0400 (EDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5UJwUW09267 for ; Fri, 30 Jun 2000 15:58:31 -0400 (EDT) Received: from earth.research.telcordia.com (earth [192.4.18.66]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e5UJw8F01704 for ; Fri, 30 Jun 2000 15:58:08 -0400 (EDT) Sender: owner-dhcp-v4@bucknell.edu Message-ID: <395CFBCF.B73C7EAB@earth.research.telcordia.com> Date: Fri, 30 Jun 2000 15:58:08 -0400 From: Tony McAuley Organization: Telcordia X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 4.1.4 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: Re: ASCII text message option (option 56) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: mcauley@earth.research.telcordia.com X-Sender: mcauley@research.telcordia.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit The point I was trying to make was that functions that interface with the user (not just configuring the node) should be part of a separate "user registration" protocol. I agree that "user registration" should encompass both commercial cellular or cable networks authenticating a user with the help of AAA and a private (10.X) network just saying "hello." I did not mean to imply that all networks should authenticate users and use AAA. Appreciate your comments? Thanks Tony ---------------------------------------------------------------------------- Anthony J. McAuley email: mcauley@research.telcordia.com MCC 1C235B, Telcordia Technologies phone: +1 973 829 4698 445 South Street, Morristown, NJ 07960 fax: +1 973 829 5888 ---------------------------------------------------------------------------- Subject: Re: ASCII text message option (option 56) Date: Fri, 30 Jun 2000 11:51:25 -0700 From: Ted Lemon To: DHCPv4 discussion list CC: DHCPv4 discussion list > I don't understand your point about class of service: DHCP really doesn't > support that functionality in the way I understand it (e.g., delay, packet > loss, and bandwidth characteristics.) I think he means class in the sense of ISC DHCP classes and allocation pools, not in the sense of different levels of service implemented in IP. It's a very common application for people to set up a net 10 subnet on each wire and a routeable subnet on each wire and give you a net 10 address if you haven't registered, but a routable address if you have. It makes perfect sense to me that Telcordia isn't very interested in this, and that you aren't either, but I definitely wouldn't describe this as an obscure application with limited applicability. Please, folks, try to think of other peoples' requirements as well as your own... :'} _MelloN_ From owner-dhcp-v4@bucknell.edu Fri Jun 30 16:09:19 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25587 for ; Fri, 30 Jun 2000 16:09:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5UK7PW10331; Fri, 30 Jun 2000 16:07:25 -0400 (EDT) Received: from Arachnid.NTRG.com ([209.31.7.46]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5UK7FW23198 for ; Fri, 30 Jun 2000 16:07:15 -0400 (EDT) Received: from ehsco.com (nat-external.ehsco.com [209.31.7.42]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 704 for ; Fri, 30 Jun 2000 13:07:14 -0700 Message-ID: <395CFDF1.6F51D1B1@ehsco.com> Date: Fri, 30 Jun 2000 13:07:14 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: Re: ASCII text message option (option 56) References: <395CB4F8.50B5C65F@earth.research.telcordia.com> <395CCDAA.63A52823@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: ehall@ehsco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit There seem to be two topics in the same thread: 1) URL-encoding within the ASCII text option 2) A generic exec option (1) is easy. Extend the option so that text is allowed and should be intepreted as a link to some external resource, which should call an application that can handle the url if selected. yadda yadda yadda. This appeases various things like "this system is not authorized for network acces. click here to request access." (2) is more difficult. There would need to be a lot of discussion about how you would represent the action, do you need to represent the command and parameters differently, what kind of actions are to supported (URLs only? command-line apps? both?), etc. Very tricky. These two things need to be separated IMHO, although the generic URL encoding in (1) could also be "application encoding" that calls local app instead of url. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-dhcp-v4@bucknell.edu Fri Jun 30 16:15:39 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25749 for ; Fri, 30 Jun 2000 16:15:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5UKDaW28141; Fri, 30 Jun 2000 16:13:36 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5UKDZW08189 for ; Fri, 30 Jun 2000 16:13:35 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dhcp-218.rc.vix.com [204.152.187.218]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id VAA03804; Thu, 29 Jun 2000 21:33:31 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id NAA03622; Fri, 30 Jun 2000 13:13:57 -0700 (MST) Message-Id: <200006302013.NAA03622@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: ASCII text message option (option 56) In-Reply-To: Message from Tony McAuley of "Fri, 30 Jun 2000 15:58:08 -0400." <395CFBCF.B73C7EAB@earth.research.telcordia.com> Date: Fri, 30 Jun 2000 13:13:57 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > The point I was trying to make was that functions that interface > with the user (not just configuring the node) should be part of a > separate "user registration" protocol. Stuart is proposing a very simple, quick solution with immediate applications, leveraging existing protocols to produce a better user interface. Several large DHCP users can see applications for it. So I think it's useful to proceed with it, unless you can come up with a concrete reason not to. That you have a specific solution to a specific problem using a new protocol is not a reason not to proceed with this solution. Nor is this solution a reason not to proceed with what you are doing. Both are good. There's no reason that they should be considered mutually exclusive. Unless you have one that you haven't stated yet! :') _MelloN_ From owner-dhcp-v4@bucknell.edu Fri Jun 30 16:38:21 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26087 for ; Fri, 30 Jun 2000 16:38:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5UKY6W26428; Fri, 30 Jun 2000 16:34:06 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5UKY0W15330 for ; Fri, 30 Jun 2000 16:34:00 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dhcp-218.rc.vix.com [204.152.187.218]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id VAA03882; Thu, 29 Jun 2000 21:53:56 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id NAA03698; Fri, 30 Jun 2000 13:34:22 -0700 (MST) Message-Id: <200006302034.NAA03698@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: ASCII text message option (option 56) In-Reply-To: Message from "Eric A. Hall" of "Fri, 30 Jun 2000 13:07:14 MST." <395CFDF1.6F51D1B1@ehsco.com> Date: Fri, 30 Jun 2000 13:34:22 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > (2) is more difficult. There would need to be a lot of discussion about > how you would represent the action, do you need to represent the command > and parameters differently, what kind of actions are to supported (URLs > only? command-line apps? both?), etc. Very tricky. I don't think anybody's proposing (2). (2) would be an extremely dangerous enhancement, and I'd have trouble getting behind such a proposal for the same reason that having Java in my web browser gives me the willies. _MelloN_ From owner-dhcp-v4@bucknell.edu Fri Jun 30 16:59:07 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26305 for ; Fri, 30 Jun 2000 16:59:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5UKnfW24449; Fri, 30 Jun 2000 16:49:41 -0400 (EDT) Received: from Arachnid.NTRG.com ([209.31.7.46]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5UKnaW18762 for ; Fri, 30 Jun 2000 16:49:36 -0400 (EDT) Received: from ehsco.com (nat-external.ehsco.com [209.31.7.42]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 573 for ; Fri, 30 Jun 2000 13:49:35 -0700 Message-ID: <395D07DE.6D6F2E47@ehsco.com> Date: Fri, 30 Jun 2000 13:49:34 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 CC: DHCPv4 discussion list Subject: Re: ASCII text message option (option 56) References: <200006302034.NAA03698@grosse.bisbee.fugue.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: ehall@ehsco.com Sender: owner-dhcp-v4@bucknell.edu To: DHCPv4 discussion list X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > I don't think anybody's proposing (2). (2) would be an extremely > dangerous enhancement, and I'd have trouble getting behind such a > proposal for the same reason that having Java in my web browser gives > me the willies. If you want to automatically fire up a web browser that takes a user to a registration URL then you're talking about an exec option (2). -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-dhcp-v4@bucknell.edu Fri Jun 30 17:11:56 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26604 for ; Fri, 30 Jun 2000 17:11:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5UL7HW29029; Fri, 30 Jun 2000 17:07:17 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5UL7EW20015 for ; Fri, 30 Jun 2000 17:07:14 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dhcp-218.rc.vix.com [204.152.187.218]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id WAA03958; Thu, 29 Jun 2000 22:27:12 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id OAA03792; Fri, 30 Jun 2000 14:07:38 -0700 (MST) Message-Id: <200006302107.OAA03792@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: ASCII text message option (option 56) In-Reply-To: Message from "Eric A. Hall" of "Fri, 30 Jun 2000 13:49:34 MST." <395D07DE.6D6F2E47@ehsco.com> Date: Fri, 30 Jun 2000 14:07:38 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > If you want to automatically fire up a web browser that takes a user to > a registration URL then you're talking about an exec option (2). No, you aren't. An exec option (2) means firing up an arbitrary program on command of the DHCP server. A URL means that you'll do an HTTP request to get the contents of a web page and arrange to display it. It has no other specific implications. Implementation is left up to the implementor, and the implementation that I have in mind for NetBSD doesn't involve automatically firing up a full-fledged browser. I can't speak to what Stuart or Nathan have in mind, of course. _MelloN_ From owner-dhcp-v4@bucknell.edu Fri Jun 30 17:28:13 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26901 for ; Fri, 30 Jun 2000 17:28:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5ULQ4W22309; Fri, 30 Jun 2000 17:26:04 -0400 (EDT) Received: from honts307.wal-mart.com (honts307.wal-mart.com [146.132.234.37]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5ULQ2W15369 for ; Fri, 30 Jun 2000 17:26:02 -0400 (EDT) Received: from honts387.homeoffice.wal-mart.com (fwnts002.wal-mart.com [146.132.235.8]) by honts307.wal-mart.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id N5BXL5PC; Fri, 30 Jun 2000 16:29:48 -0500 Received: from honts305.homeoffice.wal-mart.com (unverified) by honts387.homeoffice.wal-mart.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Fri, 30 Jun 2000 16:24:21 -0500 Received: by HONTS305.homeoffice.wal-mart.com with Internet Mail Service (5.5.2650.21) id ; Fri, 30 Jun 2000 16:25:42 -0500 Message-ID: From: Nathan Lane To: DHCPv4 discussion list Subject: RE: ASCII text message option (option 56) Date: Fri, 30 Jun 2000 16:25:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Reply-To: ndlane@wal-mart.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN [.....] implementation that I have in mind for > NetBSD doesn't involve automatically firing up a full-fledged > browser. I can't speak to what Stuart or Nathan have in mind, of > course. > Now we're dying to know what *you* have in mind...but arbitrary execution is not what I was thinking. Just a referral URL and a little window that understands HTML/1.0 is more than enough. Of course, that part of it is not relevant to DHCP. -Nathan ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please notify the Wal-Mart E-mail administrator at " postmaster@wal-mart.com ". ********************************************************************** From owner-dhcp-v4@bucknell.edu Fri Jun 30 17:51:43 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27318 for ; Fri, 30 Jun 2000 17:51:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5ULlfW04080; Fri, 30 Jun 2000 17:47:41 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5ULldW15539 for ; Fri, 30 Jun 2000 17:47:39 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dhcp-218.rc.vix.com [204.152.187.218]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id XAA04087; Thu, 29 Jun 2000 23:07:36 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id OAA03970; Fri, 30 Jun 2000 14:48:02 -0700 (MST) Message-Id: <200006302148.OAA03970@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: ASCII text message option (option 56) In-Reply-To: Message from Nathan Lane of "Fri, 30 Jun 2000 16:25:39 EST." Date: Fri, 30 Jun 2000 14:48:02 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > but arbitrary execution is not what I was thinking. Just a referral > URL and a little window that understands HTML/1.0 is more than > enough. That's what I had in mind too. The reason I had something specific in mind is that there are several choices for NetBSD as to *what* widget to use to display HTML, not that I had a specific application in mind. _MelloN_ From owner-dhcp-v4@bucknell.edu Fri Jun 30 17:59:10 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27404 for ; Fri, 30 Jun 2000 17:59:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e5ULvLW29924; Fri, 30 Jun 2000 17:57:21 -0400 (EDT) Received: from Arachnid.NTRG.com ([209.31.7.46]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e5ULvAW20998 for ; Fri, 30 Jun 2000 17:57:10 -0400 (EDT) Received: from ehsco.com (nat-external.ehsco.com [209.31.7.42]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 456 for ; Fri, 30 Jun 2000 14:57:08 -0700 Message-ID: <395D17B4.DD041FEA@ehsco.com> Date: Fri, 30 Jun 2000 14:57:08 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 CC: DHCPv4 discussion list Subject: Re: ASCII text message option (option 56) References: <200006302148.OAA03970@grosse.bisbee.fugue.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: ehall@ehsco.com Sender: owner-dhcp-v4@bucknell.edu To: DHCPv4 discussion list X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > in mind is that there are several choices for NetBSD as to *what* > widget to use to display HTML, not that I had a specific application > in mind. I didn't say HTML in (1), I said URLs. Encapsulating raw HTML is a whole nother bag of beans. Do you really need support for and tags or is it just something you want? What about

tags? What about multipart messages that reference external plugins? Full-bore HTML chained onto the back of the DHCP transaction is just as dangerous as an exec option would be, even worse is an HTTP stub that interprets HTML and performs actions against it. This is why you have to separate "here is a link" and "open this link". The former is easy, the latter is very hairy. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/