From dhcp-v4@bucknell.edu Sun Aug 1 08:33:40 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25111 for ; Sun, 1 Aug 1999 08:33:39 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA01098; Sun, 1 Aug 1999 08:30:31 -0400 (EDT) Date: Sun, 1 Aug 1999 08:30:31 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: droms@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ralph Droms To: Multiple recipients of list Subject: Minutes from Oslo X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 I've posted the final version of the minutes from the DHC WG meetings in Oslo at http://www.dhcp.org/9907-minutes.html - Ralph From dhcp-v4@bucknell.edu Mon Aug 2 14:29:37 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02182 for ; Mon, 2 Aug 1999 14:29:36 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA23610; Mon, 2 Aug 1999 14:22:09 -0400 (EDT) Date: Mon, 2 Aug 1999 14:22:09 -0400 (EDT) Message-Id: <01C843625423D211AC3F00A0C969E890032B0BE6@orsmsx35.jf.intel.com> Errors-To: droms@bucknell.edu Reply-To: myron.hattig@intel.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Hattig, Myron" To: Multiple recipients of list Subject: 1394 DHCP conclusion X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; X-Mailer: Internet Mail Service (5.5.2448.0) Mime-Version: 1.0 I think the conclusions are: 1) Don't use chaddr with 1394, if it is used the chaddr len is equal to zero and chaddr value is null. 2) Use EUI-64 for client id. 3) Use IP broadcast for request and response. Is anything missing? -myron From dhcp-v4@bucknell.edu Mon Aug 2 15:53:50 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03877 for ; Mon, 2 Aug 1999 15:53:49 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA01764; Mon, 2 Aug 1999 15:51:21 -0400 (EDT) Date: Mon, 2 Aug 1999 15:51:21 -0400 (EDT) Message-Id: <21839C593E75D211BF7800805FCCD026EAAD03@msgsrv03.srv.PacBell.COM> Errors-To: droms@bucknell.edu Reply-To: RBHIBBS@msg.pacbell.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "HIBBS, BARR (PB)" To: Multiple recipients of list Subject: RE: 1394 DHCP conclusion X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain X-Mailer: Internet Mail Service (5.5.2448.0) Mime-Version: 1.0 Myron-- I slightly disagree: hlen MUST be zero AND htype MUST be set to the proper value for IEEE-1394. --Barr > ---------- > From: Hattig, Myron[SMTP:myron.hattig@intel.com] > Sent: Monday, August 02, 1999 11:25 AM > To: Multiple recipients of list > Subject: 1394 DHCP conclusion > > > I think the conclusions are: > 1) Don't use chaddr with 1394, if it is used the chaddr > len is equal to zero and chaddr value is null. > 2) Use EUI-64 for client id. > 3) Use IP broadcast for request and response. > > Is anything missing? > > -myron > From dhcp-v4@bucknell.edu Mon Aug 2 17:08:03 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04835 for ; Mon, 2 Aug 1999 17:08:02 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA20404; Mon, 2 Aug 1999 17:01:48 -0400 (EDT) Date: Mon, 2 Aug 1999 17:01:48 -0400 (EDT) Message-Id: <37A5FB23.1044B194@connectnet.com> Errors-To: droms@bucknell.edu Reply-To: conx@connectnet.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: C J Considine To: Multiple recipients of list Subject: Re: 1394 DHCP conclusion X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.61 [en] (WinNT; I) Content-Transfer-Encoding: 7bit EUI-64'ing both fields is the same as either alone. Chaddr alone leaves the option of DNS names in client identifier. That logical addressing is why there are two fields. You probably must EUI-64 one of them so as to pick your response out of the DHCPOFFER's if the whole subnet reboots. client_id alone would reject much of our experience and break older software, you might want both fields to be useful and plausible. The volatile id is irrelevant. Many DHCP requests will span bus resets, and most leases will as well. chaddr alone would be more robust and not break older servers. It would also much simplify debugging as every packet would have a factory unique identifier, even when customers override client_id. Why else would there be two fields? "Hattig, Myron" wrote: > > I think the conclusions are: > 1) Don't use chaddr with 1394, if it is used the chaddr > len is equal to zero and chaddr value is null. > 2) Use EUI-64 for client id. > 3) Use IP broadcast for request and response. > > Is anything missing? > > -myron From dhcp-v4@bucknell.edu Mon Aug 2 18:03:43 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05593 for ; Mon, 2 Aug 1999 18:03:42 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id SAA07702; Mon, 2 Aug 1999 18:02:36 -0400 (EDT) Date: Mon, 2 Aug 1999 18:02:36 -0400 (EDT) Message-Id: <078292D50C98D2118D090008C7E9C6A601734844@STAY.platinum.corp.microsoft.com> Errors-To: droms@bucknell.edu Reply-To: yegu@Exchange.Microsoft.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Ye Gu (Exchange)" To: Multiple recipients of list Subject: RE: *DRAFT* of minutes from Oslo WG meeting X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain X-Mailer: Internet Mail Service (5.5.2650.14) Mime-Version: 1.0 It's in the original Win98 distribution. However, there is no API to set the user class before the Second Edition. You'll have to go through the registry to set it up. If you're interested, reply directly to me. I'll send you the key location. Thanks! Ye -----Original Message----- From: Ted Lemon [mailto:mellon@isc.org] Sent: Thursday, July 29, 1999 10:06 AM To: Multiple recipients of list Subject: Re: *DRAFT* of minutes from Oslo WG meeting > Microsoft supports the user class option in both Windows 98 and the upcoming > Windows 2000. We've found it to be useful for a number of applications. > We, too, would like to see this be adopted by the WG. Wow, really? I have to check this out - how does it work? Is it in the initial Win98 distribution, or the update? Thanks! _MelloN_ From dhcp-v4@bucknell.edu Mon Aug 2 21:39:12 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07135 for ; Mon, 2 Aug 1999 21:39:07 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id VAA03321; Mon, 2 Aug 1999 21:36:49 -0400 (EDT) Date: Mon, 2 Aug 1999 21:36:49 -0400 (EDT) Message-Id: <199908030127.KAA23524@fujiken.sm.sony.co.jp> Errors-To: droms@bucknell.edu Reply-To: fujisawa@sm.sony.co.jp Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: fujisawa@sm.sony.co.jp To: Multiple recipients of list Subject: Re: 1394 DHCP conclusion X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 >I think the conclusions are: >1) Don't use chaddr with 1394, if it is used the chaddr > len is equal to zero and chaddr value is null. >2) Use EUI-64 for client id. >3) Use IP broadcast for request and response. Since the expiration date of the previous draft was July 1999, I submitted new draft, draft-ietf-ip1394-dhcp-02.txt, yesterday adding two notes. : Note: In general, the use of a broadcast reply is discouraged, : but we consider the impact in a 1394 network is not an issue. : Note: As described in [RFC2131], 'ciaddr' MUST be filled in with : client's IP address during BOUND, RENEWING or REBINDING state, : therefore, the BROADCAST flag MUST NOT be set. In these cases, : the DHCP server unicasts DHCPACK message to the address in : 'ciaddr'. The link address will be resolved by ARP. I'll gladly update the draft if necessary. Best Regards, Kenji Fujisawa From dhcp-v4@bucknell.edu Mon Aug 2 22:47:58 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09280 for ; Mon, 2 Aug 1999 22:47:57 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id WAA08857; Mon, 2 Aug 1999 22:46:21 -0400 (EDT) Date: Mon, 2 Aug 1999 22:46:21 -0400 (EDT) Message-Id: <199908030233.LAA23711@fujiken.sm.sony.co.jp> Errors-To: droms@bucknell.edu Reply-To: fujisawa@sm.sony.co.jp Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: fujisawa@sm.sony.co.jp To: Multiple recipients of list Subject: Re: 1394 DHCP conclusion X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 >I slightly disagree: hlen MUST be zero AND htype MUST be set to the proper >value for IEEE-1394. Just a confirmation. The draft says, : 'htype' (hardware address type) MUST be 24 [ARPPARAM]. : 'hlen' (hardware address length) MUST be 0. Do you disagree with this text? Or, do you think it's okay? Kenji Fujisawa From dhcp-v4@bucknell.edu Tue Aug 3 08:51:55 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02778 for ; Tue, 3 Aug 1999 08:51:54 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA08969; Tue, 3 Aug 1999 08:49:13 -0400 (EDT) Date: Tue, 3 Aug 1999 08:49:13 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: Buckalew@summit-inc.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Buckalew@summit-inc.com To: Multiple recipients of list Subject: Re: 1394 DHCP conclusion X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: Lotus Notes Release 5.0 March 30, 1999 Unsubscribe me please. William F. Buckalew, RCDD/LAN General Manager Summit Network Services 707 East Gay Street West Chester, PA 19380 1-610-692-5042 1-888-332-3325 (toll-free) 1-610-429-9001 (fax) www.summit-inc.com buckalew@summit-inc.com From dhcp-v4@bucknell.edu Tue Aug 3 09:55:04 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06787 for ; Tue, 3 Aug 1999 09:55:04 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA29790; Tue, 3 Aug 1999 09:52:09 -0400 (EDT) Date: Tue, 3 Aug 1999 09:52:09 -0400 (EDT) Message-Id: <199908031326.JAA12680@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: 1394 DHCP conclusion X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Try sending mail to listserv@bucknell.edu with the word "HELP" in the body of the message. Unfortunately, I _can't_ unsubscribe you, and chances are that nobody else who read your message can either. :'( _MelloN_ From dhcp-v4@bucknell.edu Tue Aug 3 10:34:08 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08155 for ; Tue, 3 Aug 1999 10:34:07 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA28377; Tue, 3 Aug 1999 10:32:25 -0400 (EDT) Date: Tue, 3 Aug 1999 10:32:25 -0400 (EDT) Message-Id: <199908031401.KAA11595@csrlink.net> Errors-To: droms@bucknell.edu Reply-To: droms@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ralph Droms To: Multiple recipients of list Subject: Re: 1394 DHCP conclusion X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 At 09:54 AM 8/3/99 -0400, mellon@isc.org wrote: > >Try sending mail to listserv@bucknell.edu with the word "HELP" in the >body of the message. Unfortunately, I _can't_ unsubscribe you, and >chances are that nobody else who read your message can either. :'( I've received several direct requests to be unsubscribed from the list recently. I have to enter those requests manually and it may be several days before I get a chance to make those changes. I'll follow up Ted's suggestion and strongly recommend that anyone who wants to leave the dhcp-v4 or dhcp-v6 lists first send mail to listserv@bucknell.edu with the message: unsubscribe dhcp-v4 (and/or, as appropriate) unsubscribe dhcp-v6 - Yr. obdt. (but very harried) mailing list manager Ralph From dhcp-v4@bucknell.edu Tue Aug 3 10:36:33 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08200 for ; Tue, 3 Aug 1999 10:36:32 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA03065; Tue, 3 Aug 1999 10:34:20 -0400 (EDT) Date: Tue, 3 Aug 1999 10:34:20 -0400 (EDT) Message-Id: <199908031412.KAA17986@csrlink.net> Errors-To: droms@bucknell.edu Reply-To: Internet-Drafts@ietf.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Internet-Drafts@ietf.org (by way of Ralph Droms ) To: Multiple recipients of list Subject: I-D ACTION:draft-ietf-ip1394-dhcp-02.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Over IEEE 1394 Working Group of the IETF. Title : DHCP on IEEE 1394 Author(s) : K. Fujisawa Filename : draft-ietf-ip1394-dhcp-02.txt Pages : 4 Date : 02-Aug-99 IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. Since 1394 uses different link-layer addressing method than conventional IEEE802/Ethernet, the usage of some fields must be clarified to achieve interoperability. This memo describes the 1394 specific usage of some fields of DHCP messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ip1394-dhcp-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-ip1394-dhcp-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-ip1394-dhcp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19990802071642.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ip1394-dhcp-02.txt From listserv@bucknell.edu Tue Aug 3 17:39:41 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15057 for ; Tue, 3 Aug 1999 17:39:41 -0400 (EDT) From: listserv@bucknell.edu Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA01746; Tue, 3 Aug 1999 17:39:31 -0400 (EDT) Date: Tue, 3 Aug 1999 17:39:31 -0400 (EDT) Message-Id: <199908032139.RAA01746@mail.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: listserv@bucknell.edu Sender: listserv@bucknell.edu To: dhc-archive@ietf.org Cc: droms@bucknell.edu Subject: SUBSCRIBE DHCP-V6 WG MAILING LIST ARCHIVE X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Bucknell University ListProcessor You have been added to list dhcp-v6@bucknell.edu. The system has recorded your address as dhc-archive@lists.ietf.org and in order for your messages to get posted (if the list accepts postings), you will have to send them from this address, unless the list does not require subscription for posting. If a message is ever rejected, please contact the list's owner: droms@bucknell.edu For information on this service and how to use it, send the following request in the body of a mail message to listserv@bucknell.edu: HELP All requests should be addressed to listserv@bucknell.edu. The amount of acknowledgement you wish to receive from this list upon completion of a mailing operation can be changed by means of a "SET DHCP-V6 MAIL option" command, where "option" may be either "ACK" (mail acknowledgement) or "NOACK": SET DHCP-V6 MAIL ACK SET DHCP-V6 MAIL NOACK If you prefer to receive messages from DHCP-V6 in one fell swoop, you may use the the DIGEST option to have DHCP-V6 messages accumulated into digests which will be periodically sent to you: SET DHCP-V6 MAIL DIGEST If you wish to stop delivery of list messages temporarily without unsubscribing from the list, you can use the POSTPONE option: SET DHCP-V6 MAIL POSTPONE When you're ready to receive messages again, use the ACK or NOACK options as described above. To issue any of these commands, send them in the body of a message to the LISTSERV@BUCKNELL.EDU e-mail address. Contributions sent to this list are automatically archived. You can obtain a list of the available archive files by sending an "INDEX DHCP-V6" command to LISTSERV@BUCKNELL.EDU. These files can then be retrieved by means of a "GET DHCP-V6 filetype" command. To post an article to the list, send your message to the list address DHCP-V6@BUCKNELL.EDU. To leave the list at any time, you can send an e-mail message to LISTSERV@BUCKNELL.EDU with the body of your message containing the line: UNSUBSCRIBE DHCP-V6 Virtually, The LISTSERVer at Bucknell From dhcp-v4@bucknell.edu Tue Aug 3 21:47:21 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18182 for ; Tue, 3 Aug 1999 21:47:20 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id VAA10084; Tue, 3 Aug 1999 21:45:25 -0400 (EDT) Date: Tue, 3 Aug 1999 21:45:25 -0400 (EDT) Message-Id: <199908040135.KAA25733@fujiken.sm.sony.co.jp> Errors-To: droms@bucknell.edu Reply-To: fujisawa@sm.sony.co.jp Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: fujisawa@sm.sony.co.jp To: Multiple recipients of list Subject: Re: 1394 DHCP conclusion X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 >EUI-64'ing both fields is the same as either alone. Chaddr >alone leaves the option of DNS names in client identifier. >That logical addressing is why there are two fields. >You probably must EUI-64 one of them so as to pick your >response out of the DHCPOFFER's if the whole subnet reboots. I couldn't understand your point, sorry. My understanding is, client-ID identification of the client chaddr link address of the client In the case of 1394, we don't have a consistent link address within entire subnet, this is the reason for NULL chaddr. EUI-64 is not a link address. And, the use of EUI-64 is not mandatory. For example, the combination of (client-ID = FQDN, chaddr = NULL) may be used for 1394 DHCP client if desired. Best Regards, Kenji Fujisawa From dhcp-v4@bucknell.edu Sat Aug 7 10:21:58 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16058 for ; Sat, 7 Aug 1999 10:21:57 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA00238; Sat, 7 Aug 1999 10:19:04 -0400 (EDT) Date: Sat, 7 Aug 1999 10:19:04 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: Patent application for draft-dhcp-agent-options X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 (Forwarded for Mike Patrick) ---------------------------------------------------------------------------- --- Working Group, I apologize for delays in advancing the relay agent options draft. The IESG required standard text from RFC2026 regarding intellectual property, including patent applications, and I misunderstood what was required from Motorola before adding this text. Those hurdles are past, and I'm ready to submit a revised draft for the WG's consideration. First, an important notice: This is to inform you that Motorola has applied for a patent which may cover methods and devices described in the DHCP relay option draft . Inquiries are directed to Mr. Kirk Dailey, IP Legal Counsel, Motorola Internet and Networking Group, MS M2-300, 20 Cabot Blvd, Mansfield MA 02048, email: AKD001@email.mot.com, regarding CX096052. I am submitting version 6 of the draft which adds required text in a new section 7.0 "Intellectual Property Notices" pursuant to the IETF standards process in RFC2026. This is the only difference between -05 and -06. I am soliciting feedback to the list on the revised draft, which I will post to the list under separate cover. BTW, I will be on vacation until 8/16 and will not be able to respond to the list until that time. Regards, Mike Patrick Motorola Internet and Networking Group From dhcp-v4@bucknell.edu Sat Aug 7 12:10:53 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16596 for ; Sat, 7 Aug 1999 12:10:52 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA00493; Sat, 7 Aug 1999 12:09:03 -0400 (EDT) Date: Sat, 7 Aug 1999 12:09:03 -0400 (EDT) Message-Id: <199908071547.LAA02156@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: Patent application for draft-dhcp-agent-options X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > This is to inform you that Motorola has applied for a patent which > may cover methods and devices described in the DHCP relay option draft > . > Inquiries are directed to Mr. Kirk Dailey, IP Legal Counsel, > Motorola Internet and Networking Group, MS M2-300, 20 Cabot > Blvd, Mansfield MA 02048, email: AKD001@email.mot.com, regarding CX096052. Michael, I think you owe us a great deal more explanation than this. For starters, what exactly are you patenting? Secondly, what are your intentions with respect to the patent - is this a defensive patent, does Motorola intent to attempt to prevent others from deploying this technology through the use of patent protection, or does Motorola intent to attempt to collect licensing fees for this technology? More to the point, though, why didn't you mention that you intended to patent this at the very beginning of the process? I personally have expended quite a bit of effort both in helping you to come up with the right solution for the problem, and also in actually implementing features in the ISC DHCP server and relay agent that support this technology. You can be very certain that I would not have expended any such effort if you had stated your intentions at the beginning of the process. I am asking you to take personal responsibity for this. You personally got up in front of all of us and made your proposal, without giving us all the facts. You then let us believe for over a year and a half that this was going to be a free and open standard, which you now tell us it is not. You made free with our resources and good will, and now it looks like you're going to patent the results. If you personally can't make a statement as to Motorola's intentions, then you have an obligation to personally see to it that your lawyer clearly and completely states Motorola's intentions, both in terms of what Motorola is patenting, and also in terms of what Motorola's intentions are in the event that the patent is granted. I would appreciate your prompt attention to this matter. Sincerely, Ted Lemon From dhcp-v4@bucknell.edu Sat Aug 7 12:11:52 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16617 for ; Sat, 7 Aug 1999 12:11:51 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA07442; Sat, 7 Aug 1999 12:10:02 -0400 (EDT) Date: Sat, 7 Aug 1999 12:10:02 -0400 (EDT) Message-Id: <199908071548.LAA02172@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: Patent application for draft-dhcp-agent-options X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Based on Michael Patrick's announcement of Motorola's decision to try to patent the technology behing the Relay Agent Information option draft, I hereby propose that the draft be removed from the consideration of this working group as a standard. _MelloN_ From dhcp-v4@bucknell.edu Sat Aug 7 19:02:48 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18460 for ; Sat, 7 Aug 1999 19:02:48 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA23972; Sat, 7 Aug 1999 17:58:29 -0400 (EDT) Date: Sat, 7 Aug 1999 17:58:29 -0400 (EDT) Message-Id: <199908072139.RAA01994@mail.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: Re: Patent application for draft-dhcp-agent-options X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 message sent to dhcp-v4@bucknell.edu by WES@ORCHARD.ARLINGTON.MA.US follows. ---------------------------------------------------------------------------- Based on Michael Patrick's announcement of Motorola's decision to try to patent the technology behing the Relay Agent Information option draft, I hereby propose that the draft be removed from the consideration of this working group as a standard. I support this action. I'll actually be quite happy to see it go, though I would have much preferred it if Motorola been open about their intent to patent aspects of this technology when they first brought it to the working group. The IETF's practice for quite some time has been to avoid the use of patented technologies when suitable unpatented alternatives exist. While it's unclear what Motorola will attempt to claim in their patent application, it's clear that there are many other ways to solve the same problem without the insertion of options by a relay agent... indeed, some of them may be technically superior.. I've felt for a long time that the relay option is problematic from a security perspective (it's much harder to protect the original message from the client from modification if a relay agent in the middle can modify it along the way). Some sort of encapsulation-based scheme (where the original packet from the client is included unmodified in the message from the relay agent to the DHCP server) appears to be the most obvious alternative.. - Bill From dhcp-v4@bucknell.edu Sun Aug 8 14:06:40 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09840 for ; Sun, 8 Aug 1999 14:06:40 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA02557; Sun, 8 Aug 1999 14:04:12 -0400 (EDT) Date: Sun, 8 Aug 1999 14:04:12 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: gww@nortelnetworks.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Glenn Waters" To: Multiple recipients of list Subject: RE: Patent application for draft-dhcp-agent-options X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit before we consider removing this work from the dhc working group i would like to hear what michael has to say. i too would like to see his prompt attention to this matter. /gww > -----Original Message----- > From: dhcp-v4@bucknell.edu [mailto:dhcp-v4@bucknell.edu]On Behalf Of Ted > Lemon > Sent: Saturday, August 07, 1999 12:10 > To: Multiple recipients of list > Subject: Re: Patent application for draft-dhcp-agent-options > > > > Based on Michael Patrick's announcement of Motorola's decision to try > to patent the technology behing the Relay Agent Information option > draft, I hereby propose that the draft be removed from the > consideration of this working group as a standard. > > _MelloN_ > > From dhcp-v4@bucknell.edu Mon Aug 9 07:49:19 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01362 for ; Mon, 9 Aug 1999 07:49:19 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id HAA03783; Mon, 9 Aug 1999 07:46:00 -0400 (EDT) Date: Mon, 9 Aug 1999 07:46:00 -0400 (EDT) Message-Id: <4.1.19990809052917.0097f220@mail.join.com> Errors-To: droms@bucknell.edu Reply-To: robs@join.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Rob Stevens To: Multiple recipients of list Subject: RE: Patent application for draft-dhcp-agent-options X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Glenn Waters wrote: >before we consider removing this work from the dhc working group i would >like to hear what michael has to say. .... Yes. I don't want to re-act in an over hasty way before I understand exactly what Motorola are trying to do with this patent. I'm seeking clarification from the counsel that Michael mentioned. Rob Stevens From dhcp-v4@bucknell.edu Mon Aug 9 10:47:09 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08677 for ; Mon, 9 Aug 1999 10:47:08 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA32276; Mon, 9 Aug 1999 10:45:17 -0400 (EDT) Date: Mon, 9 Aug 1999 10:45:17 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: RE: Patent application for draft-dhcp-agent-options X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 message sent to dhcp-v4@bucknell.edu by KIRK.DAILEY@MOTOROLA.COM follows. ------------------------------------------------------------------------- Ted, In no way did Michael intend to mislead anyone. He is attempting to get approval from Motorola to provide the patent on a royalty-free basis. The official position should be known in the next couple of months. Regards, Kirk ------------------------------------------------------------------------ ------------------------------------------------ Kirk W. Dailey Legal Counsel Internet and Networking Group Motorola, Inc. 20 Cabot Boulevard Mansfield, MA 02048 USA Phone: (508) 261-5385 Fax: (508) 339-7086 Email: Kirk.Dailey@motorola.com ------------------------------------------------------------------------ ------------------------------------------------------- -----Original Message----- From: Ted Lemon [mailto:mellon@isc.org] Sent: Saturday, August 07, 1999 11:47 AM To: Michael Patrick-LZZ007 Cc: Kirk.Dailey; dhcp-v4@bucknell.edu Subject: Re: Patent application for draft-dhcp-agent-options > This is to inform you that Motorola has applied for a patent which > may cover methods and devices described in the DHCP relay option draft > . > Inquiries are directed to Mr. Kirk Dailey, IP Legal Counsel, > Motorola Internet and Networking Group, MS M2-300, 20 Cabot > Blvd, Mansfield MA 02048, email: AKD001@email.mot.com, regarding CX096052. Michael, I think you owe us a great deal more explanation than this. For starters, what exactly are you patenting? Secondly, what are your intentions with respect to the patent - is this a defensive patent, does Motorola intent to attempt to prevent others from deploying this technology through the use of patent protection, or does Motorola intent to attempt to collect licensing fees for this technology? More to the point, though, why didn't you mention that you intended to patent this at the very beginning of the process? I personally have expended quite a bit of effort both in helping you to come up with the right solution for the problem, and also in actually implementing features in the ISC DHCP server and relay agent that support this technology. You can be very certain that I would not have expended any such effort if you had stated your intentions at the beginning of the process. I am asking you to take personal responsibity for this. You personally got up in front of all of us and made your proposal, without giving us all the facts. You then let us believe for over a year and a half that this was going to be a free and open standard, which you now tell us it is not. You made free with our resources and good will, and now it looks like you're going to patent the results. If you personally can't make a statement as to Motorola's intentions, then you have an obligation to personally see to it that your lawyer clearly and completely states Motorola's intentions, both in terms of what Motorola is patenting, and also in terms of what Motorola's intentions are in the event that the patent is granted. I would appreciate your prompt attention to this matter. Sincerely, Ted Lemon From dhcp-v4@bucknell.edu Mon Aug 9 10:47:22 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08688 for ; Mon, 9 Aug 1999 10:47:17 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA16208; Mon, 9 Aug 1999 10:45:50 -0400 (EDT) Date: Mon, 9 Aug 1999 10:45:50 -0400 (EDT) Message-Id: <199908091435.KAA07632@mail.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: droms@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ralph Droms To: Multiple recipients of list Subject: Motorola patent application on draft-dhcp-agent-options-*.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Following the procedure in RFC2026, 10.3.2 (C), I've asked Steve Coya of the IETF to contact Motorola to obtain "written assurance that upon approval by the IESG of the relevant Internet standards track specification(s), any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification(s) under openly specified, reasonable, non-discriminatory terms." We'll keep you posted as to the progress of these efforts. Based on RFC2026, the WG may decide to: * continue considering draft-dhcp-agent-options-*.txt for standards acceptance * defer further action until hearing details about the patent application from Motorola * drop the draft as a WG work item My recommendation would be to defer any decision until we hear from Motorola. - Ralph From dhcp-v4@bucknell.edu Mon Aug 9 10:47:24 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08691 for ; Mon, 9 Aug 1999 10:47:20 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA19862; Mon, 9 Aug 1999 10:43:08 -0400 (EDT) Date: Mon, 9 Aug 1999 10:43:08 -0400 (EDT) Message-Id: <199908091414.KAA01324@mail.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: RE: Patent application for draft-dhcp-agent-options X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 message sent to dhcp-v4@bucknell.edu by MWC@SPG-EAST-004.EAST.SUN.COM follows. ------------------------------------------------------------------------------ > before we consider removing this work from the dhc working group i would > like to hear what michael has to say. i too would like to see his prompt > attention to this matter. > > /gww I agree that more detail about exactly what is being patented is warranted before we consider dropping it from the IETF. However, I would also like to add that I too feel mislead by Motorola. In addition to the work that was done on the dhcp agent info option draft, there was also other work (DHCP authentication) that was affected by this draft, and which required a non-trivial amount of work in order to ensure that the agent option functionality would continue to work in an DHCP authentication environment. In retrospect, I suppose we shouldn't have been too surprised, since of the cable modem vendors out there, only motorola has implemented this functionality. (if there are others that have that I don't know about, they likely are very concerned about this turn of events). > > > -----Original Message----- > > From: dhcp-v4@bucknell.edu [mailto:dhcp-v4@bucknell.edu]On Behalf Of Ted > > Lemon > > Sent: Saturday, August 07, 1999 12:10 > > To: Multiple recipients of list > > Subject: Re: Patent application for draft-dhcp-agent-options > > > > > > > > Based on Michael Patrick's announcement of Motorola's decision to try > > to patent the technology behing the Relay Agent Information option > > draft, I hereby propose that the draft be removed from the > > consideration of this working group as a standard. > > > > _MelloN_ > > > > > Mike Carney SNT Internet Engineering Sun Microsystems, Inc. Mailstop UBUR02-212 One Network Drive Burlington, MA 01803 From dhcp-v4@bucknell.edu Mon Aug 9 11:31:16 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09662 for ; Mon, 9 Aug 1999 11:31:15 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA13837; Mon, 9 Aug 1999 11:28:04 -0400 (EDT) Date: Mon, 9 Aug 1999 11:28:04 -0400 (EDT) Message-Id: <199908091443.KAA11780@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: Patent application for draft-dhcp-agent-options X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > In no way did Michael intend to mislead anyone. He is attempting to get > approval from Motorola to provide the patent on a royalty-free basis. The > official position should be known in the next couple of months. Kirk, thanks for responding so quickly. It's good to know what Michael's intentions are. However, until we have an official statement from Motorola to the effect that they do not intend to enforce their intellectual property rights based on this patent, I think it would be premature to write it into a standard. What will be different three months from now that will allow Motorola to make an official statement on this matter? _MelloN_ From dhcp-v4@bucknell.edu Mon Aug 9 11:31:42 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09676 for ; Mon, 9 Aug 1999 11:31:42 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA26248; Mon, 9 Aug 1999 11:29:56 -0400 (EDT) Date: Mon, 9 Aug 1999 11:29:56 -0400 (EDT) Message-Id: <199908091513.LAA12208@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: Patent application for draft-dhcp-agent-options X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > We have internal approval policies that need to be adhered to. Ick. Been there, done that. > Should not take 3 months. Hopefully much shorter. Great! I'm really looking forward to getting this cleared up - this draft has been around for a long time, is clearly useful, and it would really be nice to finally put it to bed for once and for all. Thanks for explaining, and for responding so quickly! _MelloN_ From dhcp-v4@bucknell.edu Mon Aug 9 11:31:45 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09687 for ; Mon, 9 Aug 1999 11:31:44 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA10318; Mon, 9 Aug 1999 11:29:10 -0400 (EDT) Date: Mon, 9 Aug 1999 11:29:10 -0400 (EDT) Message-Id: <199908091458.KAA11877@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: Motorola patent application on draft-dhcp-agent-options-*.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > My recommendation would be to defer any decision until we hear from Motorola. This sounds like the right thing to do. Thanks! _MelloN_ From dhcp-v4@bucknell.edu Mon Aug 9 11:31:46 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09694 for ; Mon, 9 Aug 1999 11:31:45 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA16116; Mon, 9 Aug 1999 11:30:37 -0400 (EDT) Date: Mon, 9 Aug 1999 11:30:37 -0400 (EDT) Message-Id: <9908091118.aa14008@khitomer.epilogue.com> Errors-To: droms@bucknell.edu Reply-To: wes@epilogue.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Bill Sommerfeld To: Multiple recipients of list Subject: Re: Patent application for draft-dhcp-agent-options X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > [Michael] is attempting to get approval from Motorola to provide the > patent on a royalty-free basis. The official position should be > known in the next couple of months. Given this statement, I recommend: - defer all work on this draft until this statement is made. - avoid deferring work on other drafts (e.g., security) just because of interdependance with the deferred draft. - in particular, preventing any new issues relating to the relay agent option from causing further delay on the DHCP security drafts... i.e., if there's a conflict, don't change (and delay) security, since the relay agent option may not emerge from the patent quagmire for months or years. - Bill From dhcp-v4@bucknell.edu Mon Aug 9 12:15:20 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10353 for ; Mon, 9 Aug 1999 12:15:19 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA17208; Mon, 9 Aug 1999 12:12:10 -0400 (EDT) Date: Mon, 9 Aug 1999 12:12:10 -0400 (EDT) Message-Id: <199908091540.LAA20569@mail.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: RE: Patent application for draft-dhcp-agent-options X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 message sent to dhcp-v4@bucknell.edu by KIRK.DAILEY@MOTOROLA.COM follows. ------------------------------------------------------------------------- We have internal approval policies that need to be adhered to. Should not take 3 months. Hopefully much shorter. ------------------------------------------------------------------------ ------------------------------------------------ Kirk W. Dailey Legal Counsel Internet and Networking Group Motorola, Inc. 20 Cabot Boulevard Mansfield, MA 02048 USA Phone: (508) 261-5385 Fax: (508) 339-7086 Email: Kirk.Dailey@motorola.com ------------------------------------------------------------------------ ------------------------------------------------------- -----Original Message----- From: Ted Lemon [mailto:mellon@isc.org] Sent: Monday, August 09, 1999 10:43 AM To: Dailey Kirk-AKD001 Cc: Patrick Michael-LZZ007; dhcp-v4@bucknell.edu Subject: Re: Patent application for draft-dhcp-agent-options > In no way did Michael intend to mislead anyone. He is attempting to get > approval from Motorola to provide the patent on a royalty-free basis. The > official position should be known in the next couple of months. Kirk, thanks for responding so quickly. It's good to know what Michael's intentions are. However, until we have an official statement from Motorola to the effect that they do not intend to enforce their intellectual property rights based on this patent, I think it would be premature to write it into a standard. What will be different three months from now that will allow Motorola to make an official statement on this matter? _MelloN_ From dhcp-v4@bucknell.edu Mon Aug 9 12:15:52 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10375 for ; Mon, 9 Aug 1999 12:15:51 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA15779; Mon, 9 Aug 1999 12:14:12 -0400 (EDT) Date: Mon, 9 Aug 1999 12:14:12 -0400 (EDT) Message-Id: <21839C593E75D211BF7800805FCCD026EAAD12@msgsrv03.srv.PacBell.COM> Errors-To: droms@bucknell.edu Reply-To: RBHIBBS@msg.pacbell.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "HIBBS, BARR (PB)" To: Multiple recipients of list Subject: RE: Motorola patent application on draft-dhcp-agent-options-*.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain X-Mailer: Internet Mail Service (5.5.2448.0) Mime-Version: 1.0 > > My recommendation would be to defer any decision until we hear from > Motorola. > > This sounds like the right thing to do. Thanks! > > I concur with Ralph and Ted (and, undoubtedly, numerous others), namely that the WG should defer a decision on any action regarding the relay agent options draft until we have a clear, unambiguous, and binding statement from Motorola's legal counsel regarding the specific technologies they are seeking to patent. --Barr From dhcp-v4@bucknell.edu Mon Aug 9 12:15:57 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10374 for ; Mon, 9 Aug 1999 12:15:51 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA18008; Mon, 9 Aug 1999 12:14:43 -0400 (EDT) Date: Mon, 9 Aug 1999 12:14:43 -0400 (EDT) Message-Id: <967A4CE9335DD111892400A024C9E9E49F2932@vts.edu> Errors-To: droms@bucknell.edu Reply-To: BBraxton@vts.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Braxton, Bob" To: Multiple recipients of list X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; X-Mailer: Internet Mail Service (5.5.2448.0) Mime-Version: 1.0 UNSUBSCRIBE From dhcp-v4@bucknell.edu Mon Aug 9 12:49:44 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10738 for ; Mon, 9 Aug 1999 12:49:44 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA17760; Mon, 9 Aug 1999 12:48:10 -0400 (EDT) Date: Mon, 9 Aug 1999 12:48:10 -0400 (EDT) Message-Id: <40FB2EA0D644D311AC4300A0C9A8BCEA08363E@INSMAIL.integralis.co.uk> Errors-To: droms@bucknell.edu Reply-To: Paul.Barker@integralis.co.uk Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Paul Barker To: Multiple recipients of list Subject: RE: Patent application for draft-dhcp-agent-options X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; X-Mailer: Internet Mail Service (5.5.2448.0) Mime-Version: 1.0 UNSUBSCRIBE -----Original Message----- From: dhcp-v4@bucknell.edu [mailto:dhcp-v4@bucknell.edu] Sent: Monday, August 09, 1999 5:12 PM To: Multiple recipients of list Subject: RE: Patent application for draft-dhcp-agent-options message sent to dhcp-v4@bucknell.edu by KIRK.DAILEY@MOTOROLA.COM follows. ------------------------------------------------------------------------- We have internal approval policies that need to be adhered to. Should not take 3 months. Hopefully much shorter. ------------------------------------------------------------------------ ------------------------------------------------ Kirk W. Dailey Legal Counsel Internet and Networking Group Motorola, Inc. 20 Cabot Boulevard Mansfield, MA 02048 USA Phone: (508) 261-5385 Fax: (508) 339-7086 Email: Kirk.Dailey@motorola.com ------------------------------------------------------------------------ ------------------------------------------------------- -----Original Message----- From: Ted Lemon [mailto:mellon@isc.org] Sent: Monday, August 09, 1999 10:43 AM To: Dailey Kirk-AKD001 Cc: Patrick Michael-LZZ007; dhcp-v4@bucknell.edu Subject: Re: Patent application for draft-dhcp-agent-options > In no way did Michael intend to mislead anyone. He is attempting to get > approval from Motorola to provide the patent on a royalty-free basis. The > official position should be known in the next couple of months. Kirk, thanks for responding so quickly. It's good to know what Michael's intentions are. However, until we have an official statement from Motorola to the effect that they do not intend to enforce their intellectual property rights based on this patent, I think it would be premature to write it into a standard. What will be different three months from now that will allow Motorola to make an official statement on this matter? _MelloN_ Integralis Network Systems Ltd Theale House Brunel Road Theale, Reading RG7 4AQ +44 (0) 118 9306060 Specialists in Network Security and Network Integration info@Integralis.com http://www.integralis.com DISCLAIMER Any opinions expressed in this email are those of the individual and not necessarily the Company. This email and any files transmitted with it, including replies and forwarded copies (which may contain alterations) subsequently transmitted from the Company, are confidential and solely for the use of the intended recipient. It may contain material protected by attorney-client privilege. If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that you have received this email in error and that any use is strictly prohibited. If you have received this email in error please notify the IT manager by telephone on +44 (0)118 930 6060 or via email to internal.security@integralis.com, including a copy of this message. Please then delete this email and destroy any copies of it. From dhcp-v4@bucknell.edu Mon Aug 9 14:40:20 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11889 for ; Mon, 9 Aug 1999 14:40:20 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA32209; Mon, 9 Aug 1999 14:38:00 -0400 (EDT) Date: Mon, 9 Aug 1999 14:38:00 -0400 (EDT) Message-Id: <47FEF5D2BE22D311AA8600508B10891503F78D@fs-sd-exch1.coppermountain.com> Errors-To: droms@bucknell.edu Reply-To: emichelsen@coppermountain.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Eric Michelsen To: Multiple recipients of list Subject: RE: Patent application for draft-dhcp-agent-options X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; X-Mailer: Internet Mail Service (5.5.2448.0) Mime-Version: 1.0 > -----Original Message----- > From: Ted Lemon [mailto:mellon@isc.org] > Sent: Saturday, August 07, 1999 9:09 > To: Multiple recipients of list > Subject: Re: Patent application for draft-dhcp-agent-options > .. > > I am asking you to take personal responsibity for this. You > personally got up in front of all of us and made your proposal, > without giving us all the facts. You then let us believe for over a > year and a half that this was going to be a free and open standard, > which you now tell us it is not. You made free with our resources > and good will, and now it looks like you're going to patent the > results. At one time, an inventor could only file a patent within one year of any *public disclosure.* I assume this is still true. Can a valid patent application be filed for an invention that was publicly disclosed a year and a half ago? From dhcp-v6@bucknell.edu Mon Aug 9 17:56:39 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14170 for ; Mon, 9 Aug 1999 17:56:38 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA22918; Mon, 9 Aug 1999 17:53:56 -0400 (EDT) Date: Mon, 9 Aug 1999 17:53:56 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v6@bucknell.edu Sender: dhcp-v6@bucknell.edu Precedence: bulk From: Mike Carney - SNT Internet Engineering To: Multiple recipients of list Subject: Clarification sought for Oslo minutes regarding DHCPv6... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion list for DHCPv6 internet protocol. Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Mime-Version: 1.0 Hi folks, Could the person(s) who made the following suggestions please clarify what you meant? (a paragraph would be nice). Please send your description to me, copy Current technical issues * How does a client request addresses from multiple prefixes? DHCPv4 features to carry forward/misfeatures to avoid/missing features to add * "Echo option" - client retains and echoes option value from server * Explicit "change server" mechanism DHCPv6 new features * Consistency across client implementations: - List of client-supported options - Client can explicitly reject options as unsupported/unrequested - Alternative actions: what to do if option unrecognized, unrequested, ... - Requested values: client gives range of desired values. Document structure * Additional discussion needed about why complicated actions are mandated and how there were arrived at. WG to send input to authors about parts of the spec that require additional discussion. Could the WG please do this? Thanks much for your input, Mike Carney SNT Internet Engineering Sun Microsystems, Inc. Mailstop UBUR02-212 One Network Drive Burlington, MA 01803 From dhcp-v4@bucknell.edu Mon Aug 9 18:01:07 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14258 for ; Mon, 9 Aug 1999 18:01:06 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA03820; Mon, 9 Aug 1999 17:59:43 -0400 (EDT) Date: Mon, 9 Aug 1999 17:59:43 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: Michael.Carney@East.Sun.COM Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Mike Carney - SNT Internet Engineering To: Multiple recipients of list Subject: Clarification sought for Oslo minutes regarding DHCPv6... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Mime-Version: 1.0 Hi folks, Could the person(s) who made the following suggestions please clarify what you meant? (a paragraph would be nice). Please send your description to me, copy Current technical issues * How does a client request addresses from multiple prefixes? DHCPv4 features to carry forward/misfeatures to avoid/missing features to add * "Echo option" - client retains and echoes option value from server * Explicit "change server" mechanism DHCPv6 new features * Consistency across client implementations: - List of client-supported options - Client can explicitly reject options as unsupported/unrequested - Alternative actions: what to do if option unrecognized, unrequested, ... - Requested values: client gives range of desired values. Document structure * Additional discussion needed about why complicated actions are mandated and how there were arrived at. WG to send input to authors about parts of the spec that require additional discussion. Could the WG please do this? Thanks much for your input, Mike Carney SNT Internet Engineering Sun Microsystems, Inc. Mailstop UBUR02-212 One Network Drive Burlington, MA 01803 From dhcp-v4@bucknell.edu Mon Aug 9 18:03:58 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14270 for ; Mon, 9 Aug 1999 18:03:58 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id SAA00646; Mon, 9 Aug 1999 18:03:33 -0400 (EDT) Date: Mon, 9 Aug 1999 18:03:33 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dwason@ersi.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "David Wason" To: Multiple recipients of list Subject: Bootp/tftp IP address question X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset=US-ASCII Mime-Version: 1.0 X-Mailer: Novell GroupWise 5.2 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA14270 What is the best way, within the standards, for the bootp response to indicate an IP address other than that of the DHCP server for the location of the tftp function? We have a device that receives its IP address and downloads its operating software by means of a bootp/tftp process. Up 'till now this device has been using the contents of the server address field of the bootp response as the address of the tftp daemon. This works fine when the bootp daemon is running on a local processor in the same location as our device. One of our clients, operating out of multiple locations, has recently implemented a central DHCP server, with DHCP relay daemons running on the local processor at each site. This results in our devices attempting to use the tftp daemon on the central DHCP server. For performance reasons it is desirable to return the tftp function to the local processor (the one running the DHCP relay). Thanks for any help you can give. Dave Wason From dhcp-v4@bucknell.edu Mon Aug 9 20:18:38 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15111 for ; Mon, 9 Aug 1999 20:18:38 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id UAA17645; Mon, 9 Aug 1999 20:17:09 -0400 (EDT) Date: Mon, 9 Aug 1999 20:17:09 -0400 (EDT) Message-Id: <492567C8.008398A1.00@d22mta10.yamato.ibm.com> Errors-To: droms@bucknell.edu Reply-To: TOSHIS@jp.ibm.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Toshimasa Shimizu" To: Multiple recipients of list X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 UNSUBSCRIBE From dhcp-v4@bucknell.edu Mon Aug 9 20:52:44 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15408 for ; Mon, 9 Aug 1999 20:52:43 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id UAA10905; Mon, 9 Aug 1999 20:51:10 -0400 (EDT) Date: Mon, 9 Aug 1999 20:51:10 -0400 (EDT) Message-Id: <3.0.32.19990810102930.009ffa50@cryptic.rch.unimelb.edu.au> Errors-To: droms@bucknell.edu Reply-To: boon@cryptic.rch.unimelb.edu.au Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Boon Chia To: Multiple recipients of list X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: Windows Eudora Pro Version 3.0 (32) unsubscribe From dhcp-v4@bucknell.edu Mon Aug 9 23:42:17 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18320 for ; Mon, 9 Aug 1999 23:42:14 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id XAA06603; Mon, 9 Aug 1999 23:40:14 -0400 (EDT) Date: Mon, 9 Aug 1999 23:40:14 -0400 (EDT) Message-Id: <199908100333.XAA00733@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: Bootp/tftp IP address question X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > What is the best way, within the standards, for the bootp response > to indicate an IP address other than that of the DHCP server for the > location of the tftp function? This is what siaddr is supposed to be used for - if you want to do tftp from some other IP address, you set siaddr to that IP address. > For performance reasons it is desirable to > return the tftp function to the local processor (the one running the > DHCP relay). Thanks for any help you can give. If they're using the ISC DHCP server, in each subnet declaration you would write a next-server statement with the IP address of the tftp server. _MelloN_ From dhcp-v4@bucknell.edu Tue Aug 10 00:17:10 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18579 for ; Tue, 10 Aug 1999 00:17:09 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id AAA31117; Tue, 10 Aug 1999 00:15:35 -0400 (EDT) Date: Tue, 10 Aug 1999 00:15:35 -0400 (EDT) Message-Id: <199908100341.XAA0000023007@quarry.zk3.dec.com> Errors-To: droms@bucknell.edu Reply-To: bound@zk3.dec.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Jim Bound To: Multiple recipients of list Subject: Re: Patent application for draft-dhcp-agent-options X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 >At one time, an inventor could only file a patent within one year of any >*public disclosure.* I assume this is still true. Can a valid patent >application be filed for an invention that was publicly disclosed a year and >a half ago? According to the lawyers I have for such matters it was true 9 months ago. Two potential patents I wanted to put forth were not done for the reasons above. I had disclosed them a year before in some papers. They are now in the public domain. In my case I was concerned and thought I should do them for defensive reasons as a vendor (defensive patent), because for 90% of the cases I think software patents are bogus and very questionable regarding "orginal" idea especially in the space around that which is used by and within the TCP/IP protocol suite. But I was convinced to check with the process because I would be bummed if someone patented an idea I worked on with others which I lead as one example. When Thomas Jefferson started the patent office in the U.S. Govt from what I have learned about the man after many years of studying him we are yet again not using what his vision was, like so many other things he gave us (e.g. public education, separation church/state, Fededralism). /jim From dhcp-v4@bucknell.edu Tue Aug 10 10:52:45 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17805 for ; Tue, 10 Aug 1999 10:52:44 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA06536; Tue, 10 Aug 1999 10:47:39 -0400 (EDT) Date: Tue, 10 Aug 1999 10:47:39 -0400 (EDT) Message-Id: <199908101431.KAA02535@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: Patent application for draft-dhcp-agent-options X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 I guess I should know better by now than to publically demand an apology on a mailing list when I don't know the facts. Michael, having heard what Kirk has to say, it is now clear to me that you did not intend to do what I feared you'd intended to do. I made an unwarranted assumption, and publically castigated you based on that assumption. I'm sorry for doing so, and I hope you can forgive me. _MelloN_ From dhcp-v4@bucknell.edu Tue Aug 10 11:37:25 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19013 for ; Tue, 10 Aug 1999 11:37:22 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA09804; Tue, 10 Aug 1999 11:35:27 -0400 (EDT) Date: Tue, 10 Aug 1999 11:35:27 -0400 (EDT) Message-Id: <199908101508.QAA13406@castor.acu.ac.uk> Errors-To: droms@bucknell.edu Reply-To: a.west@acu.ac.uk Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Alexandra West" To: Multiple recipients of list Subject: Config question X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Pegasus Mail for Win32 (v3.11) Content-Transfer-Encoding: 7BIT Content-Type: text/enriched; charset=US-ASCII Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT 0000,0000,0000I apologize in advance if this question makes anyone's stomach turn. I've configured dhcp so that most clients obtain an IP address linked to their Mac address: subnet 194.81.120.0 netmask 255.255.255.0{ } host arcturus { hardware ethernet 00:e0:29:1c:c8:76; fixed-address 194.81.120.110; } host polaris { hardware ethernet 00:e0:29:05:54:a0; fixed-address 194.81.120.111; } etc. This is working fine and has been for some weeks now. I'd now like to add a statement to the config file which allows dynamic IP address allocation for occasional internal clients (i.e. laptops). Since the subnet has already been defined at the beginning of the file I assume it needn't be repeated. Unfortunately, I'm unsure about the syntax and (not yet being a hardenend Linux user) the man pages didn't make complete sense to me. range 194.81.120.200 194.81.120.219; What else do I need? Help would be much appreciated. Thanks Alexandra From dhcp-v4@bucknell.edu Tue Aug 10 11:38:03 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19036 for ; Tue, 10 Aug 1999 11:38:03 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA29665; Tue, 10 Aug 1999 11:36:30 -0400 (EDT) Date: Tue, 10 Aug 1999 11:36:30 -0400 (EDT) Message-Id: <37B04606.751D8A59@integralis.co.uk> Errors-To: droms@bucknell.edu Reply-To: paul.barker@integralis.co.uk Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Paul Barker To: Multiple recipients of list Subject: (no subject) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.61 [en] (Win98; I) Content-Transfer-Encoding: 7bit UNSUBSCRIBE Integralis Network Systems Ltd Theale House Brunel Road Theale, Reading RG7 4AQ +44 (0) 118 9306060 Specialists in Network Security and Network Integration info@Integralis.com http://www.integralis.com DISCLAIMER Any opinions expressed in this email are those of the individual and not necessarily the Company. This email and any files transmitted with it, including replies and forwarded copies (which may contain alterations) subsequently transmitted from the Company, are confidential and solely for the use of the intended recipient. It may contain material protected by attorney-client privilege. If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that you have received this email in error and that any use is strictly prohibited. If you have received this email in error please notify the IT manager by telephone on +44 (0)118 930 6060 or via email to internal.security@integralis.com, including a copy of this message. Please then delete this email and destroy any copies of it. From dhcp-v4@bucknell.edu Tue Aug 10 12:08:26 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19771 for ; Tue, 10 Aug 1999 12:08:26 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA23978; Tue, 10 Aug 1999 12:06:45 -0400 (EDT) Date: Tue, 10 Aug 1999 12:06:45 -0400 (EDT) Message-Id: <199908101549.LAA03019@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: Config question X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > range 194.81.120.200 194.81.120.219; That's it. Put it in the subnet declaration. _MelloN_ From dhcp-v6@bucknell.edu Tue Aug 10 12:40:03 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20250 for ; Tue, 10 Aug 1999 12:40:03 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA11712; Tue, 10 Aug 1999 12:38:23 -0400 (EDT) Date: Tue, 10 Aug 1999 12:38:23 -0400 (EDT) Message-Id: <199908101604.SAA18232@givry.inria.fr> Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v6@bucknell.edu Sender: dhcp-v6@bucknell.edu Precedence: bulk From: Francis Dupont To: Multiple recipients of list Subject: Re: Clarification sought for Oslo minutes regarding DHCPv6... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion list for DHCPv6 internet protocol. In your previous mail you wrote: Could the person(s) who made the following suggestions please clarify what you meant? (a paragraph would be nice). Please send your description to me, copy Current technical issues * How does a client request addresses from multiple prefixes? => a client boots on a link with more than one global prefix, how the client gets an address per prefix? An example should be enough (there are many ways to solve this issue but only one should be correct). Regards Francis.Dupont@inria.fr From dhcp-v4@bucknell.edu Tue Aug 10 12:45:34 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20348 for ; Tue, 10 Aug 1999 12:45:32 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA21814; Tue, 10 Aug 1999 12:43:12 -0400 (EDT) Date: Tue, 10 Aug 1999 12:43:12 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: derdmann@nortelnetworks.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "David Erdmann" To: Multiple recipients of list Subject: options question X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Hi! I have a very simple question. Given one DHCP request with options in it, can you have multiple instances of options of the same type? For instance if you had 2 User Class option fields for some reason, be it that a client was trying to pass more information than the single option field would allow, or it made a mistake. What should the behaviour of the DHCP server be? -Dave ---------------------------------- Dave Erdmann Nortel Networks, NetID Group mailto:derdmann@nortelnetworks.com From dhcp-v4@bucknell.edu Tue Aug 10 13:20:59 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21031 for ; Tue, 10 Aug 1999 13:20:59 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA06902; Tue, 10 Aug 1999 13:17:56 -0400 (EDT) Date: Tue, 10 Aug 1999 13:17:56 -0400 (EDT) Message-Id: <199908101652.MAA03183@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: options question X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > I have a very simple question. Given one DHCP request with options > in it, can you have multiple instances of options of the same type? There's really no provision for this in the protocol, no. If you want to be able to claim more than one user class, you need to figure out a way to do it in a single user class option. For example, send sales+winnt4+building-a in the user class option, and have your DHCP server know to split this into three classes. The ISC DHCP server could be easily tweaked to handle things this way, and it shouldn't be a problem to enter the user class into your client this way. _MelloN_ From dhcp-v4@bucknell.edu Tue Aug 10 15:42:35 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22769 for ; Tue, 10 Aug 1999 15:42:35 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA29939; Tue, 10 Aug 1999 15:39:43 -0400 (EDT) Date: Tue, 10 Aug 1999 15:39:43 -0400 (EDT) Message-Id: <199908101901.PAA00995@hygro.adsl.duke.edu> Errors-To: droms@bucknell.edu Reply-To: narten@raleigh.ibm.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Thomas Narten To: Multiple recipients of list Subject: Web Proxy Auto-Discovery Protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 DHCP WG: The document draft-ietf-wrec-wpad-01.txt (among other things) defines a new DHCP option. It also defines a number of techniques for locating a configuration file (i.e., one that tells the browser what proxies to use). The draft does call for some interesting DHCP behavior I'd be interested in getting WG feedback on. Specifically, it seems to change the DHCP model a bit in that you don't just use DHCP when you boot (or when the DHCP timers tell you to contact the server again). Instead, it uses the INFORM message to query a DHCP server whenever the browser thinks it needs to get a new configuration file. Quoting from the draft: > Full client support for DHCP is not as ubiquitous as for DNS. That > is, not all clients are equipped to take advantage of DHCP for their > essential network configuration (assignment of IP address, network > mask, etc). APIs for DHCP are not as widely available. Luckily, > using DHCP for WPAD does not require either of these facilities. It > is relatively easy for web client developers to speak just the > minimal DHCP protocol to perform resource discovery. It entails > building a simple UDP packet, sending it to the subnet broadcast > address, and parsing the reply UDP packet(s) which are received to > extract the WPAD option field. A reference implementation of this > code in C is available [11]. then later: > In addition, the client MUST attempt a discovery cycle upon > expiration of a previously downloaded CFILE in accordance with > HTTP/1.1. I.e. when you find a configuration file and use HTTP to fetch it, the HTTP header tells you how long you may cache the file. When lifetime expires, you have to fetch a new config file. But rather than just fetching the same one, you restart the discovery process, including rerunning DHCP (not full blown DHCP, just INFORM/ACK). In the following, my read is that you must rerun DHCP when you start the browser the first time (or when you restart it): > 4.2.1. Upon Startup of the Web Client > > For many types of web client (like web browsers) there can be many > instances of the client operating for a given user at one time. This > is often to allow display of multiple web pages in different > windows, for example. There is no need to re-perform WPAD every time > a new instance of the web client is opened. WPAD MUST be performed > when the number of web client instances transitions from 0 to 1. It > SHOULD NOT be performed as additional instances are created. Is the above consistent with the intended usage of the INFORM message? Are folks OK with this sort of extension to the DHCP model? Is DHCP already being used in this sort of way, or would this be a new thing? Thomas From dhcp-v4@bucknell.edu Tue Aug 10 16:53:27 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23816 for ; Tue, 10 Aug 1999 16:53:26 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA11618; Tue, 10 Aug 1999 16:51:43 -0400 (EDT) Date: Tue, 10 Aug 1999 16:51:43 -0400 (EDT) Message-Id: <199908102026.PAA41632@us.networkcs.com> Errors-To: droms@bucknell.edu Reply-To: salo@networkcs.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Tim Salo To: Multiple recipients of list Subject: Re: Patent application for draft-dhcp-agent-options X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Date: Tue, 10 Aug 1999 10:54:41 -0400 (EDT) > From: Ted Lemon > To: Multiple recipients of list > Subject: Re: Patent application for draft-dhcp-agent-options > [...] > Michael, having heard what Kirk has to say, it is now clear to me that > you did not intend to do what I feared you'd intended to do. I made > an unwarranted assumption, and publically castigated you based on that > assumption. I'm sorry for doing so, and I hope you can forgive me. Ted Lemon, I believe your e-mail represents a level of professionalism to which we all ought to aspire and that, were it more widespread, would considerably strengthen the IETF. Nice job, -tjs From dhcp-v4@bucknell.edu Tue Aug 10 22:16:46 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28804 for ; Tue, 10 Aug 1999 22:16:46 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id WAA26699; Tue, 10 Aug 1999 22:15:10 -0400 (EDT) Date: Tue, 10 Aug 1999 22:15:10 -0400 (EDT) Message-Id: <37B0D82B.D13A8785@ehsco.com> Errors-To: droms@bucknell.edu Reply-To: ehall@ehsco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Eric A. Hall" To: Multiple recipients of list Subject: Re: Web Proxy Auto-Discovery Protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.6 [en] (WinNT; I) Content-Transfer-Encoding: 7bit > Is the above consistent with the intended usage of the INFORM message? Seems appropriate usage to me. > Are folks OK with this sort of extension to the DHCP model? Is DHCP > already being used in this sort of way, or would this be a new thing? I would think that there is an easier path to the same goal, and that is to define an "HTTP proxy" extension. There are already several extensions for things like "default home page" and "POP3 server" and so forth. Why not just do another one for "HTTP proxy" rather than screwing around with a configuration file? You could use DHCPINFORM on that all day long without introducing yet another configuration format. For a list of all the current BOOTP/DHCP extensions, see the IANA's list at http://www.isi.edu/in-notes/iana/assignments/bootp-dhcp-extensions/ -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Wed Aug 11 12:17:52 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01271 for ; Wed, 11 Aug 1999 12:17:52 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA01260; Wed, 11 Aug 1999 12:14:22 -0400 (EDT) Date: Wed, 11 Aug 1999 12:14:22 -0400 (EDT) Message-Id: <006201bee411$97d13600$399b309b@b0hl2g.BABSON.EDU> Errors-To: droms@bucknell.edu Reply-To: hanlon@babson.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Martha Hanlon" To: Multiple recipients of list X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook Express 4.72.3155.0 Content-Type: multipart/alternative; Mime-Version: 1.0 This is a multi-part message in MIME format. ------=_NextPart_000_005A_01BEE3F0.0CF399E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable unsubscribe dhcp-v4 Martha Hanlon ------=_NextPart_000_005A_01BEE3F0.0CF399E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
unsubscribe dhcp-v4 Martha Hanlon
------=_NextPart_000_005A_01BEE3F0.0CF399E0-- ------- From dhcp-v6@bucknell.edu Wed Aug 11 19:25:56 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08185 for ; Wed, 11 Aug 1999 19:25:55 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id TAA14179; Wed, 11 Aug 1999 19:23:48 -0400 (EDT) Date: Wed, 11 Aug 1999 19:23:48 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v6@bucknell.edu Sender: dhcp-v6@bucknell.edu Precedence: bulk From: Mike Carney - SNT Internet Engineering To: Multiple recipients of list Subject: Re: Clarification sought for Oslo minutes regarding DHCPv6... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion list for DHCPv6 internet protocol. Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Mime-Version: 1.0 Hi folks - awfully silent out there... can someone help me out and clarify the following suggestions? TIA. > Hi folks, > > Could the person(s) who made the following suggestions please clarify what > you meant? (a paragraph would be nice). Please send your description > to me, copy > > Current technical issues > > * How does a client request addresses from multiple prefixes? > > > DHCPv4 features to carry forward/misfeatures to avoid/missing features to add > > * "Echo option" - client retains and echoes option value from server > > * Explicit "change server" mechanism > > > DHCPv6 new features > > * Consistency across client implementations: > - List of client-supported options > - Client can explicitly reject options as unsupported/unrequested > - Alternative actions: what to do if option unrecognized, > unrequested, ... > - Requested values: client gives range of desired values. > > Document structure > > * Additional discussion needed about why complicated actions are mandated > and how there were arrived at. WG to send input to authors about parts > of the spec that require additional discussion. Could the WG please > do this? > > > Thanks much for your input, > > > Mike Carney > SNT Internet Engineering > Sun Microsystems, Inc. > Mailstop UBUR02-212 > One Network Drive > Burlington, MA 01803 > > From dhcp-v4@bucknell.edu Thu Aug 12 11:50:30 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16332 for ; Thu, 12 Aug 1999 11:50:29 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA14892; Thu, 12 Aug 1999 11:48:09 -0400 (EDT) Date: Thu, 12 Aug 1999 11:48:09 -0400 (EDT) Message-Id: <7D59C5D744D3D211BF300008C7088E8302F77562@nt000034.ral.cplc.com> Errors-To: droms@bucknell.edu Reply-To: david.haygood@cplc.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Haygood, David" To: Multiple recipients of list X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Internet Mail Service (5.5.2448.0) Mime-Version: 1.0 subscribe dhcp-v4 David Haygood David W. Haygood Networked Systems Management CDC Caronet 770-6134 Text Page: david.haygood.pager@cplc.com From dhcp-v4@bucknell.edu Thu Aug 12 21:22:53 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24575 for ; Thu, 12 Aug 1999 21:22:53 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id VAA06619; Thu, 12 Aug 1999 21:18:32 -0400 (EDT) Date: Thu, 12 Aug 1999 21:18:32 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: droms@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ralph Droms To: Multiple recipients of list Subject: Re: Web Proxy Auto-Discovery Protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 At 3:00 PM 8/10/99 -0400, Thomas Narten wrote: >[...]it uses the INFORM message to query a DHCP server whenever the browser >thinks it needs to get a new configuration file. >[...] >Is the above consistent with the intended usage of the INFORM message? In general, I'm comfortable with the intended usage of the INFORM message. I don't see that using DHCPINFORM to obtain additional configuration parameters affects the definition of the protocol or the operation of DHCP servers. I am, unsure of a detail, which is both an implementation question and a theoretical question: If more than one software system (e.g., a DHCP client and a web client) are trying to share the same incoming UDP port, how are incoming messages routed to the appropriate system? For example, in a system where the DHCP client opens (and leaves open while running as a daemon - I'm thinking of UNIX-like systems, here) the DHCPC UDP port to receive incoming DHCP messages, how does the web client arrange to receive responses to its DHCPINFORM messages? Even if there is a way for more than one software system to share the UDP port, how are incoming messages demuxed to the appropriate destination? Suppose a web client happens to send a DHCPINFORM at almost the same time as the DHCP client renews the host's lease and sends a DHCPREQUEST? How are the two responses - which may, of course, arrive in any order - demuxed? - Ralph From dhcp-v4@bucknell.edu Fri Aug 13 00:28:53 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28441 for ; Fri, 13 Aug 1999 00:28:53 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id AAA04784; Fri, 13 Aug 1999 00:27:03 -0400 (EDT) Date: Fri, 13 Aug 1999 00:27:03 -0400 (EDT) Message-Id: <37B39794.EDDA16B5@ehsco.com> Errors-To: droms@bucknell.edu Reply-To: ehall@ehsco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Eric A. Hall" To: Multiple recipients of list Subject: Re: Web Proxy Auto-Discovery Protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.6 [en] (WinNT; I) Content-Transfer-Encoding: 7bit > in a system where the DHCP client opens (and leaves open while > running as a daemon - I'm thinking of UNIX-like systems, here) the > DHCPC UDP port to receive incoming DHCP messages, how does the web > client arrange to receive responses to its DHCPINFORM messages? I did a light survey of a dozen or so DHCP clients, and the ISC client is the only way that stays permanently bound to the socket that I know of. The rest of them release the socket when inactive (as it should be, IMHO). It's still a valid point mind you, since there's nothing to prevent a DHCP client from staying permanently bound, but as it stands today its a non-issue for almost all clients. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Fri Aug 13 11:14:35 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03028 for ; Fri, 13 Aug 1999 11:14:35 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA23753; Fri, 13 Aug 1999 11:11:31 -0400 (EDT) Date: Fri, 13 Aug 1999 11:11:31 -0400 (EDT) Message-Id: <37B42B70.55A9EEC1@sun.com> Errors-To: droms@bucknell.edu Reply-To: dave.miner@sun.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Dave Miner To: Multiple recipients of list Subject: Re: Web Proxy Auto-Discovery Protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) Content-Transfer-Encoding: 7bit The question that came to my mind in reading this message is this: why aren't they using SLP (Service Location Protocol) instead? It seems to have been designed for just this sort of usage. Obvious answer is that SLP isn't deployed (yet), but you probably need some application uses to get it deployed to begin with, so when would this answer cease to be acceptable? Dave From dhcp-v6@bucknell.edu Sat Aug 14 07:47:29 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02198 for ; Sat, 14 Aug 1999 07:47:28 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id HAA19943; Sat, 14 Aug 1999 07:43:31 -0400 (EDT) Date: Sat, 14 Aug 1999 07:43:31 -0400 (EDT) Message-Id: <19990814133551.A2701@itea.ntnu.no> Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v6@bucknell.edu Sender: dhcp-v6@bucknell.edu Precedence: bulk From: Stig Venaas To: Multiple recipients of list Subject: Re: Clarification sought for Oslo minutes regarding DHCPv6... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion list for DHCPv6 internet protocol. X-Mailer: Mutt 0.93.2i Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Hi all On Mon, Aug 09, 1999 at 05:55:43PM -0400, Mike Carney - SNT Internet Engineering wrote: > Hi folks, > > Could the person(s) who made the following suggestions please clarify what > you meant? (a paragraph would be nice). Please send your description > to me, copy > > DHCPv6 new features > > * Consistency across client implementations: > - List of client-supported options > - Client can explicitly reject options as unsupported/unrequested > - Alternative actions: what to do if option unrecognized, > unrequested, ... > - Requested values: client gives range of desired values. I'm trying to remember myself. I think my first suggestion was that the client could in the solicit message indicate which extensions it knew of (or options as I guess I said at the meeting). The format could be similar to extensions in request messages. I think it should be optional for the client to do this, and what the server does should be undefined as well. I'm not sure how much use this is, it was just a spurious thought during the meeting. The second thought I had which I think might be more useful, is that the client could send extensions with the solicit message to indicate minimum requirements. If the client is looking for a spesific resource, or a spesific amount or value of some extension it would be nice if this could be done in the solicit, again similar to the options in request messages. The servers should then reply with an advertisement only if it can satisfy these requirements at the moment (when the client later requests them, it may be impossible to deliver). I think this may be useful if you have a scenario with several DHCP servers that can give out different resources. I'm not sure how useful this is either. These are just ideas. Another thing I've been thinking of that I did not bring up, is whether non-DHCP servers should be able to send reconfigure messages. I can think of at least one case where I think it's useful. Of course there would have to be some flag indicating that it's not from a server, so that the client instead of sending a request to the sender of the reconfigure message, issues a request to some DHCP server if it wants to. The server is just telling a client that it would be a good idea if it got hold of some resource, and it should then be up to the client if it asks some DHCP server for it, get hold of the resource in some other way, or simply ignores it. What do you think? This is perhaps outside the scope of DHCP, a client and a server could figure this out in some other way. > Document structure > > * Additional discussion needed about why complicated actions are mandated > and how there were arrived at. WG to send input to authors about parts > of the spec that require additional discussion. Could the WG please > do this? Personally I think the structure is okay. But I've been reading carefully through draft-ietf-dhc-dhcpv6-14.txt again, and I've got some comments. Agent is defined at the end of 2.2. Both the definition of message in 2.1 and agent address in 2.2 should perhaps come after the definition of agent. Near the end of 3.3: A DHCP server or agent MUST transmit all messages to DHCP clients on UDP port 546. A DHCP client MUST transmit all messages to a DHCP agent over UDP using port 547. A DHCP server MUST transmit all messages to DHCP relays over UDP on port 546. The source port for DHCP messages is arbitrary. In the first sentence, it should be relay rather than agent I think. In my opinion the following phrasing would be slightly better: A DHCP agent MUST transmit all messages to DHCP clients and relays over UDP using port 546. A DHCP client MUST transmit all messages to a DHCP agent over UDP using port 547. The source port for DHCP messages is arbitrary. The last paragraph of 3.3: For the proper operation of the DHCP protocol to operate within a network where one or more firewallsare used, DHCP transactions sent to the IP addresses of DHCP servers at UDP destination ports 546 and 547 will need to be permitted. Why should one permit destination 546, if messages are only sent to port 547? To me it seems reasonable to permit messages sent to addresses of servers with destination port 547 and messages sent from servers with destination port 546. In the last paragraph of 4.2 it says: The server MUST copy the client's link-local address into the advertisement which is sent in response to a DHCP Solicit. Both server-address (if present) and agent-address of the DHCP Advertise message MUST have sufficient scope to be reachable by the client. Moreover, the agent-address of any DHCP Advertise message sent by a relay MUST NOT be a link-local address. In situations where there In the last line I think relay should be server, since the relay simply passes on what it got from the server. What about replacing this with: If the relay-address is nonzero, the server MUST copy it into the agent-address field of the advertisement message. Which is what it says in 6.2. The last paragraph of 5.3 says suggests that the client may cache the result of any advertisements, while in 5.4 it says: retransmit according to the rules in Section 8. If (after following those rules) the client has not received a Reply message, it SHOULD start over again by multicasting a new DHCP Solicit message to find a different server. If the client receives an ICMP error message in response to such a DHCP Request, it likewise SHOULD start over again by multicasting a new DHCP Solicit message, to find a different server. I think it should say something about using cached advertisements, or do you think it's enough to state this in 5.3? Apart from this it looks just fine to me, Stig Venaas UNINETT/NTNU From dhcp-v6@bucknell.edu Tue Aug 17 00:11:43 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21205 for ; Tue, 17 Aug 1999 00:11:42 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id AAA27018; Tue, 17 Aug 1999 00:05:46 -0400 (EDT) Date: Tue, 17 Aug 1999 00:05:46 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v6@bucknell.edu Sender: dhcp-v6@bucknell.edu Precedence: bulk From: Mike Carney - SNT Internet Engineering To: Multiple recipients of list Subject: DHCPv6 issues list X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion list for DHCPv6 internet protocol. Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Mime-Version: 1.0 Hi Folks, Here are the list of issues we've captured. We (the authors) are currently producing an item by item response for these issues. If we've missed some or have gotten some wrong, please let me know. bound/mwc/perkins List of DHCPv6 Issues to resolve ================================ DHCPv4 disadvantages to avoid: ============================== * Lack of mechanism for defining server priority. * BOOTP heritage. DHCP suffers alot from overloading the BOOTP packet format simply to leverage BOOTP relay agent functionality. * Current option format too restrictive. Not enough options, value lengths too small. Alleviating this problem in DHCPv4 made difficult due to BOOTP heritage. * Lack of DHCP protocol versioning in original specification. * Changes to options in most cases necessitate changes to client and server implementations. Can we avoid this by carefully specifying suggested generic encoding mechanisms? * Uses broadcast. Response: IPv6 doesn't have broadcast. * Overloading single Packet type for multiple purposes. DHCPREQUEST's use in INIT, INIT-REBOOT, and RENEW/REBIND has been a source of major confusion for implementors. We should avoid overloading packet types as much as possible. * Confusion regarding minimum packet size. Some say BOOTP size (300bytes) is the minimum, whereas others say the minimum is the fixed part of the BOOTP header. * Confusion about interaction between vendor class id and encapsulated vendor option. Verbiage in original RFC 1541 appears to have been deleted in RFC 2131. * Change in RFC 1541 -> RFC 2131 INIT-REBOOT DHCPREQUEST format was not backward compatible. DHCPv4 advantages, DHCPv4-based questions ========================================= * Does not require service on every link; service can be remote from client's link * State transition diagram clarifies client / server interaction. * Has specified an optional server to server synchronization protocol. * Echo option would be handy in DHCPv6. (client retains option value to later echo back to server). * Change server explicit option. * Client version * DHCP server load balancing * DHCPv4 / DNS interaction finally reaching maturity. How well defined is this in DHCPv6? * Is what has been learned during the DHCP authentication draft development useful in the discussion in the v6 extensions draft? DHCPv6 draft issues =================== * Document organization makes protocol unclear. Information is duplicated, some info contradictory. * Consider merging two documents into one * What is the process for defining, reviewing, and acceptance of new extensions? Particularly when there are DHCPv4 options for the same item? * RECONFIGURE / renumbering semantics unclear. * Do we still need the added complication of the ability to request multiple addresses, in the light of http 1.1? (this support is seen as a source of major complication in the current draft) * What about the new media becoming available? How well will DHCPV6 work in these environments? Example: IEEE 1394, USB, CDN. What about traditional environments? ATM, FDDI. Are there any issues with multicast in these environments? What about PPP? * There isn't a clear state machine defined. * No background explanations for complicated message exchanges. * General lack of background for complication (seemingly) in protocol itself. * Lack of a DHCPv4 -> DHCPv6 section describing the differences between the protocols (useful for DHCPv4 folks thinking about implementing DHCPv6). * Seems like there are too many alternatives for releasing resources. * (Section 6) Is the mandate for implementation strategy too strong? Why is XID transaction cache described in such detail? * Which messages are not idempotent (and why not?) * How does a client request addresses from multiple prefixes? * Does the RECONFIGURE mechanism scale wrt ACK implosion? New RECONFIGURE reduces messages from 2N to N, but N may still be large. * In case of a RECONFIGURE failure, loosen text to specify "notify administrator" (rather than "log to error log"). * Section 6.3.2: Clarify that 'C' bit semantics are to release all resources, reallocate only those requested in message. * Section 6.4: What does client do with response? Add MUST/SHOULD. * RFC 2119 terminology misused. * retransmission backoff not always exponential, and is sometimes too short. * Error codes not sequential, and there is no discussion of how error codes are allocated (IANA?) * Some extensions require association with server that sent the message (releasable resources?) There is no way to signal this to the client in a way that avoids having to rev the client when new such extensions are deployed. Would be much better to flag such options with a bit that would allow clients to function appropriately w/o change. * No concept of T1/T2 times (or % of lifetimes) for client use when deciding when and how often to contact server to extend various lifetimes for certain extensions, of which IP address is one such extension. * Does a client need to request PTR record update, or is it implied that the server will always do the PTR record update on its behalf? * prefix-size description unclear. * Affect that 'A' and 'Q' bit (MUST update AAAA record before responding) has on retransmission not clear. * Impact that receiving an IP address with 0 lifetime as denial of service attack not handled. Need to look at addrconf solution to this problem. From dhcp-v4@bucknell.edu Tue Aug 17 06:16:48 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08439 for ; Tue, 17 Aug 1999 06:16:48 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA29198; Tue, 17 Aug 1999 06:14:20 -0400 (EDT) Date: Tue, 17 Aug 1999 06:14:20 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: Re: Web Proxy Auto-Discovery Protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 message sent to dhcp-v4@bucknell.edu by CHARLES.PERKINS@ENG.SUN.COM follows. ---------------------------------------------------------------------------- Hello Dave, The answer is that WPAD does specify the use of SLP. And, in fact, there is a SLP draft for this. But, since DHCP is much more widely deployed than SLP, the document authors seemed reluctant to make SLP the only choice, or even a MUST. It is perfectly valid for working group discussion to indicate further refinements on the existing protocol as it is currently specified in the Internet Draft. Regards, Charlie P. > The question that came to my mind in reading this message is this: why > aren't they using SLP (Service Location Protocol) instead? It seems to > have been designed for just this sort of usage. Obvious answer is that > SLP isn't deployed (yet), but you probably need some application uses to > get it deployed to begin with, so when would this answer cease to be > acceptable? From dhcp-v4@bucknell.edu Tue Aug 17 06:51:34 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08678 for ; Tue, 17 Aug 1999 06:51:33 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA09827; Tue, 17 Aug 1999 06:49:57 -0400 (EDT) Date: Tue, 17 Aug 1999 06:49:57 -0400 (EDT) Message-Id: <199908171045.GAA19919@mail.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: droms@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ralph Droms To: Multiple recipients of list Subject: Re: Web Proxy Auto-Discovery Protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 At 12:28 AM 8/13/99 -0400, ehall@ehsco.com wrote: >I did a light survey of a dozen or so DHCP clients, and the ISC client >is the only way that stays permanently bound to the socket that I know >of. The rest of them release the socket when inactive (as it should be, >IMHO). Thanks for taking a look at existing implementations and posting the results of your survey. There's still the problem of demuxing incoming DHCP messages. If both the DHCP client and an application are trying to use DHCP simultaneously - e.g., the DHCP client is renewing the host's lease on an address while an application is obtaining a web proxy address with a DHCPINFORM message - how would the responses from the DHCP server be routed to the correct destination? - Ralph From dhcp-v4@bucknell.edu Tue Aug 17 10:44:40 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22319 for ; Tue, 17 Aug 1999 10:44:39 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA25765; Tue, 17 Aug 1999 10:42:47 -0400 (EDT) Date: Tue, 17 Aug 1999 10:42:47 -0400 (EDT) Message-Id: <37B9729A.846C975F@ehsco.com> Errors-To: droms@bucknell.edu Reply-To: ehall@ehsco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Eric A. Hall" To: Multiple recipients of list Subject: Re: Web Proxy Auto-Discovery Protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.6 [en] (WinNT; I) Content-Transfer-Encoding: 7bit > If both the DHCP client and an application are trying to use DHCP > simultaneously - e.g., the DHCP client is renewing the host's lease > on an address while an application is obtaining a web proxy address > with a DHCPINFORM message - how would the responses from the DHCP > server be routed to the correct destination? Well they shouldn't be able to do it "simultaneously" since UDP ought to prevent one or the other from binding to the port. However there is a very high likelihood that the two might "overlap" such as when one of them issues a request, times out and unbinds, and then the other binds and receives the response from the first request. I haven't had enough coffee yet to think this through but it would seem that an opportunity exists for some sort of failure to occur. Perhaps there's a generic need for a Transaction-ID option since this type of usage can practically be counted on. As a side note, this would also be required for the multicast client and replication structure I was describing a couple of months ago also (not the multicast relay agent however). In the latter case, the Transaction-ID could be a combination of MAC address and local time (synchronized time is not required; only a unique "key" is needed), and maybe this same format could be useful here (if it's needed, which I'm not sure it is). -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Tue Aug 17 12:09:07 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26359 for ; Tue, 17 Aug 1999 12:09:05 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA09647; Tue, 17 Aug 1999 12:07:25 -0400 (EDT) Date: Tue, 17 Aug 1999 12:07:25 -0400 (EDT) Message-Id: <199908171532.LAA28829@mail.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: Re: Web Proxy Auto-Discovery Protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 message sent to dhcp-v4@bucknell.edu by LAPP@NORTELNETWORKS.COM follows. ------------------------------------------------------------------------ Eric A. Hall wrote: > > > If both the DHCP client and an application are trying to use DHCP > > simultaneously - e.g., the DHCP client is renewing the host's lease > > on an address while an application is obtaining a web proxy address > > with a DHCPINFORM message - how would the responses from the DHCP > > server be routed to the correct destination? > > Well they shouldn't be able to do it "simultaneously" since UDP ought to > prevent one or the other from binding to the port. However there is a > very high likelihood that the two might "overlap" such as when one of > them issues a request, times out and unbinds, and then the other binds > and receives the response from the first request. I haven't had enough > coffee yet to think this through but it would seem that an opportunity > exists for some sort of failure to occur. > > Perhaps there's a generic need for a Transaction-ID option since this > type of usage can practically be counted on. As a side note, this would > also be required for the multicast client and replication structure I > was describing a couple of months ago also (not the multicast relay > agent however). In the latter case, the Transaction-ID could be a > combination of MAC address and local time (synchronized time is not > required; only a unique "key" is needed), and maybe this same format > could be useful here (if it's needed, which I'm not sure it is). > Such a transaction id already exists in bootp/DHCP (the xid field) so another option isn't really needed. Of course, some clients have been known to use the same xid over and over again so this could expose some interesting problems. Fixing the broken clients should be no more difficult then implenting a new option of this type tho. Dave Lapp From dhcp-v6@bucknell.edu Tue Aug 17 12:47:44 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27886 for ; Tue, 17 Aug 1999 12:47:43 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA00039; Tue, 17 Aug 1999 12:42:41 -0400 (EDT) Date: Tue, 17 Aug 1999 12:42:41 -0400 (EDT) Message-Id: <199908171345.PAA30397@givry.inria.fr> Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v6@bucknell.edu Sender: dhcp-v6@bucknell.edu Precedence: bulk From: Francis Dupont To: Multiple recipients of list Subject: Re: DHCPv6 issues list X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion list for DHCPv6 internet protocol. In your previous mail you wrote: DHCPv6 draft issues =================== * Do we still need the added complication of the ability to request multiple addresses, in the light of http 1.1? (this support is seen as a source of major complication in the current draft) => this isn't very clear but I believe "in the light of http 1.1" means multiple addresses in the same prefix, doesn't it? * How does a client request addresses from multiple prefixes? => then this issue is a different one and you do *not* suggest support for multiple prefixes should be dropped (:-)! * There isn't a clear state machine defined. => I have seen one then you should get that... Regards Francis.Dupont@inria.fr From dhcp-v4@bucknell.edu Tue Aug 17 16:00:44 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03967 for ; Tue, 17 Aug 1999 16:00:40 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA10086; Tue, 17 Aug 1999 15:58:17 -0400 (EDT) Date: Tue, 17 Aug 1999 15:58:17 -0400 (EDT) Message-Id: <000e01bee8e8$47ba4900$5f106bd1@office.accsyst.com> Errors-To: droms@bucknell.edu Reply-To: jhall@vramp.net Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Jon Hall" To: Multiple recipients of list X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook Express 4.72.3155.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit subscribe From dhcp-v4@bucknell.edu Wed Aug 18 01:49:05 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19775 for ; Wed, 18 Aug 1999 01:49:05 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id BAA25738; Wed, 18 Aug 1999 01:47:20 -0400 (EDT) Date: Wed, 18 Aug 1999 01:47:20 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: shay.meshulam@aks.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: shay.meshulam@aks.com To: Multiple recipients of list Subject: Can't MAKE the DHCP.... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Lotus Notes Release 5.0 (Intl) 30 March 1999 Hello guys, in the last few days I have been trying to install DHCP service ( download from ISC ) with no success. I try to install all the tree versions but in all of them I got errors line in the MAKE process. is there any way out ? I have to run it on Linux 2.0 and it should support other operation systems ( win NT win95/98 etc' ) thanks for advance, Shay. From dhcp-v6@bucknell.edu Wed Aug 18 03:48:57 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26963 for ; Wed, 18 Aug 1999 03:48:56 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id DAA21015; Wed, 18 Aug 1999 03:37:37 -0400 (EDT) Date: Wed, 18 Aug 1999 03:37:37 -0400 (EDT) Message-Id: <199908180729.JAA15120@kilkenny.inria.fr> Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v6@bucknell.edu Sender: dhcp-v6@bucknell.edu Precedence: bulk From: Jean-Jacques Bernard To: Multiple recipients of list Subject: Re: DHCPv6 issues list X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion list for DHCPv6 internet protocol. Content-Type: multipart/mixed ; Mime-Version: 1.0 This is a multipart MIME message. --==_Exmh_-15868101120 Content-Type: text/plain; charset=us-ascii Michael Carney wrote: > * There isn't a clear state machine defined. I draw a state machine for the client a few time ago. If it can help you, it is attached with this message. -- Jean-Jacques Bernard Email : jean-jacques.bernard@inria.fr --==_Exmh_-15868101120 Content-Type: text/plain ; name="client_states"; charset=us-ascii Content-Description: client_states -------------- | INIT_STATE | -------------- | |Send solicit (see if delay is needed) | | V ---------------- get adv ------------ ----->| SOLICIT_SENT |------------>| WAIT_ADV | timeout | ---------------- pref != 255 ------------ expires | | ^ | | (send solicit) -------| | |get adv | | |with pref = 255 |CLIENT_WAIT_ADV ------------ V |expires | ----------------- | | | SERVER_CHOICE |<------------------ | ----------------- All | | rules |Send |Send request with defined |solicit |t_id > last_t_id in | | section 8 | | fail | V | ---------------- -------| REQUEST_SENT |<------ REPLY_MSG_TIMEOUT expires ---------------- | or AUTH extension failed ^ ^ | |----------- | | |Get reply ----------------- | |with good t_id | --+------------------------ | V | |send ----------------- | |request | PROCESS_REPLY | |User |if ----------------- |action |needed | |which needs | |----- |a request | | |to be sent | V | ------------------ get -------------- | | PROCESS_RECONF |<--------| IDLE_STATE |------------ ------------------ reconf -------------- | ^^ | --------------------------|| |User action if no request need | |or ressource no more to be sent | |needed ----- | get | |send reply | |release message | V ---------------- | RELEASE_SENT | ---------------- --==_Exmh_-15868101120-- ------- From dhcp-v4@bucknell.edu Wed Aug 18 04:10:24 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27082 for ; Wed, 18 Aug 1999 04:10:23 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id EAA14803; Wed, 18 Aug 1999 04:08:52 -0400 (EDT) Date: Wed, 18 Aug 1999 04:08:52 -0400 (EDT) Message-Id: <4.1.19990818015109.009c74a0@mail.join.com> Errors-To: droms@bucknell.edu Reply-To: robs@join.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Rob Stevens To: Multiple recipients of list Subject: Re: Can't MAKE the DHCP.... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 I venture to suggest that you will get a better response to your question if: a) You post it to the proper group. dhcp-v4 is for questions related to the advancement of the DHCP protocol and changes to it. Nobody reading it has any interest in some problem that the ISC code displays. Mail your request to dhcp-interest@isc.org b) You include details. Nobody is going to take the time to respond to a bug report like yours: "it doesn't work". Include version of OS, hardware type, specific error messages, compiler used...etc. Rob Stevens CTO Join Systems From dhcp-v4@bucknell.edu Wed Aug 18 09:11:48 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05699 for ; Wed, 18 Aug 1999 09:11:43 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA08864; Wed, 18 Aug 1999 09:08:33 -0400 (EDT) Date: Wed, 18 Aug 1999 09:08:33 -0400 (EDT) Message-Id: <199908181246.IAA16649@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: Can't MAKE the DHCP.... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Nobody reading > it has any interest in some problem that the ISC code > displays. Mail your request to dhcp-interest@isc.org I wouldn't go quite that far. :') Also, the right mailing list is probably dhcp-server@isc.org, to which you must subscribe before you can send mail. > b) You include details. > Nobody is going to take the time to respond to > a bug report like yours: "it doesn't work". > Include version of OS, hardware type, specific > error messages, compiler used...etc. Yup. Thanks for pointing this out! :') _MelloN_ From dhcp-v4@bucknell.edu Wed Aug 18 09:17:46 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06459 for ; Wed, 18 Aug 1999 09:17:45 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA25334; Wed, 18 Aug 1999 09:17:02 -0400 (EDT) Date: Wed, 18 Aug 1999 09:17:02 -0400 (EDT) Message-Id: <199908181307.JAA00045@mail.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: droms@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ralph Droms To: Multiple recipients of list Subject: Re: Web Proxy Auto-Discovery Protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Well, it seems the semantics of shared UDP ports are implementation-dependent (or at least not well-defined; see below). There is a third possible behavior - processes sharing a UDP port are queued awaiting incoming messages. Each incoming message is handed to one (FIFO? randomly selected?) waiting process. I believe NFS server implementations using multiple processes are based on this behavior. - Ralph At 09:43 AM 8/17/99 -0400, Rich Woundy wrote: >At 06:50 AM 08/17/1999 -0400, you wrote: >>There's still the problem of demuxing incoming DHCP messages. > >I think that if there are multiple applications on the same machine with >sockets bound to the same IP address and port number, then the operating >system will make multiple copies of the inbound packet, and queue one copy >per matching socket. I remember seeing this in some Unix-y operating system >source code. At 07:32 AM 8/17/99 -0700, Eric A. Hall wrote: > >> If both the DHCP client and an application are trying to use DHCP >> simultaneously - e.g., the DHCP client is renewing the host's lease >> on an address while an application is obtaining a web proxy address >> with a DHCPINFORM message - how would the responses from the DHCP >> server be routed to the correct destination? > >Well they shouldn't be able to do it "simultaneously" since UDP ought to >prevent one or the other from binding to the port. From dhcp-v6@bucknell.edu Wed Aug 18 09:52:05 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09560 for ; Wed, 18 Aug 1999 09:52:04 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA16813; Wed, 18 Aug 1999 09:47:52 -0400 (EDT) Date: Wed, 18 Aug 1999 09:47:52 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v6@bucknell.edu Sender: dhcp-v6@bucknell.edu Precedence: bulk From: Ralph Droms To: Multiple recipients of list Subject: Re: Web Proxy Auto-Discovery Protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion list for DHCPv6 internet protocol. Content-Type: text/plain; charset="iso-8859-1" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA09560 Recently on the dhcp-v4 mailing list, we've been having a discussion of the use of DHCPINFORM by applications programs, as proposed by the WPAD (web proxy discovery) proposal, http://www .ietf.org/internet-drafts/draft-ietf-wrec-wpad-01.txt. The idea is that an application (in this case, a web client) would initiate its own exchange of DHCP messages, independent of the OS DHCP client (used for initial configuration), to get a DHCP option that would contain a pointer to web proxy configuration information. The details of the option aren't so important. What's come out of the discussion is a problem in the sharing of the DHCP UDP port by multiple entities. For example, suppose the OS DHCP client renews the lease on an IP address at the same time an application tries to contact the DHCP server for some application-specific information or an additional IP address. How will incoming messages for different processes on the DHCP client be demultiplexed and delivered to the appropriate recipient? Not being familiar with UDPv6 (or even if there is an effort to update the UDPv4 spec to accommodate IPv6), I am unfamiliar with the semantics of shared UDPv6 ports. I've included a copy of a recent message I sent to the dhcp-v4 mailing list, summarizing several different possible semantics for messages delivered to a shared UDP(v4) port. Managing simultaneous independent DHCP message exchanges is probably not an insoluble problem, especially in DHCPv6 as we have time to fix it now before any clients are deployed. But, I think we do need to think about a solution and include it in the DHCPv6 spec... - Ralph ===== (message sent to dhcp-v4 mailing list) Well, it seems the semantics of shared UDP ports are implementation-dependent (or at least not well-defined; see below).  There is a third possible behavior - processes sharing a UDP port are queued awaiting incoming messages.  Each incoming message is handed to one (FIFO? randomly selected?) waiting process.  I believe NFS server implementations using multiple processes are based on this behavior. - Ralph At 09:43 AM 8/17/99 -0400, Rich Woundy wrote: >At 06:50 AM 08/17/1999 -0400, you wrote: >>There's still the problem of demuxing incoming DHCP messages. > >I think that if there are multiple applications on the same machine with >sockets bound to the same IP address and port number, then the operating >system will make multiple copies of the inbound packet, and queue one copy >per matching socket. I remember seeing this in some Unix-y operating system >source code. At 07:32 AM 8/17/99 -0700, Eric A. Hall wrote: > >> If both the DHCP client and an application are trying to use DHCP >> simultaneously - e.g., the DHCP client is renewing the host's lease >> on an address while an application is obtaining a web proxy address >> with a DHCPINFORM message - how would the responses from the DHCP >> server be routed to the correct destination? > >Well they shouldn't be able to do it "simultaneously" since UDP ought to >prevent one or the other from binding to the port. From dhcp-v4@bucknell.edu Wed Aug 18 09:55:43 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09906 for ; Wed, 18 Aug 1999 09:55:42 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA27747; Wed, 18 Aug 1999 09:52:50 -0400 (EDT) Date: Wed, 18 Aug 1999 09:52:50 -0400 (EDT) Message-Id: <199908181329.JAA16799@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: Web Proxy Auto-Discovery Protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Well, it seems the semantics of shared UDP ports are > implementation-dependent (or at least not well-defined; see below). Right, I think the queuing behaviour you've described is correct - when a packet comes in, probably all the select()s on that descriptor wake up, and then one of the read()s finishes, or maybe only one select() wakes up. Obviously, this can't work for DHCP clients, since each packet represents a transaction specific to a particular state machine. I have two theories for how to deal with this problem in the ISC client. One is not to just have it stop listening on the port when it's idle - this will work most of the time, but if the real DHCP client happens to need to renew just when some other app is doing a DHCPINFORM, the client might fail to renew, with potentially disastrous consequences. So much as I've been flamed for not doing the client this way, I think my decision was correct. Sharing the port using the semantics that NFS uses, probably doesn't work. What I think will work, and what I suspect Microsoft may have done, is to simply have the "official" DHCP client see all packets, and also pass those packets to any user process that may be listening on the port. A kernel-resident DHCP client for BSD or Linux could do the same thing. I think for a variety of reasons that a kernel-resident client is the right thing anyway, so I don't see any point in trying to solve this problem strictly in userland. The other solution would be to just define an API for getting the "official" DHCP client to do DHCPINFORMs. Theoretically, this is cleaner, but unless all the DHCP client vendors agree on a standard API for this, it's probably not terribly useful. The ISC will be coming out with an API that could be used in this way, but unless everybody wants to jump on the bandwagon and support the same API (don't agree to this until you've seen it!), I don't think it's a real solution for this issue. _MelloN_ From dhcp-v4@bucknell.edu Wed Aug 18 09:55:57 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09980 for ; Wed, 18 Aug 1999 09:55:54 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA19237; Wed, 18 Aug 1999 09:53:28 -0400 (EDT) Date: Wed, 18 Aug 1999 09:53:28 -0400 (EDT) Message-Id: <37BAB5A3.D87D625A@uab.ericsson.se> Errors-To: droms@bucknell.edu Reply-To: Per.Wadelius@uab.ericsson.se Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Per Wadelius To: Multiple recipients of list X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.51 [en] (Win95; I) Content-Transfer-Encoding: 7bit unsubscribe From dhcp-v4@bucknell.edu Wed Aug 18 11:46:18 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15899 for ; Wed, 18 Aug 1999 11:46:18 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA11010; Wed, 18 Aug 1999 11:42:57 -0400 (EDT) Date: Wed, 18 Aug 1999 11:42:57 -0400 (EDT) Message-Id: <37BACCE6.7BC7119@ehsco.com> Errors-To: droms@bucknell.edu Reply-To: ehall@ehsco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Eric A. Hall" To: Multiple recipients of list Subject: Re: Web Proxy Auto-Discovery Protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.6 [en] (WinNT; I) Content-Transfer-Encoding: 7bit > The other solution would be to just define an API for getting the > "official" DHCP client to do DHCPINFORMs. Theoretically, this is > cleaner, but unless all the DHCP client vendors agree on a standard > API for this, it's probably not terribly useful. The ISC will be > coming out with an API that could be used in this way, but unless > everybody wants to jump on the bandwagon and support the same API > (don't agree to this until you've seen it!), I don't think it's a real > solution for this issue. The latest incarnation of OpenTransport in MacOS (not MacOS X) has an API for their DHCP client now, BTW. I don't know if it allows for INFORM updates or not. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v6@bucknell.edu Wed Aug 18 12:38:23 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17528 for ; Wed, 18 Aug 1999 12:38:22 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA32350; Wed, 18 Aug 1999 12:23:37 -0400 (EDT) Date: Wed, 18 Aug 1999 12:23:37 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v6@bucknell.edu Sender: dhcp-v6@bucknell.edu Precedence: bulk From: Mike Carney - SNT Internet Engineering To: Multiple recipients of list Subject: Re: DHCPv6 issues list X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion list for DHCPv6 internet protocol. Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Mime-Version: 1.0 Thanks for sending this along, Jean-Jacques. We'll take a look. ASCII art is always lots of fun. ;^) Mike Carney SNT Internet Engineering Sun Microsystems, Inc. Mailstop UBUR02-212 One Network Drive Burlington, MA 01803 From dhcp-v6@bucknell.edu Wed Aug 18 13:45:09 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18759 for ; Wed, 18 Aug 1999 13:45:08 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA01557; Wed, 18 Aug 1999 13:41:33 -0400 (EDT) Date: Wed, 18 Aug 1999 13:41:33 -0400 (EDT) Message-Id: <19990818193830.A16539@itea.ntnu.no> Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v6@bucknell.edu Sender: dhcp-v6@bucknell.edu Precedence: bulk From: Stig Venaas To: Multiple recipients of list Subject: Re: Web Proxy Auto-Discovery Protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion list for DHCPv6 internet protocol. X-Mailer: Mutt 0.93.2i Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Wed, Aug 18, 1999 at 09:48:13AM -0400, Ralph Droms wrote: > > The details of the option aren't so important. What's come out of the > discussion is a problem in the sharing of the DHCP UDP port by multiple > entities. For example, suppose the OS DHCP client renews the lease on an IP > address at the same time an application tries to contact the DHCP server for > some application-specific information or an additional IP address. How will > incoming messages for different processes on the DHCP client be demultiplexed > and delivered to the appropriate recipient? Unless using several ports or some hack using several addresses is an option, I think you need a single process to do the demultiplexing. My first thought on how this could be done is as follows: Some process say a web browser sends a DHCP request (leaving some fields blank) to the host's dhcp client on the loopback interface (it's supposed to always listen on port 546 anyway). The DHCP client stores the port number the request came from and the transaction ID somewhere, it then fills in a new transaction ID which can be used as an index to look up this information later on. It fills in the missing fields, and sends an ordinary DHCP request. Then when the DHCP client gets a reply, it uses the transaction ID to look up to which port on the localhost the reply should be forwarded to, and what transaction ID it should have. The process (web browser) gets a reply from the local DHCP client on the loopback interface with the port it sent the request from. There are probably some things I haven't thought of, but I think this could be one way of doing it. Stig Venaas UNINETT/NTNU From dhcp-v6@bucknell.edu Wed Aug 18 15:35:12 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21542 for ; Wed, 18 Aug 1999 15:35:12 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA15587; Wed, 18 Aug 1999 15:31:58 -0400 (EDT) Date: Wed, 18 Aug 1999 15:31:58 -0400 (EDT) Message-Id: <21839C593E75D211BF7800805FCCD026EAAD26@msgsrv03.srv.PacBell.COM> Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v6@bucknell.edu Sender: dhcp-v6@bucknell.edu Precedence: bulk From: "HIBBS, BARR (PB)" To: Multiple recipients of list Subject: RE: Web Proxy Auto-Discovery Protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion list for DHCPv6 internet protocol. Content-Type: text/plain X-Mailer: Internet Mail Service (5.5.2448.0) Mime-Version: 1.0 Stig-- I am a little confused by your note.... [...stuff deleted...] > Some process say a web browser sends a DHCP request (leaving some fields > blank) to the host's dhcp client on the loopback interface (it's supposed > to always listen on port 546 anyway). > [...what is port 546? DHCP clients normally listen only to port 68. I'm not conversant about www clients, so is 546 the port normally used by one? Also, DHCP clients will generally ignore (perhaps rudely!) message types that differ from what they expect: a DHCPREQUEST message is normally not processed by a client, only by a server. I'm not trying to be difficult here, but you seem to be suggesting client behavior that may not be practical, although I do like the simplicity of using the loopback address...] > The DHCP client stores the port number the request came from and the > transaction ID somewhere, it then fills in a new transaction ID which > can be used as an index to look up this information later on. It fills > in the missing fields, and sends an ordinary DHCP request. > > Then when the DHCP client gets a reply, it uses the transaction ID to > look up to which port on the localhost the reply should be forwarded to, > and what transaction ID it should have. > > The process (web browser) gets a reply from the local DHCP client on > the loopback interface with the port it sent the request from. > [...I'll summarize the above three paragraphs as "...a DHCP client could simply multiplex application requests for configuration information as part of its natural function..." -- does that accurately convey what you were suggesting? Your suggested approach is a clean way to handle DHCPINFORM requests from applications without creating a universal DCHP client API, but even this approach would require concurrence among the vendors of DHCP clients that should be formalized through the RFC development process. If the other readers of the mailing list concur, you should consider writing an Internet-Draft to cover this behavior (unless Ralph thinks it better to be part of the core protocol specifications)...] [...stuff deleted...] --Barr From dhcp-v6@bucknell.edu Wed Aug 18 16:29:58 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22479 for ; Wed, 18 Aug 1999 16:29:57 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA26501; Wed, 18 Aug 1999 16:26:04 -0400 (EDT) Date: Wed, 18 Aug 1999 16:26:04 -0400 (EDT) Message-Id: <19990818221906.A19587@itea.ntnu.no> Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v6@bucknell.edu Sender: dhcp-v6@bucknell.edu Precedence: bulk From: Stig Venaas To: Multiple recipients of list Subject: Re: Web Proxy Auto-Discovery Protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion list for DHCPv6 internet protocol. X-Mailer: Mutt 0.93.2i Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA22479 On Wed, Aug 18, 1999 at 03:32:49PM -0400, HIBBS, BARR (PB) wrote: > > Stig-- > > I am a little confused by your note.... Sorry about that, I'll try to clarify > [...stuff deleted...] > > > Some process say a web browser sends a DHCP request (leaving some fields > > blank) to the host's dhcp client on the loopback interface (it's supposed > > to always listen on port 546 anyway). > > > [...what is port 546? DHCP clients normally listen only to port 68. I'm > not conversant about www clients, so is 546 the port normally used by one? I was thinking of DHCPv6 here, but you could do the same with IPv4 on port 68 of course. > Also, DHCP clients will generally ignore (perhaps rudely!) message types > that differ from what they expect: a DHCPREQUEST message is normally not > processed by a client, only by a server. I'm not trying to be difficult > here, but you seem to be suggesting client behavior that may not be > practical, although I do like the simplicity of using the loopback > address...] Yes, the client would of course have to be modified, and it should ignore any DHCPREQUEST messages that does not arrive at the loopback interface. Perhaps one should use some other message type. I haven't really given this much thought. It was mostly as an input to the discussion and I'm glad for getting replies. [...stuff deleted...] > Your suggested approach is a clean way to handle DHCPINFORM requests from > applications without creating a universal DCHP client API, but even this > approach would require concurrence among the vendors of DHCP clients that > should be formalized through the RFC development process. If the other Yes, I agree that whatever solution is chosen needs to be formalized in some way. [...stuff deleted...] I should perhaps mention that I haven't followed the discussion on the DHCPv4 lists or looked at the WPAD implementation. I guess it might be a bad idea to propose something without having followed the discussion. Stig -- Stig Venås Tel: +47 73 59 53 29 NTNU Fax: +47 73 59 80 98 ITEA/Nett, Prof. Brochs g. 6 N-7491 Trondheim, Norway E-mail: venaas@itea.ntnu.no From dhcp-v6@bucknell.edu Wed Aug 18 22:00:48 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03704 for ; Wed, 18 Aug 1999 22:00:48 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id VAA18161; Wed, 18 Aug 1999 21:58:16 -0400 (EDT) Date: Wed, 18 Aug 1999 21:58:16 -0400 (EDT) Message-Id: <199908190135.VAA28180@mail.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v6@bucknell.edu Sender: dhcp-v6@bucknell.edu Precedence: bulk From: Ralph Droms To: Multiple recipients of list Subject: Re: Web Proxy Auto-Discovery Protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion list for DHCPv6 internet protocol. Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 At 01:42 PM 8/18/99 -0400, Stig Venaas wrote: >On Wed, Aug 18, 1999 at 09:48:13AM -0400, Ralph Droms wrote: >> >> The details of the option aren't so important. What's come out of the >> discussion is a problem in the sharing of the DHCP UDP port by multiple >> entities. For example, suppose the OS DHCP client renews the lease on an IP >> address at the same time an application tries to contact the DHCP server for >> some application-specific information or an additional IP address. How will >> incoming messages for different processes on the DHCP client be demultiplexed >> and delivered to the appropriate recipient? > >[...] (it's supposed >to always listen on port 546 anyway). Ah, right, that differentiates the DHCPv6 case from the DHCPv4 case - in DHCPv6, the DHCP client is always listening on the DHCP UDP port, while in DHCPv4 the DHCP client may release the DHCP UDP port... - Ralph From dhcp-v6@bucknell.edu Thu Aug 19 17:45:44 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18468 for ; Thu, 19 Aug 1999 17:45:44 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA04980; Thu, 19 Aug 1999 17:41:43 -0400 (EDT) Date: Thu, 19 Aug 1999 17:41:43 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v6@bucknell.edu Sender: dhcp-v6@bucknell.edu Precedence: bulk From: Erik Nordmark To: Multiple recipients of list Subject: DHCPv6 hopcount=255? X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion list for DHCPv6 internet protocol. Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Mime-Version: 1.0 I don't know if this has been discussed before but when reading the 200 messages on the subject of "IPv6 and Dynamic DNS" I started wondering... Currently anybody can spoof a DHCPv* packet which says "please update the A* records for this name", as far as I can tell. Would it make sense to use hoplimit=255 to verify that DHCP packets can only be sent by nodes on the link? (These types of attacks are becomming popular - e.g. the recent IPv4 ICMP router discovery attacks.) I imagine this would require some work since many DHCPv6 packets can go either through a relay or directly to the server - and the server is likely to be multiple hops away. Can DHCPv4 authentication without any configuration of per-client keys provide this functionality for DHCPv6? Erik From dhcp-v6@bucknell.edu Mon Aug 23 11:46:07 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21385 for ; Mon, 23 Aug 1999 11:46:04 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA05955; Mon, 23 Aug 1999 11:40:49 -0400 (EDT) Date: Mon, 23 Aug 1999 11:40:49 -0400 (EDT) Message-Id: <199908231459.KAA19826@cichlid.raleigh.ibm.com> Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v6@bucknell.edu Sender: dhcp-v6@bucknell.edu Precedence: bulk From: Thomas Narten To: Multiple recipients of list Subject: DHCPv6 address allocation model X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion list for DHCPv6 internet protocol. One of the questions I've had in the back of my mind for a while is how does one use DHCPv6 to renumber a site. This may seem like a silly and obvious question, but I'm actually quite serious. To summarize, I believe there are a lot of ambiguities and unspecified details relating to the new DHCPv6 semantics, where a client is allowed to ask for additional addresses. In the following, I describe a number of concrete scenarios where I am not sure how the protocol is supposed to work and what the spec calls for. Background: Using stateless address autoconfiguration, the system administrator controls the prefixes that routers advertise via RAs. Hosts autoconfigure addresses from the prefixes in RAs. A host generates exactly one address for each prefix. To renumber a site, the sys admin adds a new prefix to the list sent out in RAs (which all the hosts then generate an address for) and also deprecates the (now old) prefix that has been advertised in use for some time, but now needs to be phased out. Because hosts always generate exactly one address for each advertised prefix, there is never any ambiguity as to which addresses are actually in use, or how they are used. DHCPv4 doesn't have the notion of muliple addresses per client. However, it does have the model that the client asks for its resources, and the server returns them. If the client asks again, it gets the same answer again. The v6 counterpart of DHCPv4 that would retain this model (but incorporate v6's multiple address model) would simply have the server return ALL the addresses a client is supposed to have (i.e., addresses from the same set of prefixes the RAs would be advertising). If a client asked for addresses three different times, it would always get the same answer. With DHCPv6 (as currently defined), however, the address assignment model is quite different. Specifically, a server doesn't simply respond saying "here are ALL of your addresses." If a client asks for addresses (and the server returns some), and then later asks for more, the server will return more (i.e., different ones in addition to those it has already handed out). The motivation for this model (from what I understand) is to allow individual applications to have their own addresses. This new model leads to a number of details that I don't think are covered in the current spec. The following gives concrete examples where there are gaps in the current spec, and where I'm not sure how things are actually supposed to work. 1) In a request, the client must specifically ask for an address (via an address extension). When it requests an address, how many does the server return? The text doesn't seem to say, and in fact says: > 3.2.2. Receiving a DHCP Request with the IP Address Extension > > When a server receives a request for an IP address, it consults its > allocation tables and determines an IP address appropriate for the > requesting client and the link to which the client is attached. note "determines an IP address", i.e., just one. 2) Now, the above wording could of course be tweaked to say "one or more ...". Let's assume that the above wording is changed and that a site has 2 prefixes (for two ISPs), and the DHCP server is allowed to return two addresses in response to the request for an address. No problem. But what if the client actually requests two addresses (by including two address extensions in the request)? How many addresses does the server return? Which ones? It could return 2, but that may be incorrect. If the two requests (i.e., two address extensions included in the request) were for two different uses, shouldn't the server return 4? Two addresses from each ISP prefix? If the server returns 4, what will the client do with those four addresses? It asked for 2, but got 4. Does it assume the first two should be associated with the first requested address, while the latter two belong to the second request? Or does it assume the first address goes with the first request, the remaining addresses go with the last request? What if the server returns the 4 addresses in the different order than the client expects them to be grouped (i.e., the first two addresses for ISP 1, the last two for ISP 2)? The point here is that there are quite a lot of unspecified details in how this will work. If the client and server have different assumptions, the wrong thing might happen and we won't have interoperability. 3) DHCPv4 and IPv6's stateless address autoconfiguration have an assumption that the sys admin knows how many addresses a host needs. The model is the client can ask for its addresses, and the server (DHCPv4 server or router sending RAs) always responds giving it all of the addresses its supposed to use. The current DHCPv6 model has the client requesting one or more addresses. But this begs a fundamental question. How does a client know how many addresses it should ask for? A client generally doesn't know how many ISPs it has connections through (and there is no defined mechanism in IPv6 today for a client to find out) so how can it sensibly be expected to know how many to ask for? Indeed, how can it ask indicate *which* type of address it wants? For example, how would it indicate that it wants two addresses and that the two addresses to come from two different ISP prefixes? Another way of stating the issue is that DHCP is intended for configuring clients. That is, the client is assumed to need configuring. But if the client is expected to ask the server for individual addresses, it needs to know what types of addresses to ask for (e.g., global scope or site-local?, which ISP prefixes, etc.) But this type of information is normally managed by the centralized DHCP server. The client doesn't (and shouldn't) need to know these sorts of things in order to use DHCP. DHCP's primary benefit comes when clients are dumb, so to speak. For example, when a new machine plugs into the network the first time, it should be able to use DHCP and just have things work, without requiring advance configuration of the client. 4) Suppose a site has two prefixes for ISPA and ISPB. A client has requested and received addresses for both prefixes (i.e., ADDR-A and ADDR-B). Suppose now that the client sends in a Request to renew address ADDR-A (the address for ISPA), but doesn't include ADDR-B in the request. What does the server return? Just an address for ADDR-A with a new lifetime? Should it also return an address corresponding to ISPB? In case 1) above, the answer was yes. But in this case, returning an additional address from ISPB's prefix gets complicated. Should it return the same ADDR-B it returned earlier (that the client is using, but didn't include in an extension in the Request message). Should the server return ADDR-BPRIME, an address for ISPB but different from ADDR-B? I'm not sure there is a "right" answer here. The right answer depends on how the client intends to use the returned addresses. 5) Suppose a site has one prefix for ISPA, but decides it wants to add a new one for a new ISP connection (ISPB). If a client had asked for one address, this wouldn't be too big of a problem. The server could send a reconfigure, the client would send a Request, and the Reply could contain both the old address and the new one. But suppose further that a client has requested and received 2 separate addresses already (both addresses are on prefix ISPA). The server can send a reconfigure for both addresses, and the client then responds with a Request for those two addresses. But now we have the problem described earlier about how many prefixes get returned, which ones, and what does a client do with them. 6) Suppose a client asks for 4 addresses (two each from ISP prefixes ISPA and ISPB) but gets back only 2 because the prefix from ISPA is no longer valid. What are semantics? In summary, I think there are a number of technical problems with the current definition of address allocation. I believe that they all stem from the extended allocation model that is new to DHCPv6. No doubt, they can all be fixed in the protocol, but I continue to wonder whether the effort is worth while. The WG should consider: 1) what are the benefits of the new model, and do the benefits justify the complexity they add. My understanding is that the main benefit is that it allows individual applications to request addresses for their own use. I.e., so I can have (say) multiple web server processes, each using their own address that is presumably not shared with any other applications. My sense also is that there is no concrete example that calls for this problem to be solved via DHCP. It also appears that the new allocation model has introduced complexity to the protocol (relative to DHCPv4) that stems directly from the new model. Specifically: - 'C' bit is needed so that the a client has a way to tell the server to throw away previous allocations. This is needed because the client can forget (i.e., via system restart) what resources have been assigned to it, and the server has no way of determining whether a client is still using a resource. The 'C' bit opens up a denial of service attack not present in DHCPv4. - the requirement that the server cache responses and respond to retransmissions from its cache for certain time periods. Unlike DHCPv4, DHCPv6 requests are not idempotent. - Additional complexity will likely be needed to address some of the issues outlined above. 2) What additional pieces are also needed in order take advantage of the new facilities. I believe that there is additional stuff that needs to be done. For example, an API would probably be needed that allowed applications to interact with DHCP to request addresses, and also that would allow DHCP to interact with an application. For example, if an application wants to get an address for its own use, it needs to ask the local DHCP entity to obtain one. Likewise, if the DHCP server sends out a RECONFIGURE, and that reconfigure corresponds to a particular address being used by one particular application, there would need to be system hooks (e.g., via the API) that allowed the client DHCP process to inform the application that the address it was using has changed, a new one has been assigned, etc. Because RECONFIGUREs can arrive at any time, the API would probably need some sort of asynchronous notification facility. (I.e, an application would need to poll or DHCP would need do upcalls.) Is there agreement that such an API required in order to take advantage of these facilities? Does anyone have any plans to write one or think that they might in the future? 3) In the case where a client needs to do specialized things (like host multiple servers), another argument is that that DHCP provides only limited benefits. I.e., such environments will require that individual clients be hand-configured anyway, in which case configuring the address-specific stuff might make sense anyway (and wouldn't be a significant burden), and the incremental benefit of using DHCP might be quite small. Thomas From dhcp-v4@bucknell.edu Thu Aug 26 11:35:54 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22568 for ; Thu, 26 Aug 1999 11:35:50 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA19120; Thu, 26 Aug 1999 11:30:53 -0400 (EDT) Date: Thu, 26 Aug 1999 11:30:53 -0400 (EDT) Message-Id: <5104D4DBC598D211B5FE0000F8FE7EB2E6BAE7@mbtlipnt02.btlabs.bt.co.uk> Errors-To: droms@bucknell.edu Reply-To: jerome.privat@bt.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: jerome.privat@bt.com To: Multiple recipients of list Subject: draft-privat-dhc-doublephase-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain X-Mailer: Internet Mail Service (5.5.2448.0) Mime-Version: 1.0 I have submitted a draft that proposes mechanisms to enable host configuration to be split between two different DHCP servers. The draft can be found at: http://www.ietf.org/internet-drafts/draft-privat-dhc-doublephase-00.txt (I have included the abstract at the end of this email). I'd like to get feedback from this mailing list on the two mechanisms proposed. Thanks in advance, Jerome Privat BT **************************************************************************** ** Abstract: This proposal allows host configuration to be split between two different DHCP servers, potentially under different administration. This may be useful to satisfy specific regulatory, operational or business model requirements. This draft proposes two different approaches. In one approach, a DHCP server redirects clients to a second DHCP server. In the other, a DHCP server acts as a proxy to a second server. From dhcp-v4@bucknell.edu Fri Aug 27 07:15:46 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22486 for ; Fri, 27 Aug 1999 07:15:46 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id HAA12905; Fri, 27 Aug 1999 07:13:00 -0400 (EDT) Date: Fri, 27 Aug 1999 07:13:00 -0400 (EDT) Message-Id: <199908271040.GAA16339@csrlink.net> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: I-D ACTION:draft-ietf-dhc-agent-options-07.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Relay Agent Information Option Author(s) : M. Patrick Filename : draft-ietf-dhc-agent-options-07.txt Pages : 14 Date : 24-Aug-99 Newer high-speed public Internet access technologies call for a high-speed modem to have a LAN attachment to one or more customer premise hosts. It is advantageous to use the Dynamic Host Configuration Protocol as defined in RFC 2131 [1] to assign customer premise host IP addresses in this environment. However, a number of security and scaling problems arise with such 'public' DHCP use. This document describes a new DHCP option to address these issues. This option extends the set of DHCP options as defined in RFC 2132 [2]. The new option is called the Relay Agent Information option and is inserted by the DHCP relay agent when forwarding client-originated DHCP packets to a DHCP server. Servers recognizing the Relay Agent Information option may use the information to implement IP address or other parameter assignment policies. The DHCP Server echoes the option back verbatim to the relay agent in server-to-client replies, and the relay agent strips the option before forwarding the reply to the client. The 'Relay Agent Information' option is organized as a single DHCP option that contains one or more 'sub-options' that convey information known by the relay agent. The initial sub-options are defined for a relay agent that is co-located in a public circuit access unit. These include a 'circuit ID' for the incoming circuit, a 'remote ID' which provides a trusted identifier for the remote high-speed modem, and the 'subnet mask' of the logical IP subnet from which the relay agent received the client DHCP packet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-options-07.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-agent-options-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-agent-options-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19990824131857.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-agent-options-07.txt From dhcp-v4@bucknell.edu Fri Aug 27 11:27:49 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05483 for ; Fri, 27 Aug 1999 11:27:45 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA12142; Fri, 27 Aug 1999 11:21:25 -0400 (EDT) Date: Fri, 27 Aug 1999 11:21:25 -0400 (EDT) Message-Id: <199908271509.LAA00938@prospero.dma.isg.mot.com> Errors-To: droms@bucknell.edu Reply-To: mpatrick@dma.isg.mot.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Michael W. Patrick" To: Multiple recipients of list Subject: agent options patent progress X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Ralph, Just to let you know, I've just obtained approval from the key decision-making Motorola VP for a "royaltee free" status if we ever get a patent on agent options. I'm awaiting vacations and a monthly-scheduled Motorola corporate committee to do the final approval before we can send a formal letter to the IETF to this regard. -mike From dhcp-v4@bucknell.edu Fri Aug 27 16:59:59 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15301 for ; Fri, 27 Aug 1999 16:59:58 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA07597; Fri, 27 Aug 1999 16:56:53 -0400 (EDT) Date: Fri, 27 Aug 1999 16:56:53 -0400 (EDT) Message-Id: <199908271850.OAA21474@mail.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: droms@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ralph Droms To: Multiple recipients of list Subject: Re: agent options patent progress X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Mike - thanks for the update and follow through on the status of the patent application. I appreciate your efforts to ensure that this technology will continue to be available to the DHCP community. - Ralph At 11:09 AM 8/27/99 -0400, Michael W. Patrick wrote: >Ralph, > >Just to let you know, I've just obtained approval from the key >decision-making Motorola VP for a "royaltee free" status if we ever >get a patent on agent options. I'm awaiting vacations and a >monthly-scheduled Motorola corporate committee to do the final >approval before we can send a formal letter to the IETF to this >regard. > >-mike > From dhcp-v4@bucknell.edu Mon Aug 30 08:32:30 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23604 for ; Mon, 30 Aug 1999 08:32:26 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA32109; Mon, 30 Aug 1999 08:29:59 -0400 (EDT) Date: Mon, 30 Aug 1999 08:29:59 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: I-D ACTION:draft-ietf-dhc-agent-options-07.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Relay Agent Information Option Author(s) : M. Patrick Filename : draft-ietf-dhc-agent-options-07.txt Pages : 14 Date : 27-Aug-99 Newer high-speed public Internet access technologies call for a high-speed modem to have a LAN attachment to one or more customer premise hosts. It is advantageous to use the Dynamic Host Configuration Protocol as defined in RFC 2131 [1] to assign customer premise host IP addresses in this environment. However, a number of security and scaling problems arise with such 'public' DHCP use. This document describes a new DHCP option to address these issues. This option extends the set of DHCP options as defined in RFC 2132 [2]. The new option is called the Relay Agent Information option and is inserted by the DHCP relay agent when forwarding client-originated DHCP packets to a DHCP server. Servers recognizing the Relay Agent Information option may use the information to implement IP address or other parameter assignment policies. The DHCP Server echoes the option back verbatim to the relay agent in server-to-client replies, and the relay agent strips the option before forwarding the reply to the client. The 'Relay Agent Information' option is organized as a single DHCP option that contains one or more 'sub-options' that convey information known by the relay agent. The initial sub-options are defined for a relay agent that is co-located in a public circuit access unit. These include a 'circuit ID' for the incoming circuit, a 'remote ID' which provides a trusted identifier for the remote high-speed modem, and the 'subnet mask' of the logical IP subnet from which the relay agent received the client DHCP packet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-options-07.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-agent-options-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-agent-options-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19990827111250.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-agent-options-07.txt