From dhcp-v4@bucknell.edu Tue Jun 1 06:44:32 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 GAA25882 for ; Tue, 1 Jun 1999 06:44:31 -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 GAA04737; Tue, 1 Jun 1999 06:40:04 -0400 (EDT) Date: Tue, 1 Jun 1999 06:40:04 -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: WG meetings in 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 As is our custom, the WG will meet twice in Oslo; once for DHCPv4 issues and once for DHCPv6 issues: Monday, July 12 at 0900-1130 other groups scheduled at that time: cat, rsvp, mpls Monday, July 12 at 1930-2200 other groups scheduled at that time: rap, mpls Please contact me with agenda items as soon as possible so that I can organize the agendas for the two meetings. - Ralph Droms From dhcp-v4@bucknell.edu Tue Jun 1 06:49:11 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 GAA25902 for ; Tue, 1 Jun 1999 06:49: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 GAA28061; Tue, 1 Jun 1999 06:45:17 -0400 (EDT) Date: Tue, 1 Jun 1999 06:45:17 -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: Revised WG charter 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 included a revised WG charter below. Please respind to the mailing list with comments and suggestions. I'm working with ID authors to develop milestones and goals for individual documents. - Ralph ===== Description of Working Group: This working group has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCP is currently a "Draft Standard". The working group now has four main objectives: * Revise and submit the DHCP specification for acceptance as a Full Standard * Develop additional functions for DHCP * Develop an accurate list of assigned option codes and identify option codes that can be safely reassigned * Develop a specification for DHCP for IPv6 Specific additional functions to be developed by the working group include: o Interaction between DHCP and DNS dynamic update protocol (ddns) o Inter-server communication for coordination of multiple servers o Mechanisms for the authentication of clients and servers o Definition of a DHCP MIB for management of DHCP servers through SNMP O Definition of an LDAP schema to provide a standardized format for the storage and retrieval of DHCP information, primarily configuration and lease data; this schema will be developed in coordination with the Policy Frameworks Working Group as appropriate. o Options through which DHCP relay agents can pass information to DHCP servers o Other options: user class, server selection, domain search o Roadmap for development of new options, option syntax and option acceptance procedures From dhcp-v4@bucknell.edu Tue Jun 1 21:51: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 VAA09412 for ; Tue, 1 Jun 1999 21:51: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 VAA07978; Tue, 1 Jun 1999 21:46:48 -0400 (EDT) Date: Tue, 1 Jun 1999 21:46:48 -0400 (EDT) Message-Id: <000101beac98$afe0bbe0$268939cc@internaut.com> Errors-To: droms@bucknell.edu Reply-To: aboba@internaut.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Bernard Aboba" To: Multiple recipients of list Subject: Questions on authentication draft X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Some questions on the authentication draft: 1. The draft describes protocols 0 and 1. Is it correct to assume that these MUST be implemented? 2. I am curious as to how a client and server agree to use a new protocol. One possibility is for the DHCP client to indicate the desired protocol in the DHCPDISCOVER. Then only servers which offer that protocol will respond with DHCPOFFERs. If no servers implement that protocol, then no servers will respond. Since the client may not know what administrative domain it is in when it issues the DHCPOFFER, it is possible for it to guess wrong. If no servers respond then it will never find out what domain it is in. Therefore this approach may not be best. Another possibility is for the client to only indicate a mandatory protocol in the DHCPDISCOVER. The server can then use a mandatory protocol in the DHCPOFFER, while also including an option indicating what authentication protocols it will allow the client to do, and its administrative domain. The offered protocols could be based on the client's identity as determined from the chaddr or 'client identifier' option. The client would then choose one of the offered protocols, and formulate an authentication option appropriate for the administrative domain indicated by the server. Note that in this case, the client could use a different protocol in the DHCPREQUEST than in the DHCPDISCOVER, or used by the server in the DHCPOFFER. One question that arises is whether the server should use the same protocol that the client used in the DHCPREQUEST in authenticating its DHCPACK, or whether it will always use a mandatory protocol. 3. In the case of DHCPINFORM, the client has already obtained an IP address, and therefore has typically figured out what administrative domain it is in. Thus, it should know what protocol is appropriate, and can indicate this in the authentication option included in the DHCPINFORM. Is the server required to use the same protocol as in the DHCPINFORM in authenticating its DHCPACK or can it use another protocol? If the server cannot support the chosen client protocol, but finds the DHCPINFORM otherwise acceptable, and does support authentication, then it can send a DHCPACK authenticated with one of the mandatory protocols. If the server cannot support authentication at all, then it will send an unauthenticated DHCPACK. This case indicates misconfiguration since the client should know what administrative domain it is in. If the client is set to accept unauthenticated server messages it will process this message. However, if it is set to not accept unauthenticated messages, then it will silently discard the DHCPACK. Does this make sense? 4. I am curious as to the architecture that is used by DHCP servers in order to support extensibility. For example, does the DHCP server need to be modified in order to support a new protocol, or can it act as a passthrough? 5. Is the possibility of a DHCP proxy handled? This was introduced in the subnet selection draft as well as in draft-ietf-dhc-agent-options-05.txt. For example, the latter draft introduced the possibility of a relay agent inserting options. Possibilities include: a. We decide now that the idea of a DHCP proxy doesn't make sense, and therefore explicitly decide not to support this in the authentication draft (or in any future document). b. The possibility of a DHCP proxy is taken into account in the authentication draft, so that it will not have to be reworked in the future. For example, the authentication hash could be applied up to and including the authentication option. The relay agent could then insert (but never remove) options after this, but they would not be covered by the authentication hash. From dhcp-v4@bucknell.edu Thu Jun 3 15:26: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 PAA11831 for ; Thu, 3 Jun 1999 15:26:41 -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 PAA15963; Thu, 3 Jun 1999 15:15:20 -0400 (EDT) Date: Thu, 3 Jun 1999 15:15:20 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: waa@dsl.cis.upenn.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "William A. Arbaugh" To: Multiple recipients of list Subject: Re: Questions on authentication draft 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 On Tue, 1 Jun 1999, Bernard Aboba wrote: > Some questions on the authentication draft: > > 1. The draft describes protocols 0 and 1. > Is it correct to assume that these > MUST be implemented? > I feel that Protocol 1 MUST be implemented. Honestly, I don't see much use for Protocol 0 given that a secret has already been exchanged- you might as well use the stronger protocol. The only advantage that I see Protocol 0 having is implementation size. What's the feeling of the list? > 2. I am curious as to how a client and > server agree to use a new protocol. One > possibility is for the DHCP client to indicate > the desired protocol in the DHCPDISCOVER. Then > only servers which offer that protocol will respond > with DHCPOFFERs. If no servers implement that > protocol, then no servers will respond. > > Since the client may not know what administrative > domain it is in when it issues the DHCPOFFER, it > is possible for it to guess wrong. If no servers > respond then it will never find out what domain > it is in. Therefore this approach may not be best. > > Another possibility is for the client to only > indicate a mandatory protocol in the DHCPDISCOVER. > The server can then use a mandatory protocol in > the DHCPOFFER, while also including an option indicating > what authentication protocols it will allow the > client to do, and its administrative domain. > > The offered protocols could be based on the client's identity > as determined from the chaddr or 'client identifier' > option. The client would then choose one of the > offered protocols, and formulate an authentication option > appropriate for the administrative domain > indicated by the server. Note that in this > case, the client could use a different protocol > in the DHCPREQUEST than in the DHCPDISCOVER, > or used by the server in the DHCPOFFER. > > One question that arises is whether the server > should use the same protocol that the client > used in the DHCPREQUEST in authenticating > its DHCPACK, or whether it will always use > a mandatory protocol. > I'm open to having the server respond with another authentication protocol if it already has a security association established with it in that protocol. If the server is designed to always use the "best available" authentication mechanism, then this is a nice capability. A problem, however, is that if the client and server are out of sync with their security associations then you have a potential livelock situation. > 3. In the case of DHCPINFORM, the client has > already obtained an IP address, and therefore > has typically figured out what administrative > domain it is in. Thus, it should know what > protocol is appropriate, and can indicate this in the > authentication option included in the DHCPINFORM. > Is the server required to use the same protocol > as in the DHCPINFORM in authenticating its DHCPACK or can > it use another protocol? > > If the server cannot support the chosen client protocol, > but finds the DHCPINFORM otherwise acceptable, and > does support authentication, then it can send a DHCPACK > authenticated with one of the mandatory protocols. If > the server cannot support authentication at all, then > it will send an unauthenticated DHCPACK. This case indicates > misconfiguration since the client should know what administrative > domain it is in. If the client is set to accept > unauthenticated server messages it will process this > message. However, if it is set to not accept > unauthenticated messages, then it will silently > discard the DHCPACK. Does this make sense? > I think the best approach with INFORM is to have the server respond with the same authentication mechanism. If the server doesn't support that mechanism, then it should respond with a DHCPNAK and force the client back to INIT. The DHCPNAK should be authenticated if any security associations exist between the client and server. > 4. I am curious as to the architecture that is used > by DHCP servers in order to support extensibility. For > example, does the DHCP server need to be modified in order > to support a new protocol, or can it act as a passthrough? > Not a bad idea ... sort of like apache modules. > 5. Is the possibility of a DHCP proxy handled? > This was introduced in the subnet selection draft as > well as in draft-ietf-dhc-agent-options-05.txt. For > example, the latter draft introduced the possibility > of a relay agent inserting options. Possibilities > include: > > a. We decide now that the idea of a DHCP proxy doesn't > make sense, and therefore explicitly decide not > to support this in the authentication draft (or > in any future document). > > b. The possibility of a DHCP proxy is taken into > account in the authentication draft, so that it > will not have to be reworked in the future. > > For example, the authentication hash could > be applied up to and including the authentication > option. The relay agent could then insert > (but never remove) options after this, but > they would not be covered by the authentication > hash. > I'm working on addressing the relay agent interactions right now. I'll post my proposed text on it next week. Bill From dhcp-v4@bucknell.edu Thu Jun 3 16:27: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 QAA12558 for ; Thu, 3 Jun 1999 16:27: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 QAA04671; Thu, 3 Jun 1999 16:18:45 -0400 (EDT) Date: Thu, 3 Jun 1999 16:18:45 -0400 (EDT) Message-Id: <199906031925.PAA16287@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: Use of bootfile field by BOOTP/DHCP clients 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. ------------------------------------------------------------------------------ Hi folks, I'm trying to get a feel for the common practice among BOOTP/DHCP client implementations with regards to the bootfile field. RFC 951, section 7.3: "We now check the boot file name field (file). The field will be null if the client is not interested in filenames, or wants the default bootfile. If the field is non-null, it is used as a lookup key in a database, along with the client's IP address. If there is a default file or generic file (possibly indexed by the client address) or a fully-specified path name that matches, then replace the 'file' field with the fully-specified path name of the selected boot file. If the field is non-null and no match was found, then the client is asking for a file we dont have; discard the packet, perhaps some other BOOTP server will have it." I've seen implementations provide the name of a file they expect. Is this the general usage, or are there clients that provide strings whose purpose is strictly a hint/key to be used in combination with the client's assigned IP address or hardware address to do a configuration table lookup which would result in the actual absolute path which would then be returned to the client in the bootfile field by the server? TIA, Mike Carney SNT Internet Engineering Sun Microsystems, Inc. Mailstop UBUR02-212 One Network Drive Burlington, MA 01803 From dhcp-v4@bucknell.edu Thu Jun 3 18:00: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 SAA13805 for ; Thu, 3 Jun 1999 18:00: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 RAA28448; Thu, 3 Jun 1999 17:52:30 -0400 (EDT) Date: Thu, 3 Jun 1999 17:52:30 -0400 (EDT) Message-Id: <3756F03C.BEEBA25B@cup.hp.com> Errors-To: droms@bucknell.edu Reply-To: scain@cup.hp.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Stuart Cain 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.6 [en] (WinNT; I) Content-Transfer-Encoding: 7bit unsubscribe From dhcp-v4@bucknell.edu Thu Jun 3 18:50: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 SAA14272 for ; Thu, 3 Jun 1999 18:50: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 SAA00078; Thu, 3 Jun 1999 18:42:02 -0400 (EDT) Date: Thu, 3 Jun 1999 18:42:02 -0400 (EDT) Message-Id: <85256785.007333C8.00@3cmc04smtp.chase.com> Errors-To: droms@bucknell.edu Reply-To: Jan.Jirousek@chase.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Jan.Jirousek@chase.com To: Multiple recipients of list Subject: Jan Jirousek/CHASE is out of the office. 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 I will be out of the office from 06/03/99 until 06/21/99. For urgent matters regarding DNS Infrastructure project please contact the following people meantime: Roberto Ramirez (212)493-3001 - DNS updates Madhu Chaganti (212)43-4954 or Paul Trotter (212)493-4955 - engineering issues Honza From dhcp-v4@bucknell.edu Thu Jun 3 20:06:11 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 UAA14671 for ; Thu, 3 Jun 1999 20:06:11 -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 TAA28171; Thu, 3 Jun 1999 19:56:56 -0400 (EDT) Date: Thu, 3 Jun 1999 19:56:56 -0400 (EDT) Message-Id: <000001beae1a$a2f37700$268939cc@internaut.com> Errors-To: droms@bucknell.edu Reply-To: aboba@internaut.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Bernard Aboba" To: Multiple recipients of list Subject: RE: Questions on authentication draft X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit >I feel that Protocol 1 MUST be implemented. Honestly, I don't see much use >for Protocol 0 given that a secret has already been exchanged- you might >as well use the stronger protocol. The only advantage that I see Protocol >0 having is implementation size. What's the feeling of the list? Well, given that protocol 0 is essentially passing a clear text secret, I'd vote for eliminating it entirely, rather than making it optional. >A problem, however, is that if the client and server are out of >sync with their security associations then you have a potential livelock situation. Yup. That's why I think it's important to allow the server to indicate which protocols it supports in a DHCPNAK. That way, a client that guesses wrong can try again with better knowledge. >I think the best approach with INFORM is to have the server respond with >the same authentication mechanism. If the server doesn't support that >mechanism, then it should respond with a DHCPNAK and force the client back >to INIT. The DHCPNAK should be authenticated if any security associations >exist between the client and server. I assume that the DHCPNAK would include an option describing what protocols the server supports, so as to give the client a decent shot at success the second time around? And would the DHCPNAK be authenticated via protocol 1 in this case? >I'm working on addressing the relay agent interactions right now. I'll >post my proposed text on it next week. You might want to take a look at how Mobile IP handled similar issues with the mobile agent, foreign agent and home agent in the registration authentication options. Basically, there is are mobile-foreign, foreign-home and mobile-home authentication options, which are to be added in a strict order and allow addition of options with appropriate authentication hash coverage for each. From dhcp-v4@bucknell.edu Fri Jun 4 12:02: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 MAA07733 for ; Fri, 4 Jun 1999 12:02: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 LAA08132; Fri, 4 Jun 1999 11:53:40 -0400 (EDT) Date: Fri, 4 Jun 1999 11:53:40 -0400 (EDT) Message-Id: <19990604174803.C29298@stud.uni-hannover.de> Errors-To: droms@bucknell.edu Reply-To: Jan.Krueger@stud.uni-hannover.de Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Jan Krueger To: Multiple recipients of list Subject: static leases based on client_identifier? X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Mutt 0.95.1i Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Hi, is it possible to define static leases based on the client_identifier? I already tried out to define static leases based on the hardware address like hardware token-ring 00:50:04:38:69:e5; fixed-address 10.147.248.72; Can I use a statement like clientID ; fixed-address 10.147.248.72; ?? I also don't understand in the doku of version 2, whether the hostname parameter in the host {} statement can be used for that purpose or if it is checked againt the hostname or client_hostname parameter, the client transmits in the DISCOVER and REQUEST. Thanks in advance. Best regards. Jan Krueger -- Jan.Krueger@stud.uni-hannover.de | CeBit98: thinking on demand business http://www.stud.uni-hannover.de/~jk/ | solutions improvement for a small planet From dhcp-v4@bucknell.edu Fri Jun 4 12:59:32 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 MAA08555 for ; Fri, 4 Jun 1999 12:59: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 MAA15649; Fri, 4 Jun 1999 12:53:37 -0400 (EDT) Date: Fri, 4 Jun 1999 12:53:37 -0400 (EDT) Message-Id: <199906041604.MAA10754@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: static leases based on client_identifier? X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Can I use a statement like > > clientID ; > fixed-address 10.147.248.72; option dhcp-client-identifier ; > I also don't understand in the doku of version 2, whether the hostname parameter > in the host {} statement can be used for that purpose or if it is > checked againt the hostname or client_hostname parameter, the client > transmits in the DISCOVER and REQUEST. Nope, it's just a label that's used internally. You can, if you want, have the server send it back to the client in the host-name option by enabling use-host-decl-names. _MelloN_ From dhcp-v4@bucknell.edu Mon Jun 7 18:44: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 SAA02360 for ; Mon, 7 Jun 1999 18:44: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 SAA03853; Mon, 7 Jun 1999 18:40:11 -0400 (EDT) Date: Mon, 7 Jun 1999 18:40:11 -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: WG meetings in Oslo (2nd posting) 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 As is our custom, the WG will meet twice in Oslo; once for DHCPv4 issues and once for DHCPv6 issues: Monday, July 12 at 0900-1130 (DHCPv4) other groups scheduled at that time: cat, rsvp, mpls Current agenda: Ralph Droms (Bucknell) DHCPv4 authentication (for Bill Arbaugh; draft to be published) Vipul Gupta (Sun) DHCPv4 authentication (draft to be published) Monday, July 12 at 1930-2200 (DHCPv6) other groups scheduled at that time: rap, mpls (Note that the assignment of topics to meetings and current agenda is new since the previous posting.) Please contact me with agenda items as soon as possible so that I can organize the agendas for the two meetings. - Ralph Droms From dhcp-v4@bucknell.edu Fri Jun 11 08:46:11 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 IAA28622 for ; Fri, 11 Jun 1999 08:46:10 -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 IAA25984; Fri, 11 Jun 1999 08:30:24 -0400 (EDT) Date: Fri, 11 Jun 1999 08:30:24 -0400 (EDT) Message-Id: <19990611142326.A24498@stud.uni-hannover.de> Errors-To: droms@bucknell.edu Reply-To: Jan.Krueger@stud.uni-hannover.de Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Jan Krueger To: Multiple recipients of list Subject: network of local interface not served? X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Mutt 0.95.1i Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Hi, we have another minor problem here. If there is no solution it may be considered as a feature request: Our dhcp-server has no clients in the subnet the local interface is in. Every request comes through the gateway. But we are forced by error-messages and exits() to configure an empty subnet definition for this subnet. For that reason we have all the dhcp-traffic on this subnet in the log-file. Has someone a solution the prevents our logfile from growing? Thanks in advance. Best regards. Jan -- Jan.Krueger@stud.uni-hannover.de | CeBit98: thinking on demand business http://www.stud.uni-hannover.de/~jk/ | solutions improvement for a small planet From dhcp-v4@bucknell.edu Fri Jun 11 17:11: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 RAA07477 for ; Fri, 11 Jun 1999 17:11: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 QAA18536; Fri, 11 Jun 1999 16:59:50 -0400 (EDT) Date: Fri, 11 Jun 1999 16:59:50 -0400 (EDT) Message-Id: <199906112058.NAA00770@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: network of local interface not served? X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > But we are forced by error-messages and exits() to configure an empty subnet > definition for this subnet. For that reason we have all the dhcp-traffic > on this subnet in the log-file. You'd have it in your log file anyway - the message would just be different. > Has someone a solution the prevents our logfile from growing? If you don't want to see log messages for every packet you receive (and I assume from your complaint above that you're using the ISC DHCP server :') you should set your syslog configuration to ignore messages at the LOG_INFO level. If you want to collect DHCP log messages in a different file, you can recompile the DHCP server with the log facility redefined to something other than LOG_DAEMON (see includes/site.h) for details. There's actually a section describing how to do this in Ralph's and my new book, which will be available in the not-too-distant future. If you want to disable logging on some networks but not others, this isn't currently supported, but probably will be either in 3.0 or 3.1. Of course, then you'll *definitely* want subnet declarations for unserved networks! :') _MelloN_ From dhcp-v4@bucknell.edu Mon Jun 14 15:00: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 PAA20360 for ; Mon, 14 Jun 1999 15:00: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 OAA28414; Mon, 14 Jun 1999 14:50:57 -0400 (EDT) Date: Mon, 14 Jun 1999 14:50:57 -0400 (EDT) Message-Id: <199906141810.OAA25430@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: Revised WG charter (2nd posting) 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 Included below is a revised charter for the DHC WG. Thomas and Erik: please forward this charter to the IESG for their review. - Ralph ===== Description of Working Group: This working group has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCP is currently a "Draft Standard". The working group now has four main objectives: * Revise and submit the DHCP specification for acceptance as a Full Standard * Develop a roadmap for the review and acceptance of new options, define a new option syntax, develop an accurate list of assigned option codes and identify option codes that can be safely reassigned * Develop a specification for DHCP for IPv6 * Develop an inter-server communication for coordination of multiple servers * Review new options for DHCP, as deemed appropriate by the working group chair and/or the Internet area directors; specific options currently under review in the working group include: o Mechanisms for the authentication of clients and servers o Interaction between DHCP and DNS dynamic update protocol o Definition of a DHCP MIB for management of DHCP servers through SNMP O Definition of an LDAP schema to provide a standardized format for the storage and retrieval of DHCP information, primarily configuration and lease data; this schema will be developed in coordination with the Policy Frameworks Working Group as appropriate. o Options through which DHCP relay agents can pass information to DHCP servers o Other options: user class, server selection, domain search Goals and Milestones: Jun 1999 Submit Internet-Draft on subnet selection option in time for Oslo IETF. Jun 1999 Submit Internet-Draft on LDAP schema for DHCP in time for Oslo IETF. Jun 1999 Submit Internet-Draft on DHCP authentication in time for Oslo IETF. Jun 1999 Submit Internet-Draft on failover protocol in time for Oslo IETF. Jun 1999 Submit Internet-Draft on relay agent options in time for Oslo IETF. Jun 1999 Submit Internet-Draft on DHCP-DNS interaction in time for Oslo IETF. Jul 1999 Submit Internet-Draft on DHCP authentication for WG last call. Jul 1999 Develop plan for review of DHCP specification and acceptance as Internet Standard. Sep 1999 Submit DHCP server MIB specification for WG last call. Sep 1999 Submit subnet selection option specification for WG last call. Nov 1999 Submit DHCP server MIB specification for IESG consideration as a Proposed Standard. Nov 1999 Submit LDAP schema specification for WG last call. Mar 2000 Submit LDAP schema specification for IESG consideration as a Proposed Standard. From dhcp-v4@bucknell.edu Tue Jun 15 08:29: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 IAA16184 for ; Tue, 15 Jun 1999 08:29: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 IAA15171; Tue, 15 Jun 1999 08:20:47 -0400 (EDT) Date: Tue, 15 Jun 1999 08:20:47 -0400 (EDT) Message-Id: <199906151158.HAA19779@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: I-D ACTION:draft-ietf-dhc-subnet-option-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 Dynamic Host Configuration Working Group of the IETF. Title : The Subnet Selection Option for DHCP Author(s) : G. Waters Filename : draft-ietf-dhc-subnet-option-02.txt Pages : 5 Date : 14-Jun-99 This memo defines a new DHCP option for selecting the subnet on which to allocate an address. This option would override a DHCP server's normal methods of selecting which subnet on which to allocate an address for a client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-subnet-option-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-subnet-option-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-subnet-option-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: <19990614112220.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-subnet-option-02.txt From dhcp-v4@bucknell.edu Tue Jun 15 13:47: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 NAA24603 for ; Tue, 15 Jun 1999 13: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 NAA26702; Tue, 15 Jun 1999 13:40:11 -0400 (EDT) Date: Tue, 15 Jun 1999 13:40:11 -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: draft on the "Subnet Selection Option for DHCP" 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 [i copied the v4 list on this response since i have heard this question before and i would like to get other comments on the usefulness of this text.] an example of who would use this option is a RAS device that is allocating addresses for its clients. in this case the RAS device would be allocating addresses through DHCP and then handing those addresses out to its RAS clients. in this scenario the RAS device would be connected to a private "internal" network on which the DHCP server would be located. the RAS device would also be connected to one or more service providing "external" networks (i.e.: the networks that the RAS clients are on). the internal network is not IP connected to the external networks. however, inside the device there is connectivity between the internal and external networks (e.g.: though the backplane). recall that this device is trying to allocate addresses for clients on the client networks, but since there is no IP connectivity between the internal network and the external networks the DHCP requests cannot originate from the client networks because the responses from the DHCP server cannot be routed back to the device. therefore the DHCP requests must originate from the internal network. the problem with originating the DHCP requests from the internal network is that the DHCP server will allocate addresses on one of the internal network's subnets, when what is required is an address on one of the client subnets. this is where the subnet selection option comes in. the device would send its DHCP requests on the internal subnet, but would include a subnet selection option containing the address of the client subnet on which it requires an address. the subnet selection option indicates to the DHCP server to allocate the address on the requested subnet as opposed to the normal operation of allocating the address on the subnet from which the DHCP request originated. does this help? if so i could include this text in an example section of the draft. /gww > -----Original Message----- > From: Mike Dooley [mailto:mdooley@quadritek.com] > Sent: Tuesday, June 15, 1999 11:40 > To: Glenn Waters > Subject: draft on the "Subnet Selection Option for DHCP" > > > Glenn, > I just finished reading your draft on the "Subnet Selection Option for > DHCP". Looks straight forward, only question I have is what > types of DHCP > clients do you forsee using this option. I read the overview a couple of > times, but I just don't get it .... are these clients devices such as > routers and switches, or actual workstations and PCs? Can you give an > example? > > Thanks, > Mike > > > ========================================== > Michael Dooley > Vice President of Product Development > Lucent Technologies, IP Services Product Group > mdooley@lucent.com > ========================================== > > > From dhcp-v4@bucknell.edu Tue Jun 15 14:26: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 OAA25768 for ; Tue, 15 Jun 1999 14:26:25 -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 OAA17334; Tue, 15 Jun 1999 14:20:58 -0400 (EDT) Date: Tue, 15 Jun 1999 14:20:58 -0400 (EDT) Message-Id: <3766980D.179ECA26@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: draft on the "Subnet Selection Option for DHCP" 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 > an example of who would use this option is a RAS device that is allocating > addresses for its clients. in this case the RAS device would be allocating > addresses through DHCP and then handing those addresses out to its RAS > clients. This seems like a good example to me. It would also be useful with multicast DHCP clients, since they would not require a forwarder (and would therefore not have a GIADDR field) but would still have to be able to identify the network they are on. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Tue Jun 15 14:27: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 OAA25795 for ; Tue, 15 Jun 1999 14:27: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 OAA20289; Tue, 15 Jun 1999 14:20:22 -0400 (EDT) Date: Tue, 15 Jun 1999 14:20:22 -0400 (EDT) Message-Id: <21839C593E75D211BF7800805FCCD0264B0867@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: draft on the "Subnet Selection Option for DHCP" 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 Glenn-- this explanation is great! it filled in the blanks in my understanding, which were the source of the questions during the review period. This should probably be included in the draft.... --Barr > ---------- > From: Glenn Waters[SMTP:gww@nortelnetworks.com] > Sent: Tuesday, June 15, 1999 10:40 AM > To: Multiple recipients of list > Subject: RE: draft on the "Subnet Selection Option for DHCP" > > [i copied the v4 list on this response since i have heard this question > before and i would like to get other comments on the usefulness of this > text.] > > an example of who would use this option is a RAS device that is allocating > addresses for its clients. in this case the RAS device would be > allocating > addresses through DHCP and then handing those addresses out to its RAS > clients. > > in this scenario the RAS device would be connected to a private "internal" > network on which the DHCP server would be located. the RAS device would > also > be connected to one or more service providing "external" networks (i.e.: > the > networks that the RAS clients are on). the internal network is not IP > connected to the external networks. however, inside the device there is > connectivity between the internal and external networks (e.g.: though the > backplane). > > recall that this device is trying to allocate addresses for clients on the > client networks, but since there is no IP connectivity between the > internal > network and the external networks the DHCP requests cannot originate from > the client networks because the responses from the DHCP server cannot be > routed back to the device. therefore the DHCP requests must originate from > the internal network. the problem with originating the DHCP requests from > the internal network is that the DHCP server will allocate addresses on > one > of the internal network's subnets, when what is required is an address on > one of the client subnets. > > this is where the subnet selection option comes in. the device would send > its DHCP requests on the internal subnet, but would include a subnet > selection option containing the address of the client subnet on which it > requires an address. the subnet selection option indicates to the DHCP > server to allocate the address on the requested subnet as opposed to the > normal operation of allocating the address on the subnet from which the > DHCP > request originated. > > does this help? if so i could include this text in an example section of > the draft. > > /gww > > > -----Original Message----- > > From: Mike Dooley [mailto:mdooley@quadritek.com] > > Sent: Tuesday, June 15, 1999 11:40 > > To: Glenn Waters > > Subject: draft on the "Subnet Selection Option for DHCP" > > > > > > Glenn, > > I just finished reading your draft on the "Subnet Selection Option for > > DHCP". Looks straight forward, only question I have is what > > types of DHCP > > clients do you forsee using this option. I read the overview a couple > of > > times, but I just don't get it .... are these clients devices such as > > routers and switches, or actual workstations and PCs? Can you give an > > example? > > > > Thanks, > > Mike > > > > > > ========================================== > > Michael Dooley > > Vice President of Product Development > > Lucent Technologies, IP Services Product Group > > mdooley@lucent.com > > ========================================== > > > > > > > From dhcp-v4@bucknell.edu Tue Jun 15 15:22: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 PAA27378 for ; Tue, 15 Jun 1999 15:22: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 PAA30560; Tue, 15 Jun 1999 15:15:38 -0400 (EDT) Date: Tue, 15 Jun 1999 15:15:38 -0400 (EDT) Message-Id: <199906151903.MAA16678@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: draft on the "Subnet Selection Option for DHCP" X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > It may be necessary to develop a new ICMP Subnet Query message. This > would be the best solution, and would probably be useful to some other > protocols as well. Why not just use DHCP, then? :') If you want the benefit of multicast, have the relay agent be receptive to multicast. This solves the whole problem, and doesn't require any major changes to any widely-deployed protocols, nor does it require that networks that need to support both old and new clients support two very different ways of doing DHCP. _MelloN_ From dhcp-v4@bucknell.edu Tue Jun 15 15:22:36 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 PAA27406 for ; Tue, 15 Jun 1999 15:22: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 PAA04702; Tue, 15 Jun 1999 15:13:46 -0400 (EDT) Date: Tue, 15 Jun 1999 15:13:46 -0400 (EDT) Message-Id: <199906151830.LAA16560@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: draft on the "Subnet Selection Option for DHCP" X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > It would also be useful with multicast DHCP clients, since they would > not require a forwarder (and would therefore not have a GIADDR field) > but would still have to be able to identify the network they are on. How would they identify the network they were on? _MelloN_ From dhcp-v4@bucknell.edu Tue Jun 15 15:23: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 PAA27443 for ; Tue, 15 Jun 1999 15:23: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 PAA01056; Tue, 15 Jun 1999 15:15:13 -0400 (EDT) Date: Tue, 15 Jun 1999 15:15:13 -0400 (EDT) Message-Id: <3766A0E7.3FAC11DF@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: draft on the "Subnet Selection Option for DHCP" 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 > > It would also be useful with multicast DHCP clients, since they would > > not require a forwarder (and would therefore not have a GIADDR field) > > but would still have to be able to identify the network they are on. > > How would they identify the network they were on? A most excellent question, which I do not have a most excellent answer for at the moment. The two obvious choices are (A) preconfigured at the client, or (B) ask the network. (A) has major problems of course. As for (B), there are lots of protocols already around that could provide parts of this. One possibility would be for the client to multicast a router discovery message, which local routers would respond to. Since the query is multicast, the client doesn't need an address. But since RDP responses are unicasts, the clinet would need an address. The client would also need a way to determine which portion of the addresses received back are the network portion of the addresses. ICMP Subnet Mask query messages are a solution to that as well. Don't worry: I don't think this is a very workable approach either. It may be necessary to develop a new ICMP Subnet Query message. This would be the best solution, and would probably be useful to some other protocols as well. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Tue Jun 15 16:58:14 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 QAA00241 for ; Tue, 15 Jun 1999 16:58:13 -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 QAA27177; Tue, 15 Jun 1999 16:52:23 -0400 (EDT) Date: Tue, 15 Jun 1999 16:52:23 -0400 (EDT) Message-Id: <3766B7C1.44769F03@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: draft on the "Subnet Selection Option for DHCP" 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 you want the benefit of multicast, have the relay agent be > receptive to multicast. This solves the whole problem, and doesn't > require any major changes to any widely-deployed protocols, nor does > it require that networks that need to support both old and new clients > support two very different ways of doing DHCP. This is a good point, and one I have wrestled with myself. There are lots of issues here though. Suppose that a client sends a DHCPDISCOVER, which the BOOTP forwarder picks up. What does the BOOTP forwarder do with it? Does it multicast the message onto the next network? What does the next-hop forwarder do with it? While it seems like this would certainly "work" it doesn't address the primary benefit of using multicasts in the first place, which is that we wouldn't need BOOTP forwarders at all. BOOTP forwarders are problematic on many dimensions, and multicasting would solve most of those problems. They are difficult to maintain, and require human management. They provide no value beyond replicating queries and responses. Multicasts on the other hand eliminate (not "solve" but "eliminate") all of those problems. I'd rather see a pure-multicast query/response approach, simply because it means we can eliminate the Internet's only mandatory proxy. A non-trivial side benefit to multicast queries and responses would be that server-store replication would be automated, since all of the servers would see all of the transactions. There are still loads of problems that have to be resolved. For example, what should the default TTL be set to? The specs say that the default is "one hop," which surely isn't enough. Sixteen will be too many for some networks, and not enough for others. Hard questions. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Tue Jun 15 18:54: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 SAA02674 for ; Tue, 15 Jun 1999 18:54: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 SAA19378; Tue, 15 Jun 1999 18:48:19 -0400 (EDT) Date: Tue, 15 Jun 1999 18:48:19 -0400 (EDT) Message-Id: <199906152213.PAA17297@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: draft on the "Subnet Selection Option for DHCP" X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Suppose that a client sends a DHCPDISCOVER, which the BOOTP forwarder > picks up. What does the BOOTP forwarder do with it? Does it multicast > the message onto the next network? What does the next-hop forwarder do > with it? While it seems like this would certainly "work" it doesn't > address the primary benefit of using multicasts in the first place, > which is that we wouldn't need BOOTP forwarders at all. Eliminating relay agents using multicast would be very hard to do - you need to accomplish quite a few things: (a) Get packets from the client to the server, when the client doesn't have an IP address, (b) Provide a way for the client to determine what network segment it's connected to, and (c) Get the response back to the client. (a) is pretty tractable - we could continue with the current system of using the 0.0.0.0 source address. (b) is hard, as you've pointed out. Because there's no relay agent, the client has to figure out to what network segment it's attached to before it sends its DHCP request, and before it has an IP address. This is tricky to do, and I would argue that it may be impossible to do without special layer-violating hacks to the router. (c) is even harder to do. If you unicast the packet back to the client's new IP address, the router that receives it will try to ARP for that IP address, which the client does not yet know, and so the packet will just be dropped by the router when it gets no response. In order to make this work, the DHCP server has to reach out and stuff a value into the router's ARP cache, so that the router won't need to ARP for the client. But the DHCP server doesn't know the router's IP address, because the packet was routed, not relayed. So I think you're proposing that we introduce a total of three new protocols in addition to multicast DHCP: one to allow the client to get its network number without having an IP address, one to allow the server to figure out what router initially forwarded a multicast message (maybe the client would get this information in the first protocol and stuff it in the DHCP packet) and one to allow the DHCP server to reach out and stuff the ARP cache of the router (this can be done with SNMP on some routers, but it's by no means ubuquitous). This is starting to sound hard enough that we really need to do a cost/benefit analysis and also try to see if there are any less expensive ways to solve the same problem. As far as a cost/benefit analysis goes, before you can benefit from this protocol, you need to do the following: - Come up with all the protocols that are required to implement this, and specify them to the point where they can be implemented. - Get people (particularly Microsoft) to implement them. - Replace all existing DHCP clients with clients that know all of the new protocols (you have to replace _all_ clients, or you still have to have the old infrastructure around). - Install new software on all of your routers that supports the new protocols, and probably in some cases replace old routers with new ones where support for the new protocols is not available. - Get multicast working on your network, if it is not already working. - Update your DHCP server(s) On the plus side, we have the following benefits: - Eliminates the need to configure relay agents on the routers for every network on which DHCP is supported - Eliminates the Internet's only mandatory proxy You mentioned that store/replication would be automated, since servers will see all transactions, but in fact in this one instance there would be no difference - the way DHCP relay agents and clients currently work, all servers see all requests. The multicast protocol could mandate that clients multicast even renewals, and this would extend the coverage somewhat, but I don't think it makes much difference. Since UDP isn't reliable (something multicast doesn't change), we can't count on client requests to keep servers synchronized - there still needs to be a reliable protocol keeping servers in sync. There's a truism that all of us who go to the IETF DHCP working group meetings every four months recite to each other as we're considering protocol changes: it's a lot easier to upgrade one server than 50,000 clients. Realistically, any change that requires a change to the client has to be thought of as a very long-term change. If you are expecting to realize any real benefit before the year 2010, I would say that your proposal is probably the wrong way to go, because even assuming that Microsoft comes out with support for your proposed protocols in the very first Windows release following Windows 2000, you will still need to keep the old infrastructure around until the last Windows 2000 install is powered off, and that's not going to be for a while. How many of your clients still have WfW installed on some of their systems? If you are thinking of this as a circa 2010 solution, I applaud your forward thinking. However, I still think that there are simpler ways to solve this problem, with somewhat smoother upgrade paths. It seems to me that the major problem you're trying to solve is that you want to avoid having to configure a relay agent in every router on every network in a large enterprise, and you especially want to avoid having to maintain that configuration through manual intervention as time goes by. The problem that DHCP is "the Internet's only mandatory proxy" is really an aesthetic problem, and I think it's a mistake to believe that you can make DHCP aesthetically pleasing with this one change. Aside from the BOOTP packet format, DHCP is a protocol that does something in IPv4 that no other protocol does, so it's no surprise that it's a bit ugly. I think the easy way to solve your problem is to simply have DHCP relay agents do the multicast. You still have to have a relay agent, but you no longer have to configure it - just have it multicast the DHCP request to all servers that are listening. Because the relay agent has an IP address, the server can still unicast its response. This pretty much cleans up all the goo I described earlier - the DHCP server no longer has to stuff the router's ARP table, you don't have to have a special router (because the relay agent doesn't have to be in the router), and the client doesn't have to be modified. The best thing about this is that it gives router vendors an immediate (if temporary) competitive advantage if they are early implementors, so implementation is likely to be quick and widespread, meaning that you could probably deploy this protocol next year if you wanted to, and I'd be glad to help you get the RFCs written to speed the process along. _MelloN_ From dhcp-v4@bucknell.edu Tue Jun 15 20:50: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 UAA04047 for ; Tue, 15 Jun 1999 20:50: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 UAA25060; Tue, 15 Jun 1999 20:46:20 -0400 (EDT) Date: Tue, 15 Jun 1999 20:46:20 -0400 (EDT) Message-Id: <3766F089.18F4D670@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: draft on the "Subnet Selection Option for DHCP" 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 > (a) is pretty tractable - we could continue with the current system of > using the 0.0.0.0 source address. Yeah. > (b) is hard, as you've pointed out. Because there's no relay agent, > the client has to figure out to what network segment it's attached to > before it sends its DHCP request, and before it has an IP address. Easily resolvable with an ICMP Subnet Query message. The real question is whether or not the addition of a new secondary service is cost effective when I'm trying to eliminate another secondary service. > (c) is even harder to do. If the server multicasts the response back (not unicast), then the response will get back to the segment that the request was sent from. The client will only have to monitor the associated group address for a matching response. This is actually very simple and another benefit of using multicasts; the client-location logic is eliminated. > - Replace all existing DHCP clients with clients that know all > of the new protocols (you have to replace _all_ clients, or > you still have to have the old infrastructure around). I was going to wait until the whole thing was better cooked, but what the heck: consider this para a proposal for a new "Version" option. Any request that does not have 2 in this field should be treated as v1 DHCP (ie, as it stands today). > - Install new software on all of your routers that supports > the new protocols, and probably in some cases replace old > routers with new ones where support for the new protocols is > not available. The only new code would be an extension to ICMP. There would be no new code required for anything else, assuming the router already supported multicasts correctly. > - Get multicast working on your network, if it is not already > working. Its "on" already for every consumer-class OS and router shipped today. There are still some devices that don't support it, but trust me when I say that it would be more difficult to turn it "off" than it would be to keep it on. Multicast routing is a different story, but that's routing not forwarding. > - Update your DHCP server(s) This is also straightforward. See a v2 request? Send a response to the exact same address as the request came in on (the multicast, or in some cases a broadcast address). > You mentioned that store/replication would be automated, since servers > will see all transactions, but in fact in this one instance there > would be no difference - the way DHCP relay agents and clients > currently work, all servers see all requests. The difference is that in my (soon-to-be-proposed) model, the responses are also multicast, allowing servers to witness the entire negotiation process, which allows them to track what server assigned a specific lease. This is a fundamental change over the unicast nature of today's response model. > Since UDP isn't reliable (something multicast doesn't change), we > can't count on client requests to keep servers synchronized - there > still needs to be a reliable protocol keeping servers in sync. You are absolutely correct. However, this is much less challenging than the problems being faced today. It is conceptually simple to use something like IXFR to keep transaction logs in synch. "What's the highest consecutively numbered transaction you've seen?" or "I seem to have missed transaction number n, please send?" > I think the easy way to solve your problem is to simply have DHCP > relay agents do the multicast. You still have to have a relay agent, > but you no longer have to configure it - just have it multicast the > DHCP request to all servers that are listening. Because the relay > agent has an IP address, the server can still unicast its response. You may be correct. > I'd be glad to help you get the RFCs written to speed the process > along. Thanks for that. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Wed Jun 16 13:00: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 NAA29470 for ; Wed, 16 Jun 1999 13:00: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 MAA13213; Wed, 16 Jun 1999 12:52:49 -0400 (EDT) Date: Wed, 16 Jun 1999 12:52:49 -0400 (EDT) Message-Id: <199906161639.JAA20648@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: draft on the "Subnet Selection Option for DHCP" X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Easily resolvable with an ICMP Subnet Query message. The real question > is whether or not the addition of a new secondary service is cost > effective when I'm trying to eliminate another secondary service. How does the ICMP subnet query response get back to a requestor with no IP address? Am I just being clueless here? This doesn't sound easy to me. It sounds like the router either has to stuff its ARP table to get the response back to a client with an IP address of 0.0.0.0, or you have to violate layering and do the protocol at the link layer instead of the IP layer. And the ARP-table-stuffing seems inherently unreliable - what if two clients try to boot in quick succession? They've both got the same IP address, and therefore the same arp table entry, but they have different MAC addresses! > If the server multicasts the response back (not unicast), then the > response will get back to the segment that the request was sent from. > The client will only have to monitor the associated group address for a > matching response. This is actually very simple and another benefit of > using multicasts; the client-location logic is eliminated. You still need to know where the client is in order to get it its IP address. And you're proposing that every single DHCP response be multicast throughout the entire network now, and that every DHCP client will receive every response for every other DHCP client. On a large network, this could result in a significant increase in DHCP traffic on the average network segment. Granted, it's not broadcast, but it still consumes headroom on ethernets and bandwidth on WAN links. This doesn't seem like an improvement over the current state of affairs. Ask Barr-Hibbs if he'd be willing to tolerate this. > I was going to wait until the whole thing was better cooked, but what > the heck: consider this para a proposal for a new "Version" option. Any > request that does not have 2 in this field should be treated as v1 DHCP > (ie, as it stands today). So you need to continue to replicate the old infrastructure, and you get no benefit from the new protocol. If this is the case, then there's no point in deploying the new protocol - from a cost perspective, as a businessman, I'm not going to deploy the protocol unless I see some kind of benefit to doing so. > The only new code would be an extension to ICMP. There would be no new > code required for anything else, assuming the router already supported > multicasts correctly. Yes, if you assume that the DHCP server is going to multicast its responses, and you assume that multicast routing to the DHCP multicast address is statically configured to distribute such multicasts to all supported networks. > Its "on" already for every consumer-class OS and router shipped today. > There are still some devices that don't support it, but trust me when I > say that it would be more difficult to turn it "off" than it would be to > keep it on. Multicast routing is a different story, but that's routing > not forwarding. It is to multicast routing that I was referring. > The difference is that in my (soon-to-be-proposed) model, the responses > are also multicast, allowing servers to witness the entire negotiation > process, which allows them to track what server assigned a specific > lease. This is a fundamental change over the unicast nature of today's > response model. The fact that there are two opportunities for secondary servers to hear about the transaction instead of one does not make the delivery mechanism reliable - it simply halves the chances that the information will be lost. A reliable protocol requires acknowledgement of transmissions. So using multicast in this case does not change the status quo with respect to secondary servers. > You are absolutely correct. However, this is much less challenging than > the problems being faced today. It is conceptually simple to use > something like IXFR to keep transaction logs in synch. "What's the > highest consecutively numbered transaction you've seen?" or "I seem to > have missed transaction number n, please send?" Clients choose transaction IDs, not servers, and transaction IDs are intended to be essentially random, not sequential, so implementing something like what you're talking about would require substantial changes to the existing protocol, well beyond the scope of the rest of what you've discussed. Given that a failover protocol exists, and that there are implementations of an early version of the protocol that work as intended, I see no benefit to extending the scope of your proposal in this way, and I would argue that you should simply not count this as a potential benefit to your proposed new protocol when doing the cost/benefit analysis. _MelloN_ From dhcp-v4@bucknell.edu Wed Jun 16 15:01: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 PAA14475 for ; Wed, 16 Jun 1999 15:00: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 OAA15727; Wed, 16 Jun 1999 14:59:25 -0400 (EDT) Date: Wed, 16 Jun 1999 14:59:25 -0400 (EDT) Message-Id: <3767ED91.14D9D12D@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: draft on the "Subnet Selection Option for DHCP" 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 > How does the ICMP subnet query response get back to a requestor with > no IP address? Being datagram-oriented, ICMP query/response messages can be multicast the same as UDP datagrams. The router discovery protocol uses ICMP router solicitation and ICMP router advertisement messages over multicast, as an example. It works quite well. What this means for my theory is that the client and router (or other local device like a server) can exchange subnet-specific data without the client having an IP address, and without the server having to locate the client (everything goes to the Class D addresss associated with the protocol). The rest of it you know: Once the client knows the subnet they are on, they can send off a multicast DHCP request, using their MAC address as an event key. A server (or multiple servers) would respond by sending DHCPOFFERS to the multicast address, which the client would choose from and then multicast a DHCPREQUEST for the specific lease it wanted. DHCPACK/DHCPNAK would also be sent over multicast, allowing everybody to witness the process. This is not that radical of a difference, but it has several benefits over the current hop-along approach. It ain't nearly as hard as you're making it. There are problems absolutely, but there are also benefits, and none of the problems are unresolvable. In the end, the protocol will be cleaner (I'll go ahead and commit to unpopularity by saying that the current protocol is fundamentally bad by requiring a proxy). > client will receive every response for every other DHCP client. On a > large network, this could result in a significant increase in DHCP > traffic on the average network segment. Granted, it's not broadcast, > but it still consumes headroom on ethernets and bandwidth on WAN > links. The clients should leave the multicast group when they are not doing renewals, which would limit the active members (and therefore the networks that get the multicast traffic) to the current clients and any servers. Actually, this would probably be the default behavior since most stacks don't keep the DHCP client loaded (and bound) all the time. If the DHCP client is not bound to the stack then there should not be an active listener (reflected by an IGMP Leave message on client unload), meaning no traffic would go to that subnet/switch-port anyway. So it's probably not that much of a real concern in the first place. There would be a slight increase in traffic over a non-replicated installation with a pair of isolated servers. But it would be less traffic than maintaining an n-way mesh of replication partners for the same number of servers as defined in the current replication drafts. > So you need to continue to replicate the old infrastructure, and you > get no benefit from the new protocol. If this is the case, then > there's no point in deploying the new protocol - from a cost > perspective, as a businessman, I'm not going to deploy the protocol > unless I see some kind of benefit to doing so. Lower cost of setup and operation (bye-bye forwarders), and smoother replication. This seems compelling to me (which is why I'm doing this). Also, you only need to keep the existing stuff in place for as long as you want to keep using it. As far as "costs" of migration, the only thing that folks are going to worry about (in my view) is whether or not their preferred server software (and duh clients) are going to keep working. I don't think anybody's going to cry about not having to turn on the forwarder for their new subnets. I'd like to push this along as an expiremental approach, and see where it leads if nothing else. I think its doable and will offer better service with less cost-of-ownership. Whether or not it goes beyond that will be determined by the other people here. My goal is just to make it work so that it can be studied as a possible alternative. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Wed Jun 16 16:27: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 QAA19773 for ; Wed, 16 Jun 1999 16:27: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 PAA17055; Wed, 16 Jun 1999 15:01:46 -0400 (EDT) Date: Wed, 16 Jun 1999 15:01:46 -0400 (EDT) Message-Id: <199906161852.LAA21501@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: draft on the "Subnet Selection Option for DHCP" X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Being datagram-oriented, ICMP query/response messages can be multicast > the same as UDP datagrams. The router discovery protocol uses ICMP > router solicitation and ICMP router advertisement messages over > multicast, as an example. It works quite well. Okay. > A server (or multiple servers) would respond by > sending DHCPOFFERS to the multicast address, which the client would > choose from and then multicast a DHCPREQUEST for the specific lease it > wanted. DHCPACK/DHCPNAK would also be sent over multicast, allowing > everybody to witness the process. Again, this is going to create a huge amount of traffic, multicast to every subnet that supports DHCP. Is this really what you want? Is this really cleaner than having a relay agent? I think the answer is no. > The clients should leave the multicast group when they are not doing > renewals, which would limit the active members (and therefore the > networks that get the multicast traffic) to the current clients and any > servers. Actually, this would probably be the default behavior since > most stacks don't keep the DHCP client loaded (and bound) all the time. Actually, most stacks do keep the DHCP client loaded and bound all the time. To what stacks are you referring? If DHCP is in regular use, and multicast is used as a delivery mechanism, then any network with a significant number of DHCP clients is always, or at least frequently, going to be getting DHCP multicasts. If all the clients on that network unbind from the multicast address when they don't need it, then what you'll see on a large network with lots of DHCP clients is kind of a pulsing effect, where whenever a client needs to do DHCP, suddenly the amount of traffic on the network segment increases substantially. This will, admittedly, be less of a problem on small networks, or networks where the DHCP multicast domain is carefully, manually partitioned. > There would be a slight increase in traffic over a non-replicated > installation with a pair of isolated servers. But it would be less > traffic than maintaining an n-way mesh of replication partners for the > same number of servers as defined in the current replication drafts. Have you read the current failover protocol draft? > Lower cost of setup and operation (bye-bye forwarders), and smoother > replication. This seems compelling to me (which is why I'm doing this). Right, but there's a cheaper way that accomplishes all your goals, other than the goal of eliminating forwarders, for which I can find no objective justification (and for which you've presented no objective justification). So why not go with the cheaper way? > Also, you only need to keep the existing stuff in place for as long as > you want to keep using it. Right, and that's going to be a very, very long time, given that Windows 2000 won't be implementing your protocol (unless there's something you and Peter Ford aren't telling us). > I don't think anybody's going to cry about not having to turn on the > forwarder for their new subnets. Right, but the time when they won't have to turn on the forwarder for new subnets is something like a decade in the future. If you do the multicast in the forwarder, you can stop configuring the forwarder within a year or two, without requiring any changes in the client at all. Isn't this preferable? > I'd like to push this along as an expiremental approach, and see where > it leads if nothing else. I think its doable and will offer better > service with less cost-of-ownership. Whether or not it goes beyond that > will be determined by the other people here. My goal is just to make it > work so that it can be studied as a possible alternative. I think we already know what we need to know to take the next step. What is it that you hope to learn by implementing it? I think we all understand that it's possible to implement the protocol you've proposed. The problem is, will anybody *actually* implement it, given the problems that it has? And if it is implemented, will anybody deploy it? I think you should try to come up with an answer to those two questions before you spend a lot of time implementing something. _MelloN_ From dhcp-v4@bucknell.edu Wed Jun 16 16:40: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 QAA23673 for ; Wed, 16 Jun 1999 16:40: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 QAA08402; Wed, 16 Jun 1999 16:03:15 -0400 (EDT) Date: Wed, 16 Jun 1999 16:03:15 -0400 (EDT) Message-Id: <3767FBC2.41FD35BD@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: draft on the "Subnet Selection Option for DHCP" 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 > > A server (or multiple servers) would respond by sending DHCPOFFERS > > to the multicast address, which the client would choose from and > > then multicast a DHCPREQUEST for the specific lease it wanted. > > DHCPACK/DHCPNAK would also be sent over multicast, allowing > > everybody to witness the process. > > Again, this is going to create a huge amount of traffic, multicast to > every subnet that supports DHCP. Is this really what you want? Is > this really cleaner than having a relay agent? I think the answer > is no. Multicasting does not work that way (and please forgive the following tutorial, it is to make a point). You don't send all traffic to all subnets, but instead only send traffic to segments that have an active listener (or have another router with an active listener). The process of selection uses IGMP membership reports, with devices joining and leaving multicast groups as needed. Routers and switches use these reports to determine which subnet gets what traffic. This is invisible to the application btw, with the stack handling the reports. The result is that when a client needs to get/renew a lease, the agent will bind to the stack which will send the IGMP join message. After the job is done and the client unbinds, the stack will send the IGMP leave message. Until the process is repeated, no multicast datagrams for that specific Class D address will go to that switch port (or even to that subnet if there aren't any other active listeners). The only subnets that will get all traffic will be those that have servers on them (since they will be permanently bound). Filtering at the router solves the WAN utilization problem for people that have it. Not very graceful I know, but this would have to be a per-site call anyway (some folks will want it, others won't) and I can't think of another solution that allows choice. Suggestions welcome. > Actually, most stacks do keep the DHCP client loaded and bound all > the time. To what stacks are you referring? If that's the case then this is a real problem. My understanding was that Windows and MacOS did not stay bound, which is why things like Client32 and DAVE could come in and renew the lease without involving the DHCP agent. If the agent were permanently bound, they shouldn't be able to bind to the stack? Am I wrong? Looking at netstat output on NT4 shows no active UDP protos, and I am using DHCP. The joinc agent is loaded but is not bound to the BOOTPC port on my Digital UNIX 4.0d workstation. Same for dhcpagen on my Solaris 7 box. I don't have a working Linux install at the moment. If the ISC client is staying bound, well, I know one of the guys there and he seems reasonable so maybe I'll ask him to change it . > If DHCP is in regular use, and multicast is used as a delivery > mechanism, then any network with a significant number of DHCP clients > is always, or at least frequently, going to be getting DHCP > multicasts. Those same segments would also be getting the unicasts. There would be an increase in per-segment utilization whenever multiple clients are in renewal or lease mode at the same time. The level that we're talking about is pretty trivial though. I would not call it substantial. This should be monitored for statistical purposes however. > Have you read the current failover protocol draft? Not the absolute latest version, no. > Right, but there's a cheaper way that accomplishes all your goals, > other than the goal of eliminating forwarders, for which I can find no > objective justification (and for which you've presented no objective > justification). So why not go with the cheaper way? I don't see how its cheaper. It just introduces an unnecessary element (worse, the very element that I am trying to kill off). > Right, but the time when they won't have to turn on the forwarder for > new subnets is something like a decade in the future. If you do the > multicast in the forwarder, you can stop configuring the forwarder > within a year or two, without requiring any changes in the client at > all. Isn't this preferable? A forwarder is not needed. I see no reason to mandate its use. I also see no reason to FORBID its use, and there are scenarios where a proxy would be desirable (it lets you keep the TTL at "1" for example). Its usage should be addressed and left as optional for the user I suppose. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Wed Jun 16 16:49: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 QAA25543 for ; Wed, 16 Jun 1999 16:49: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 QAA05158; Wed, 16 Jun 1999 16:43:08 -0400 (EDT) Date: Wed, 16 Jun 1999 16:43:08 -0400 (EDT) Message-Id: <199906162028.NAA21949@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: draft on the "Subnet Selection Option for DHCP" X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > You don't send all traffic to all > subnets, but instead only send traffic to segments that have an active > listener (or have another router with an active listener). I understand that, Eric. > This is invisible to the application btw, with the stack handling > the reports. I assume that the protocol somehow allows a client with no IP address to join a multicast group, right? > The result is that when a client needs to get/renew a lease, the agent > will bind to the stack which will send the IGMP join message. After the > job is done and the client unbinds, the stack will send the IGMP leave > message. Right. So if you have a subnet with, say, 200 clients, each of which takes on the order of ten seconds to go through the join/renew/quit process, then you are receiving all DHCP multicast traffic on that subnet (200*10*(lease-interval/2))/3600 seconds in every hour. I don't know how accurate a guess this is, but my suspicion is that it's not far off. Also, if any single client out of those 200 forgets to leave the multicast group, either because it is powered off during the renewal, hangs in the middle of the renewal (behaviour which I have seen, BTW) or because of a bug in its stack, then that network is going to be getting the multicast traffic until such time as the router times out (I assume the multicast routing protocol has some kind of timeout to take care of this). > Filtering at the router solves the WAN utilization problem for people > that have it. Not very graceful I know, but this would have to be a > per-site call anyway (some folks will want it, others won't) and I can't > think of another solution that allows choice. Suggestions welcome. Right, but this requires more configuration work than does simply configuring a relay agent, so again, where's the payoff? > If that's the case then this is a real problem. My understanding was > that Windows and MacOS did not stay bound, which is why things like > Client32 and DAVE could come in and renew the lease without involving > the DHCP agent. If the agent were permanently bound, they shouldn't be > able to bind to the stack? Am I wrong? Maybe you're right. Whether or not this is true, the problem still exists - this merely reduces its magnitude. > If the ISC client is staying bound, well, I know one of the guys there > and he seems reasonable so maybe I'll ask him to change it . He might even comply, but he remains unconvinced of the need to do so at this time... :') > > If DHCP is in regular use, and multicast is used as a delivery > > mechanism, then any network with a significant number of DHCP clients > > is always, or at least frequently, going to be getting DHCP > > multicasts. > Those same segments would also be getting the unicasts. Not true. Say you have a network with 20k DHCP clients, on average 200 per subnet. The unicast traffic, per subnet, is then one packet every 200*(lease-interval)/2 seconds. The multicast traffic will be for every client on the network, although it will be lessened by the automatic subscription and unsubscription of subnets as clients listen and then stop listening. Consider the effects that this has on a DHCP server administrators' range of choices. Currently, as a DHCP server administrator, I can set different lease times for different kinds of clients - clients that roam from network to network can be configured with very short lease times, with no significant impact on other clients. In your scenario, shortening the lease renewal time for a mobile client will have a direct impact on the traffic load on every subnet to which that client might connect. Even if only 10% of my clients are mobile, I'm still going to be very reluctant to provide such clients with a shorter lease time, and as a consequence, those clients are going to see a marked reduction in convenience. This also opens you up to a cool denial-of-service attack: the bad guy just subscribes to the DHCP multicast group, and suddenly your network is flooded with DHCP traffic. Quality of service drops, but probably not enough to set of any alarms. In terms of traceability, this attack is virtually perfect - you can easily forge the packet, and still win. The only way to catch it is to have a really smart hub, and even then, how easy is it going to be to seperate the DoS attack out from all the legitimate traffic that's virtually identical? > Those same segments would also be getting the unicasts. There would be > an increase in per-segment utilization whenever multiple clients are in > renewal or lease mode at the same time. The level that we're talking > about is pretty trivial though. I would not call it substantial. This > should be monitored for statistical purposes however. How substantial it is will depend on the number of clients being served by a single DHCP server. On networks where DHCP is deployed in a distributed manner, it shouldn't ever be a real problem. On networks with centralized DHCP service, which I would argue are exactly the same networks that have the most need for easier configurability, the impact could be dramatic. On a corporate network that I know a lot about, the traffic impact would be about 2% of the realistically available bandwidth of an ethernet, and this is with very conservative lease times. Granted, if you go to 100mbps networks, or have good hubs, the impact of this can be greatly reduced, but when designing a protocol, it's very important not to make decisions like this, because there are only so many protocols for which you can make this sort of allowance (to wit: 50) before you run out of bandwidth on the network. Given that the relay agent multicast scenario I described does not have this problem, I would argue that it's a much cleaner solution. > I don't see how its cheaper. It just introduces an unnecessary element > (worse, the very element that I am trying to kill off). If this is the only reason that you are proposing this protocol change, then we don't need to continue this discussion any further. I presumed, based on your www resume, that you were concerned about ease of configurability for large networks primarily, and that the relay agent was just an aesthetic issue you didn't like. If your sole reason for proposing this change in the protocol is to get rid of the relay agent, then I vote no. I think you will find that most implementors and knowledgable customers will vote the same way. > A forwarder is not needed. I see no reason to mandate its use. I also > see no reason to FORBID its use, and there are scenarios where a proxy > would be desirable (it lets you keep the TTL at "1" for example). Its > usage should be addressed and left as optional for the user I suppose. More knobs to tweak? This is an autoconfiguration protocol. The fewer knobs you (the administrator) have to know about, the better. I think leveraging multicast is a good idea, to the extent that it reduces broadcast traffic or eases configurability, and I encourage you to continue investigating it. But I also encourage you to maintain an open mind, and to not try "to kill off" a useful tool simply because you don't like it. _MelloN_ From dhcp-v4@bucknell.edu Wed Jun 16 17:25: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 RAA29095 for ; Wed, 16 Jun 1999 17:25: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 RAA12988; Wed, 16 Jun 1999 17:25:54 -0400 (EDT) Date: Wed, 16 Jun 1999 17:25:54 -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: draft on the "Subnet Selection Option for DHCP" 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 does any of this multicast discussion have anything to do with the draft listed in the subject line? /gww From dhcp-v4@bucknell.edu Wed Jun 16 17:26: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 RAA29118 for ; Wed, 16 Jun 1999 17:26: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 RAA03524; Wed, 16 Jun 1999 17:26:23 -0400 (EDT) Date: Wed, 16 Jun 1999 17:26:23 -0400 (EDT) Message-Id: <376811B5.AF9B0877@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: draft on the "Subnet Selection Option for DHCP" 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 I'm going to keep working on this, but we should probably go off-list for any more discussion until something is in a presentable form. We've pretty much hit on all the major issues I think. Whether anything happens with the expiremental proposal would be left to the desires of this group of course. > I assume that the protocol somehow allows a client with no IP address > to join a multicast group, right? Because the delivery of multicast packets primarily happens at the data-link layer with Ethernet (the destination address is a group Ethernet address), recipient systems do not need an IP address in order to receive the multicast datagrams. Therefore, a stack should not _require_ an IP address in order to send or receive multicast packets. Whether or not all stacks work in this way is an unknown, and will be an interesting issue to explore during development. Naturally, just because it shouldn't matter doesn't mean that it won't. > Right. So if you have a subnet with, say, 200 clients, each of which > takes on the order of ten seconds to go through the join/renew/quit > process, then you are receiving all DHCP multicast traffic on that > subnet (200*10*(lease-interval/2))/3600 seconds in every hour. Assuming lots of things, like that all of the clients are active for the same ten second window. This is a stretch in my view, but is worth monitoring. My guess is that no more than a dozen or so devices (out of 200) would be active at the same time unless there was a building wide power failure and restart. It could be a problem if all of them were active simultaneously. > I assume the multicast routing protocol has some kind of timeout to > take care of this. Yeah. Routers will periodically issue memebership queries to the network asking for active listeners of current gropus. If no listener responds for the group, then traffic for that group address is no longer forwarded to that subnet. If any one listener responds, then the group is left as-is. Some switch vendors are doing this on a per-port basis. > configurability, the impact could be dramatic. On a corporate network > that I know a lot about, the traffic impact would be about 2% of the > realistically available bandwidth of an ethernet, and this is with > very conservative lease times. I would be very interested in seeing how this model would consume 2% of the available bandwidth on this network. The number of messages being exchanged stays the same remember; the only difference is which switch-ports get data, which really relates to per-segment utilization. On shared Ethernet and Token Ring networks, the frame rate does not increase at all. On switched Ethernet, the frame rate on a per-segment basis does go up, but only for the 10 seconds or so that the client is active. The backbone frame rate will not change. I just don't see how this would add up to 2% except on the poorest-designed of networks. > If this is the only reason that you are proposing this protocol > change, then we don't need to continue this discussion any further. I > presumed, based on your www resume, that you were concerned about ease > of configurability for large networks primarily, and that the relay > agent was just an aesthetic issue you didn't like. My motivation is directly due to what I have seen at orgs when it comes to dealing with this component. It's unnecesary, so why have it at all? Just to preserve the status-quo? -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Wed Jun 16 18:20: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 SAA02116 for ; Wed, 16 Jun 1999 18:20: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 SAA28946; Wed, 16 Jun 1999 18:20:47 -0400 (EDT) Date: Wed, 16 Jun 1999 18:20:47 -0400 (EDT) Message-Id: <376820BC.1F2DBF0D@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: draft on the "Subnet Selection Option for DHCP" 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 > does any of this multicast discussion have anything to do with the > draft listed in the subject line? Apologies for drifting. I do have a concern with the option as defined, which is that it does not provide a multi-valued array. It is feasible for a sending device (such as a PPP server) to have multiple subnets available for clients. Being able to seed the DHCPDISCOVER message with each of those subnets would seem to be an important characteristic. The gateway device may wish to get multiple OFFERS from multiple servers, each of which serve the unique subnets, and then choose a lease (or really, choose a subnet) for the client based on offerred data. Is this an oversight or is this a non-issue? -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Wed Jun 16 18:26: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 SAA02417 for ; Wed, 16 Jun 1999 18:26: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 SAA14993; Wed, 16 Jun 1999 18:21:41 -0400 (EDT) Date: Wed, 16 Jun 1999 18:21:41 -0400 (EDT) Message-Id: <199906162150.OAA22282@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: draft on the "Subnet Selection Option for DHCP" X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Because the delivery of multicast packets primarily happens at the > data-link layer with Ethernet (the destination address is a group > Ethernet address), recipient systems do not need an IP address in order > to receive the multicast datagrams. Therefore, a stack should not > _require_ an IP address in order to send or receive multicast packets. How does the stack get the request to the router to join the multicast group when it doesn't have an IP address? > I would be very interested in seeing how this model would consume 2% of > the available bandwidth on this network. The number of messages being > exchanged stays the same remember; The number of messages arriving on the local network does _not_ stay the same! In the multicast case, whenever any client on the local network is subscribed to the multicast group, that network sees every request and every response for every DHCP client anywhere in the local multicast domain. This is _very_ different from the status quo - currently, a given network (other than the DHCP server's network, which we needn't consider) sees only the traffic generated by local clients, and the traffic sent to those clients. And since most of this traffic is currently unicast, in a switched environment the impact will be even smaller. This is a *big* difference in a large corporate environment. > Assuming lots of things, like that all of the clients are active for the > same ten second window. This is a stretch in my view, but is worth > monitoring. My guess is that no more than a dozen or so devices (out of > 200) would be active at the same time unless there was a building wide > power failure and restart. It could be a problem if all of them were > active simultaneously. No, this assumes that clients are never active in the same window. If they are active in the same window, the problem is potentially much less severe, because the number of windows decreases (although the traffic within the window increases while it's open). Operational experience, as relayed to me from a number of large ISC DHCP users, suggests that there is a relatively fixed steady level of traffic in a large installation. Whenever a subnet is subscribed to the multicast group, it will see all of that traffic. Actually, though, one of the scenarios we have considered in this working group is the 9am power-on scenario, where at a company with strict working hours, all the workers power on their DHCP client machines at the same time. Currently we haven't ever had a report of a major problem as a result of this scenario, but I think with the protocol you are proposing, we would actually have a problem. The problem is that if every client starts up at 9am, then every client's requests, and all the responses to those requests, will be distributed to every the network segment in the entire company. Now, imagine that this company provides DHCP service from a central location to a variety of sites, all connected via WAN links. This DHCP traffic is going to completely swamp any narrow WAN links. If this sounds far-fetched, please be aware that I know of more than one company that has deployed DHCP service in exactly this way, and is very satisfied with the current results. Because of the packet loss introduced on the WAN links, this would cause a large percentage of the clients not to hear responses to their requests, resulting in retries. Since different packets will be lost on each WAN link funnel, the chances that a particular client's response will make it back to its own site are fairly slim, although its response will almost certainly make it to *some* site. The packet storm would probably subside fairly quickly, but in the aftermath, a large percentage of all the Win2010 machines in the company would have autoconfigured, and would be unable to use the network. The result of this would be a support call storm the likes of which I shudder to imagine. While I do not personally know of a company where the 9am scenario and the WAN scenario both currently exist, it is easy to imagine that such a company exists, and I think it's worth being careful not to break their network. I suspect most DHCP client vendors will feel similarly: these people have deep pockets, will be buying a lot of Win2010 licenses, and will not be interested in hearing explanations as to why their network melts down and their support phones ring off the hook every morning at 9am. They will be interested in eliminating whatever software caused the problem. Given that I like seeing my software widely deployed, I'm going to think long and hard before implementing support for the protocol you're suggesting, and I suspect other DHCP client vendors will as well. > I just don't see how this would add up to 2% except on the > poorest-designed of networks. The corporate network to which I am referring above has a steady-state inter-packet arrival gap at the DHCP server of 100ms. If you figure that the headroom on a shared ethernet segment is about 25% of the total bandwidth, or 2.5mbps, and the average DHCP packet is 576 bytes, and that the DHCP server doesn't ever respond to any DHCP packet, then the bandwidth consumption works out to around 1.7%. If you figure the DHCP server responds to 100% of the packets it receives, the bandwidth consumption is actually 3.4%. I chose 2% as a nice round number. Of course, if you go to 100mbps full duplex, these numbers drop by more than an order of magnitude, and if the deployment horizon for this protocol is ten years, maybe that's not a bad assumption to make. > My motivation is directly due to what I have seen at orgs when it comes > to dealing with this component. It's unnecesary, so why have it at all? > Just to preserve the status-quo? You claim that it is unnecessary, but you haven't said anything so far that backs up this claim, other to propose a protocol that I would be very reluctant to deploy. I claim that it is quite necessary, and I think I've made a pretty good case that that's so. Furthermore, I've provided you with an easily-implemented way to get rid of the configuration problem that you're complaining about, without introducing any of the problems your protocol would introduce. So no, I'm not arguing to preserve the status quo. I'm arguing in favor of the best protocol we can come up with that solves the problems we need to solve. _MelloN_ From dhcp-v4@bucknell.edu Wed Jun 16 19:04: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 TAA03958 for ; Wed, 16 Jun 1999 19:04: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 SAA32361; Wed, 16 Jun 1999 18:59:18 -0400 (EDT) Date: Wed, 16 Jun 1999 18:59:18 -0400 (EDT) Message-Id: <199906162221.PAA22367@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: draft on the "Subnet Selection Option for DHCP" X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 I think Mr. Hall was proposing that the subnet selection option be used by the DHCP client to indicate its location. The subsequent discussion has strayed a bit from the original topic, but I still think it's useful. _MelloN_ From dhcp-v4@bucknell.edu Wed Jun 16 20:16: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 UAA04962 for ; Wed, 16 Jun 1999 20:16: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 UAA00603; Wed, 16 Jun 1999 20:16:15 -0400 (EDT) Date: Wed, 16 Jun 1999 20:16:15 -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: draft on the "Subnet Selection Option for DHCP" 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 the intent is that the device (the PPP server in your example) would get an address on each of the subnets using separate DHCPDISCOVERs for each subnet. the device would then cache those addresses and hand them out as it sees fit. i'm not sure how useful it is for a device getting multiple offers **potentially** from different subnets -- i would think that you want to specify precisely the subnet on which you want the address. /gww > -----Original Message----- > From: dhcp-v4@bucknell.edu [mailto:dhcp-v4@bucknell.edu]On Behalf Of > Eric A. Hall > Sent: Wednesday, June 16, 1999 18:21 > To: Multiple recipients of list > Subject: Re: draft on the "Subnet Selection Option for DHCP" > > > > > does any of this multicast discussion have anything to do with the > > draft listed in the subject line? > > Apologies for drifting. > > I do have a concern with the option as defined, which is that it does > not provide a multi-valued array. It is feasible for a sending device > (such as a PPP server) to have multiple subnets available for clients. > Being able to seed the DHCPDISCOVER message with each of those subnets > would seem to be an important characteristic. The gateway device may > wish to get multiple OFFERS from multiple servers, each of which serve > the unique subnets, and then choose a lease (or really, choose a subnet) > for the client based on offerred data. > > Is this an oversight or is this a non-issue? > > -- > Eric A. Hall ehall@ehsco.com > +1-650-685-0557 http://www.ehsco.com > > From dhcp-v4@bucknell.edu Wed Jun 16 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 VAA05793 for ; Wed, 16 Jun 1999 21:39:11 -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 VAA08332; Wed, 16 Jun 1999 21:39:07 -0400 (EDT) Date: Wed, 16 Jun 1999 21:39:07 -0400 (EDT) Message-Id: <37684779.C34605C2@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: draft on the "Subnet Selection Option for DHCP" 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 device would then cache those addresses and hand them out as it > sees fit. Is caching lease data a good idea? Is this really the intended use? I'm asking out of curiosity. It would seem to me that requesting leases on an as-needed basis would be safer, at least from expiration or conflict avoidance points of view. > i'm not sure how useful it is for a device getting multiple offers > **potentially** from different subnets -- i would think that you want > to specify precisely the subnet on which you want the address. I guess my concern is that in some scenarios the gateway device is not entirely sure which subnet it should be making assignments from and needs clues from the network to make the decision. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Wed Jun 16 23:40: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 XAA08740 for ; Wed, 16 Jun 1999 23:40:21 -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 XAA00620; Wed, 16 Jun 1999 23:40:18 -0400 (EDT) Date: Wed, 16 Jun 1999 23:40:18 -0400 (EDT) Message-Id: <199906170309.XAA15426@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: I-D ACTION:draft-ietf-dhc-subnet-option-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 message sent to dhcp-v4@bucknell.edu by RANDY@PSG.COM follows. -------------------------------------------------------------- 5. Security Considerations DHCP currently provides no authentication or security mechanisms. Potential exposures to attack are discussed is section 7 of the protocol specification [RFC2131]. does this not protocol not open up a new security risk, requesting on an arbitrary subnet? randy From dhcp-v4@bucknell.edu Wed Jun 16 23:41: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 XAA08763 for ; Wed, 16 Jun 1999 23:41: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 XAA23853; Wed, 16 Jun 1999 23:36:25 -0400 (EDT) Date: Wed, 16 Jun 1999 23:36:25 -0400 (EDT) Message-Id: <199906170301.UAA23165@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: DHCP with multicasting relay agents... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > I guess I missed the description on what function the proxy would > provide in the multicast arena. Please clarify the exact functionality? > Would it listen for multicast queries and then forward them as unicasts > to the targets? The function it would provide would be that you'd have a relay agent in each router, just like you do now, but instead of having to configure each relay agent with a list of DHCP servers to which to forward packets, you would simply have the relay agent forward all client DHCP packets to a well-known, routed multicast address. The protocol would otherwise be unchanged - the relay agent would still stuff giaddr, and the server would still unicast the response to the relay agent, which would either broadcast or unicast it to the client on the local network. Just this one change could eliminate the relay agent configuration problem, which I think is the real problem you're trying to solve. It also has the benefit that it requires no change to the DHCP client - just to the DHCP relay agents and the server, which are orders of magnitude easier to change, and whose vendors would have a much greater motivation to implement the new protocol. If you want to also eliminate the current problem of broadcast traffic originating from the client, you can do this by having new clients use multicast to a well-known subnet-local multicast address on which relay agents all listen. You still have a relay agent on the local network, but now all the other DHCP clients on the network don't have to hear new-style clients' initial startup messages. Compared to the relay agent configuration problem, though, this is a fairly minor issue. _MelloN_ From dhcp-v4@bucknell.edu Wed Jun 16 23:42:51 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 XAA08776 for ; Wed, 16 Jun 1999 23:42: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 XAA08566; Wed, 16 Jun 1999 23:38:36 -0400 (EDT) Date: Wed, 16 Jun 1999 23:38:36 -0400 (EDT) Message-Id: <199906170305.UAA23175@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: draft on the "Subnet Selection Option for DHCP" X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > I do have a concern with the option as defined, which is that it does > not provide a multi-valued array. It is feasible for a sending device > (such as a PPP server) to have multiple subnets available for clients. > Being able to seed the DHCPDISCOVER message with each of those subnets > would seem to be an important characteristic. The gateway device may > wish to get multiple OFFERS from multiple servers, each of which serve > the unique subnets, and then choose a lease (or really, choose a subnet) > for the client based on offerred data. The draft specifies that the server will treat the network address provided in the subnet selection option the same way that it currently treats the giaddr field. Current DHCP servers can be configured to know that a giaddr on one subnet actually refers to a network segment containing more than one subnet, and can therefore assign addresses on any such subnet. We talked about adding the functionality you're proposing in Minneapolis, but wound up deciding it wasn't a good idea. The consensus was that since the DHCP server needs to know the subnet configuration in order to do address assignment, having the relay agent or RAS send a selection of subnets on which to assign an address adds no value, and indeed needlessly complicates the implementation of the DHCP server and the configuration of the relay or RAS agent. _MelloN_ From dhcp-v4@bucknell.edu Thu Jun 17 00:22:31 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 AAA09068 for ; Thu, 17 Jun 1999 00:22:31 -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 AAA13106; Thu, 17 Jun 1999 00:18:10 -0400 (EDT) Date: Thu, 17 Jun 1999 00:18:10 -0400 (EDT) Message-Id: <199906170358.UAA23450@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: I-D ACTION:draft-ietf-dhc-subnet-option-02.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > 5. Security Considerations > > DHCP currently provides no authentication or security mechanisms. > Potential exposures to attack are discussed is section 7 of the > protocol specification [RFC2131]. > > does this not protocol not open up a new security risk, requesting on an > arbitrary subnet? I'm not sure that the incremental risk is substantial. I suppose it makes it possible for an address-pool exhaustion DoS attack to be more complete, but other than that, what benefit do I obtain by acquiring an IP address on a subnet to which I'm not connected? We already have to deal with the address-pool exhaustion DoS attack, so I don't see any reason to think of this as a significant new concern. _MelloN_ From dhcp-v4@bucknell.edu Thu Jun 17 01:34: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 BAA15867 for ; Thu, 17 Jun 1999 01:34: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 BAA24315; Thu, 17 Jun 1999 01:34:13 -0400 (EDT) Date: Thu, 17 Jun 1999 01:34:13 -0400 (EDT) Message-Id: <376886C1.E6CC6D9F@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: DHCP with multicasting relay agents... 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 function it would provide would be that you'd have a relay agent > in each router, just like you do now, but instead of having to > configure each relay agent with a list of DHCP servers to which to > forward packets, you would simply have the relay agent forward all > client DHCP packets to a well-known, routed multicast address. This is as an acceptable solution to the primary issue of mandatory proxies if it means getting done quickly. While it does not offer all of the functionality that an all-multicast approach would offer, it certainly doesn't have anywhere near the quantity of problems either. Later, when emboldened with some kind of success, perhaps we can go back to tackling the DHCP-Client multicast group problems. > Just this one change could eliminate the relay agent configuration > problem, which I think is the real problem you're trying to solve. It is my primary objective, but I also liked the opportunity of making n-way replication easier as well. This approach does not address that directly, although it does offer a channel for widely distributing data easily, which could be useful as a building block. I suppose the logical path would be to pursue the DHCP-Server group functionality and leave the client issues for later. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Thu Jun 17 02:51: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 CAA25035 for ; Thu, 17 Jun 1999 02:51: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 CAA04833; Thu, 17 Jun 1999 02:45:39 -0400 (EDT) Date: Thu, 17 Jun 1999 02:45:39 -0400 (EDT) Message-Id: <199906170636.CAA00368@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: DHCP with multicasting relay agents... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > This is as an acceptable solution to the primary issue of mandatory > proxies if it means getting done quickly. While it does not offer all of > the functionality that an all-multicast approach would offer, it > certainly doesn't have anywhere near the quantity of problems either. > > Later, when emboldened with some kind of success, perhaps we can go back > to tackling the DHCP-Client multicast group problems. That sounds like an excellent approach. > It is my primary objective, but I also liked the opportunity of making > n-way replication easier as well. This approach does not address that > directly, although it does offer a channel for widely distributing data > easily, which could be useful as a building block. Right. You could indeed use the same multicast infrastructure that the relay agents would use to allow servers to do multicast propogation of lease updates for some future n-way replication protocol. > I suppose the logical path would be to pursue the DHCP-Server group > functionality and leave the client issues for later. Sounds like a plan! When can we expect to see the draft? *evil grin* _MelloN_ From dhcp-v4@bucknell.edu Thu Jun 17 04:36:11 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 EAA25628 for ; Thu, 17 Jun 1999 04:36:10 -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 EAA19888; Thu, 17 Jun 1999 04:36:07 -0400 (EDT) Date: Thu, 17 Jun 1999 04:36:07 -0400 (EDT) Message-Id: <3768B029.59B19641@eed.ericsson.se> Errors-To: droms@bucknell.edu Reply-To: eedjib@eed.ericsson.se Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Juan-Antonio Ibanez To: Multiple recipients of list Subject: Status of draft-ietf-dhc-agent-options-05.txt 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.04 [en] (WinNT; I) Content-Transfer-Encoding: 7bit Hi all, I just joined the list and I have a special interest in the I-D draft-ietf-dhc-agent-options-05.txt, particularly the 'Agent Circuit ID' sub-option. What is the current status of this I-D? Is it on the way to becoming an RFC? In a cellular packet data network the Agent Circuit ID sub-option would be very useful to locate the terminal equipment that generated a DHCPDISCOVER message and to which the DHCPOFFER(s) have to be relayed by a relay agent. /Juan From dhcp-v4@bucknell.edu Thu Jun 17 10:09: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 KAA28222 for ; Thu, 17 Jun 1999 10:09: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 JAA10395; Thu, 17 Jun 1999 09:59:38 -0400 (EDT) Date: Thu, 17 Jun 1999 09:59:38 -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: I-D ACTION:draft-ietf-dhc-subnet-option-02.txt 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 although it is probably useful to at least mention this issue in the security section. > -----Original Message----- > From: dhcp-v4@bucknell.edu [mailto:dhcp-v4@bucknell.edu]On Behalf Of Ted > Lemon > Sent: Thursday, June 17, 1999 00:20 > To: Multiple recipients of list > Subject: Re: I-D ACTION:draft-ietf-dhc-subnet-option-02.txt > > > > > 5. Security Considerations > > > > DHCP currently provides no authentication or security mechanisms. > > Potential exposures to attack are discussed is section 7 of the > > protocol specification [RFC2131]. > > > > does this not protocol not open up a new security risk, requesting on an > > arbitrary subnet? > > I'm not sure that the incremental risk is substantial. I suppose it > makes it possible for an address-pool exhaustion DoS attack to be more > complete, but other than that, what benefit do I obtain by acquiring > an IP address on a subnet to which I'm not connected? We already > have to deal with the address-pool exhaustion DoS attack, so I don't > see any reason to think of this as a significant new concern. > > _MelloN_ > > From dhcp-v4@bucknell.edu Thu Jun 17 10:14: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 KAA28264 for ; Thu, 17 Jun 1999 10:14:41 -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 KAA22288; Thu, 17 Jun 1999 10:07:09 -0400 (EDT) Date: Thu, 17 Jun 1999 10:07:09 -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: draft on the "Subnet Selection Option for DHCP" 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 > > the device would then cache those addresses and hand them out as it > > sees fit. > > Is caching lease data a good idea? Is this really the intended use? I'm > asking out of curiosity. It would seem to me that requesting leases on > an as-needed basis would be safer, at least from expiration or conflict > avoidance points of view. correct, caching is not necessary -- it is a design decision. the device must remember the allocated addresses and perform renews on those addresses as required by the DHCP protocol definition. > > i'm not sure how useful it is for a device getting multiple offers > > **potentially** from different subnets -- i would think that you want > > to specify precisely the subnet on which you want the address. > > I guess my concern is that in some scenarios the gateway device is not > entirely sure which subnet it should be making assignments from and > needs clues from the network to make the decision. the device must know which subnets it wants the addresses for. what it may not know is whether there is more than one subnet address for the network segment. but that's ok -- when required, the dhcp server will be configured with that information. > -- > Eric A. Hall ehall@ehsco.com > +1-650-685-0557 http://www.ehsco.com /gww From dhcp-v4@bucknell.edu Thu Jun 17 11:04: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 LAA29028 for ; Thu, 17 Jun 1999 11:04: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 KAA13453; Thu, 17 Jun 1999 10:56:36 -0400 (EDT) Date: Thu, 17 Jun 1999 10:56:36 -0400 (EDT) Message-Id: <199906171410.KAA02281@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: I-D ACTION:draft-ietf-dhc-subnet-option-02.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > although it is probably useful to at least mention this issue in the > security section. Definitely. _MelloN_ From dhcp-v4@bucknell.edu Thu Jun 17 12:00: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 MAA29720 for ; Thu, 17 Jun 1999 12:00: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 LAA29645; Thu, 17 Jun 1999 11:48:52 -0400 (EDT) Date: Thu, 17 Jun 1999 11:48:52 -0400 (EDT) Message-Id: <199906171519.LAA29484@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: kkinnear@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Kim Kinnear To: Multiple recipients of list Subject: RE: draft on the "Subnet Selection Option for 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.0.2 At 08:16 PM 6/16/99 -0400, Glenn Waters wrote: >the intent is that the device (the PPP server in your example) would get an >address on each of the subnets using separate DHCPDISCOVERs for each subnet. >the device would then cache those addresses and hand them out as it sees >fit. > >i'm not sure how useful it is for a device getting multiple offers >**potentially** from different subnets -- i would think that you want to >specify precisely the subnet on which you want the address. I completely agree. The case Eric discusses is where each server manages only one of the subnets in the multiple subnet list, but what if one server manages 2 or more of the subnets specified in the list. From which subnet does it return an offer? The first? The one with the most addresses? How about: if you want offers for different subnets, you send out different discovers with different subnet selection options in them. Thus the simple case remains simple, and the extra complexity burden is borne by the client that needs the extra capability. Just because we know of no such clients today doesn't mean that we shouldn't allow them to operate, but it *does* mean that we shouldn't burden the draft/RFC with complexity to optimize their operation. The approach outlined above will work fine for these clients should they ever exist. Cheers -- Kim > >/gww > >> -----Original Message----- >> From: dhcp-v4@bucknell.edu [mailto:dhcp-v4@bucknell.edu]On Behalf Of >> Eric A. Hall >> Sent: Wednesday, June 16, 1999 18:21 >> To: Multiple recipients of list >> Subject: Re: draft on the "Subnet Selection Option for DHCP" >> >> >> >> > does any of this multicast discussion have anything to do with the >> > draft listed in the subject line? >> >> Apologies for drifting. >> >> I do have a concern with the option as defined, which is that it does >> not provide a multi-valued array. It is feasible for a sending device >> (such as a PPP server) to have multiple subnets available for clients. >> Being able to seed the DHCPDISCOVER message with each of those subnets >> would seem to be an important characteristic. The gateway device may >> wish to get multiple OFFERS from multiple servers, each of which serve >> the unique subnets, and then choose a lease (or really, choose a subnet) >> for the client based on offerred data. >> >> Is this an oversight or is this a non-issue? >> >> -- >> Eric A. Hall ehall@ehsco.com >> +1-650-685-0557 http://www.ehsco.com >> >> > From dhcp-v4@bucknell.edu Thu Jun 17 13:40: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 NAA01081 for ; Thu, 17 Jun 1999 13:40:24 -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 NAA00158; Thu, 17 Jun 1999 13:29:09 -0400 (EDT) Date: Thu, 17 Jun 1999 13:29:09 -0400 (EDT) Message-Id: <4.1.19990617015759.00998100@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: draft on the "Subnet Selection Option for 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 Ted & Eric had this exchange: > >> (a) is pretty tractable - we could continue with the current system of >> using the 0.0.0.0 source address. > >Yeah. > >> (b) is hard, as you've pointed out. Because there's no relay agent, >> the client has to figure out to what network segment it's attached to >> before it sends its DHCP request, and before it has an IP address. > >Easily resolvable with an ICMP Subnet Query message. The real question >is whether or not the addition of a new secondary service is cost >effective when I'm trying to eliminate another secondary service. > > I was under the impression that the ICMP "Subnet Query Message" was obsolete. I realise though that what you may be suggesting is that it should be resurrected. (2010 seems about right). From dhcp-v4@bucknell.edu Thu Jun 17 15:05:11 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 PAA01888 for ; Thu, 17 Jun 1999 15:05:11 -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 OAA04412; Thu, 17 Jun 1999 14:58:06 -0400 (EDT) Date: Thu, 17 Jun 1999 14:58:06 -0400 (EDT) Message-Id: <37694365.C6DD5EE4@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: DHCP with multicasting relay agents... 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 > Sounds like a plan! When can we expect to see the draft? Since the proposed mechanism is very constrained and therefore very simple, there isn't a lot that needs to be done. Essentially, the proposal boils down to: * Forwarders SHOULD be configurable to relay requests to the multicast group address of X.X.X.X. * Servers SHOULD be configurable to listen for requests on the multicast group address of X.X.X.X. With Ted's prooposal, nothing else changes anywhere in the spec. I'm wondering if instead of writing a new spec we could just modify the existing DHCP spec? These two changes would be optional, and would not require changes to any existing implementations. The cumulative amount of text would be fairly small, maybe along the lines of six paragraphs altogether. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Thu Jun 17 16:07:51 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 QAA02211 for ; Thu, 17 Jun 1999 16:07: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 QAA06526; Thu, 17 Jun 1999 16:01:42 -0400 (EDT) Date: Thu, 17 Jun 1999 16:01:42 -0400 (EDT) Message-Id: <199906171916.PAA01244@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: I-D ACTION:draft-ietf-dhc-subnet-option-02.txt (Fwd) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > what benefit does the attacker obtain in any dos attack? None whatsoever, other than the sick satisfaction of having caused harm. > is there harm in acknowledging it as a security issue? Not at all. I'm sorry I was so careless as to imply that it shouldn't be mentioned (I definitely do seem to have implied that, and that was not my intention). I'm still feeling a little jumpy after the bloodbath over the relay agent information option at the last working group meeting, so I worded my response more strongly than I should have. Sigh. _MelloN_ From dhcp-v4@bucknell.edu Thu Jun 17 16:08:06 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 QAA02222 for ; Thu, 17 Jun 1999 16:08: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 QAA22866; Thu, 17 Jun 1999 16:03:02 -0400 (EDT) Date: Thu, 17 Jun 1999 16:03:02 -0400 (EDT) Message-Id: <37694C78.5144295E@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: DHCP with multicasting relay agents... 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 > I think it's worth specifying this is a seperate draft, so as to not > confuse the progression of the existing draft, and also so as to > highlight the fact that this is new functionality. Okay. > I think your six paragraph estimate is a tad low, but not by more > than a factor of two or so Given the room a separate document affords, you are probably right. There isn't a whole lot of stuff here though. The only details are things like "relay agent SHOULD NOT join the multicast group (only send to it)" and some TTL issues. > if you don't have time to write the draft, somebody else here > probably can. I may have some free time to do this and some other > small drafts that need to be written up soon... :') I don't mind writing it, but I wouldn't mind NOT writing it either. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Thu Jun 17 16:08: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 QAA02233 for ; Thu, 17 Jun 1999 16:08: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 QAA01094; Thu, 17 Jun 1999 16:02:27 -0400 (EDT) Date: Thu, 17 Jun 1999 16:02:27 -0400 (EDT) Message-Id: <199906171920.PAA01264@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: DHCP with multicasting relay agents... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 I think it's worth specifying this is a seperate draft, so as to not confuse the progression of the existing draft, and also so as to highlight the fact that this is new functionality. I think your six paragraph estimate is a tad low, but not by more than a factor of two or so - remember that when I first tried to explain to you what I had in mind, you thought I meant something else, and we need to communicate to readers who have much less of a history with IP networking than you do. It shouldn't be very hard to get a draft like this through, though (although maybe Thomas can comment on that further). I believe there is a boilerplate for writing these drafts now, so it shouldn't be too hard. However, fundamentally I was just tweaking you - if you don't have time to write the draft, somebody else here probably can. I may have some free time to do this and some other small drafts that need to be written up soon... :') _MelloN_ From dhcp-v4@bucknell.edu Thu Jun 17 16:59: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 QAA02607 for ; Thu, 17 Jun 1999 16:59: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 QAA10187; Thu, 17 Jun 1999 16:51:28 -0400 (EDT) Date: Thu, 17 Jun 1999 16:51:28 -0400 (EDT) Message-Id: <4.1.19990617134943.00a46300@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: Subnet Selection Option Draft 02 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 If I could just risk raising my head above the parapet and risk having it blown off by all this exploding multicast ordnance... I wondered if this draft could use some words of explanation about the conditions under which a DHCP server's reply will reach the client. If giaddr is set, then the router configured with that giaddr must know how to route to the subnet implied by the subnet selection option. This is likely, and perhaps not controversial. But when giaddr is not set (so the "proxy" is on the same segment as the server) the server is going to try and unicast to the Ip address on the subnet-selected, presumably by attempting to add an entry to its own ARP table. But that isn't going to work, because ARP caches know that they are only supposed to have IP's in them which are directly reachable. The solution might be to force the server to broadcast, as it would with the Broadcast-bit set. Also, when the proxy renews the address the server will try a simple unicast, independant of giaddr (which ought to be zero on a real renewal). At some point a router will ARP for the IP address being renewed. Is the "control plane" of the entity in question going to respond to that ARP? I realise the words "proxy" haven't been used in the draft, but I still think these points should be addressed. Rob Stevens From dhcp-v4@bucknell.edu Thu Jun 17 17:47: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 RAA03136 for ; Thu, 17 Jun 1999 17:47: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 RAA15909; Thu, 17 Jun 1999 17:42:29 -0400 (EDT) Date: Thu, 17 Jun 1999 17:42:29 -0400 (EDT) Message-Id: <199906172108.RAA12581@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: kkinnear@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Kim Kinnear To: Multiple recipients of list Subject: Re: Subnet Selection Option Draft 02 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.2 At 04:51 PM 6/17/99 -0400, Rob Stevens wrote: >If I could just risk raising my head above the parapet >and risk having it blown off by all this exploding multicast ordnance... > >I wondered if this draft could use some words of >explanation about the conditions under which a >DHCP server's reply will reach the client. > >If giaddr is set, then the router configured with that >giaddr must know how to route to the subnet >implied by the subnet selection option. >This is likely, and perhaps not controversial. > >But when giaddr is not set (so the "proxy" is >on the same segment as the server) the >server is going to try and unicast to the >Ip address on the subnet-selected, >presumably by attempting to add an >entry to its own ARP table. But that >isn't going to work, because ARP caches >know that they are only supposed to have >IP's in them which are directly reachable. >The solution might be to force the server >to broadcast, as it would with the >Broadcast-bit set. > >Also, when the proxy renews the address >the server will try a simple unicast, independant >of giaddr (which ought to be zero on a real renewal). Ah, but it *could* be set, as for a rebinding, and that is what we should probably recommend, I'd say. Cheers -- Kim >At some point a router will ARP for the IP address >being renewed. Is the "control plane" of the entity >in question going to respond to that ARP? > >I realise the words "proxy" haven't been used in the >draft, but I still think these points should be addressed. > >Rob Stevens > From dhcp-v4@bucknell.edu Thu Jun 17 17:48:00 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 RAA03147 for ; Thu, 17 Jun 1999 17:47: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 RAA15497; Thu, 17 Jun 1999 17:41:31 -0400 (EDT) Date: Thu, 17 Jun 1999 17:41:31 -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: I-D ACTION:draft-ietf-dhc-subnet-option-02.txt (Fwd) 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 i have put some words about this security issue in the next draft. the new version will be submitted before the cutoff. /gww > -----Original Message----- > From: dhcp-v4@bucknell.edu [mailto:dhcp-v4@bucknell.edu]On Behalf Of Ted > Lemon > Sent: Thursday, June 17, 1999 16:02 > To: Multiple recipients of list > Subject: Re: I-D ACTION:draft-ietf-dhc-subnet-option-02.txt (Fwd) > > > > > what benefit does the attacker obtain in any dos attack? > > None whatsoever, other than the sick satisfaction of having caused > harm. > > > is there harm in acknowledging it as a security issue? > > Not at all. I'm sorry I was so careless as to imply that it > shouldn't be mentioned (I definitely do seem to have implied that, and > that was not my intention). I'm still feeling a little jumpy after > the bloodbath over the relay agent information option at the last > working group meeting, so I worded my response more strongly than I > should have. Sigh. > > _MelloN_ > > From dhcp-v4@bucknell.edu Thu Jun 17 21:58:36 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 VAA05153 for ; Thu, 17 Jun 1999 21:58: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 VAA22067; Thu, 17 Jun 1999 21:54:44 -0400 (EDT) Date: Thu, 17 Jun 1999 21:54:44 -0400 (EDT) Message-Id: <199906180142.VAA17723@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 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 MAURO_CARRERA@IT.ARVIN.COM follows. --------------------------------------------------------------------------- I am Mauro from Asti ITALIA. I work for a firm ( Arvin S.S.I ) that use Microsoft products (NT 4.0 SERVER, CLIENT SP4 & W95) I want to know if is possible to set TIME of client by DHCP protocol on every login. I have use Time Server 004 TCP-IP service (activate) but doesn't work than at the moment I use in the login script the command NET TIME \\name hosts /set..... Is possible make this by DHCP and than is possible to have some notice? Tanks and best Regards. From dhcp-v4@bucknell.edu Thu Jun 17 22:35: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 WAA06201 for ; Thu, 17 Jun 1999 22:35: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 WAA15329; Thu, 17 Jun 1999 22:31:19 -0400 (EDT) Date: Thu, 17 Jun 1999 22:31:19 -0400 (EDT) Message-Id: <3769A862.A049DB0E@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: 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 there not a DHCP-Interest list for these kinds of questions? "by way of Ralph Droms " wrote: > > message sent to dhcp-v4@bucknell.edu by MAURO_CARRERA@IT.ARVIN.COM follows. > --------------------------------------------------------------------------- > I am Mauro from Asti ITALIA. > > I work for a firm ( Arvin S.S.I ) that use Microsoft products (NT 4.0 > SERVER, CLIENT SP4 & W95) > I want to know if is possible to set TIME of client by DHCP protocol on > every login. > I have use Time Server 004 TCP-IP service (activate) but doesn't work than > at the moment I use in the login script the command NET TIME \\name hosts > /set..... > Is possible make this by DHCP and than is possible to have some notice? > > Tanks and best Regards. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Thu Jun 17 22:35: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 WAA06212 for ; Thu, 17 Jun 1999 22:35: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 WAA16467; Thu, 17 Jun 1999 22:32:53 -0400 (EDT) Date: Thu, 17 Jun 1999 22:32:53 -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: I-D ACTION:draft-ietf-dhc-subnet-option-02.txt (Fwd) 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 RANDY@PSG.COM follows. -------------------------------------------------------------- Erik, > Did you see these responses? nope > I guess it is an attribute of the mail filters that you don't > show up as the sender causing responses to only go to the list. most likely broken list software which forces Reply-To: listname Ted Lemon > 5. Security Considerations >> >> DHCP currently provides no authentication or security mechanisms. >> Potential exposures to attack are discussed is section 7 of the >> protocol specification [RFC2131]. >> >> does this not protocol not open up a new security risk, requesting on an >> arbitrary subnet? > > I'm not sure that the incremental risk is substantial. I suppose it > makes it possible for an address-pool exhaustion DoS attack to be more > complete, but other than that, what benefit do I obtain by acquiring > an IP address on a subnet to which I'm not connected? what benefit does the attacker obtain in any dos attack? > We already have to deal with the address-pool exhaustion DoS attack, > so I don't see any reason to think of this as a significant new > concern. is there harm in acknowledging it as a security issue? Glenn Waters > although it is probably useful to at least mention this issue in the > security section. thank you. that's all i was trying to say. randy From dhcp-v4@bucknell.edu Thu Jun 17 22:36:00 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 WAA06223 for ; Thu, 17 Jun 1999 22:35: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 WAA29923; Thu, 17 Jun 1999 22:32:12 -0400 (EDT) Date: Thu, 17 Jun 1999 22:32:12 -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: I-D ACTION:draft-ietf-dhc-subnet-option-02.txt (Fwd) 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. ---------------------------------------------------------------------------- > > what benefit does the attacker obtain in any dos attack? > > None whatsoever, other than the sick satisfaction of having caused > harm. Actually, Denial of Service attacks can be used as one stage in a multi-stage attack. As an example, many TCP-based attacks are easier the real host being impersonated/spoofed is out of the picture and can't send RST's to confuse the issue.. - Bill From dhcp-v4@bucknell.edu Fri Jun 18 08:02:51 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 IAA21825 for ; Fri, 18 Jun 1999 08:02: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 HAA25629; Fri, 18 Jun 1999 07:56:00 -0400 (EDT) Date: Fri, 18 Jun 1999 07:56:00 -0400 (EDT) Message-Id: <4.1.19990618053122.00a36a10@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: Questions pertaining to a particular vendor's products 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 At 10:31 PM 6/17/99 -0400, Eric Hall wrote: > >Is there not a DHCP-Interest list for these kinds of questions? > > I agree with this sentiment. Questions about a particular vendor's products, should surely not appear in this newsgroup. I would except the ISC and other freely available software as being generally for the public good, and other questions directed at a particular vendor which have a direct bearing on some question of widespread de facto usage, which are relevant to evolvement of the protocol. From dhcp-v4@bucknell.edu Fri Jun 18 11:43: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 LAA25068 for ; Fri, 18 Jun 1999 11:43: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 LAA04541; Fri, 18 Jun 1999 11:36:29 -0400 (EDT) Date: Fri, 18 Jun 1999 11:36:29 -0400 (EDT) Message-Id: <199906181535.LAA13835@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: 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 10:32 PM 6/17/99 -0400, Eric A. Hall wrote: > >Is there not a DHCP-Interest list for these kinds of questions? Well, not exactly. There might be a place w/in Microsoft or a newsgroup somewhere for Microsoft-specific questions. I took the question a little more broadly as possibly a question about the Windows DHCP client that might be of general interest. Specifically, will the Windows client accept and will the Windows stack then use a "time server" option? If so, which one - RFC 868 [6] time server (option code 4) or NTP server (option code 42)? According to the information I have, the Windows DHCP client does not use either option 4 or option 42. - Ralph From dhcp-v4@bucknell.edu Fri Jun 18 12:53: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 MAA26317 for ; Fri, 18 Jun 1999 12:53: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 MAA15334; Fri, 18 Jun 1999 12:48:08 -0400 (EDT) Date: Fri, 18 Jun 1999 12:48:08 -0400 (EDT) Message-Id: <376A69AF.E8D077FB@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: 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 > more broadly as possibly a question about the Windows DHCP client that > might be of general interest. Probably so, but for a DHCP-Interest list is my feeling. > Specifically, will the Windows client accept and will the Windows stack > then use a "time server" option? Use it with what? They don't have an NTP client or anything in the currently shipping products, and there isn't any way of passing this option data to an external client (except with NT registry extension). Future releases of one of their platforms may or may not fix either or both of these issues. The original questioner will have to either (A) stick with NET TIME or (B) use an aftermarket NTP client which will not be configurable via BOOTP/DHCP without renewing the lease independently (of which there are none that I am aware of). -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Fri Jun 18 12:53: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 MAA26329 for ; Fri, 18 Jun 1999 12:53: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 MAA21655; Fri, 18 Jun 1999 12:46:41 -0400 (EDT) Date: Fri, 18 Jun 1999 12:46:41 -0400 (EDT) Message-Id: <199906181535.LAA04435@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: Questions pertaining to a particular vendor's products X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 We do actually get a reasonable number of general protocol questions on the ISC DHCP mailing lists, and generally try to answer them to the best of our ability. It's perfectly acceptable to refer people to the ISC mailing lists. I don't know if it's likely that there would be another free mailing list besides the WG mailing list on which there'd be people technically literate enough to answer questions like this. The ISC would be very happy to set up a dhcp-interest mailing list for this purpose, however, if there'd be some interest here in people who'd subscribe to it so that questions like this could be answered. FWIW, I sent an answer to the guy who asked this particular question... _MelloN_ From dhcp-v4@bucknell.edu Fri Jun 18 13:36: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 NAA27113 for ; Fri, 18 Jun 1999 13:36: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 NAA07560; Fri, 18 Jun 1999 13:31:09 -0400 (EDT) Date: Fri, 18 Jun 1999 13:31:09 -0400 (EDT) Message-Id: <199906181653.MAA26797@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: I-D ACTION:draft-ietf-dhc-authentication-10.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 : Authentication for DHCP Messages Author(s) : R. Droms, W. Arbaugh Filename : draft-ietf-dhc-authentication-10.txt Pages : 15 Date : 17-Jun-99 The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. In some situations, network administrators may wish to constrain the allocation of addresses to authorized hosts. Additionally, some network administrators may wish to provide for authentication of the source and contents of DHCP messages. This document defines a new DHCP option through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-authentication-10.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-authentication-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-authentication-10.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: <19990617123611.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-authentication-10.txt From dhcp-v4@bucknell.edu Fri Jun 18 13:36: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 NAA27131 for ; Fri, 18 Jun 1999 13:36: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 NAA30660; Fri, 18 Jun 1999 13:32:06 -0400 (EDT) Date: Fri, 18 Jun 1999 13:32:06 -0400 (EDT) Message-Id: <199906181658.MAA04914@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: X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > The original questioner will have to either (A) stick with NET TIME or > (B) use an aftermarket NTP client which will not be configurable via > BOOTP/DHCP without renewing the lease independently (of which there are > none that I am aware of). Right, and it's probably easier to just answer the question than to refer them elsewhere... :') _MelloN_ From dhcp-v4@bucknell.edu Fri Jun 18 14:19: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 OAA28081 for ; Fri, 18 Jun 1999 14:19: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 OAA13594; Fri, 18 Jun 1999 14:14:33 -0400 (EDT) Date: Fri, 18 Jun 1999 14:14:33 -0400 (EDT) Message-Id: <199906181814.OAA13594@mail.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: Donna.Maciolek@kp.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Donna Maciolek To: Multiple recipients of list Subject: Re: Questions pertaining to a particular vendor's products X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 I sent a message to this list a while back to ask a question about a DHCP vendor option on NetID (We think this is what is causing the "option of unknown length" DHCP error we get when we are sent ACKs from NetID.) I got a couple answers to check TechNet and ignored :) (I HAD checked TechNet but we were interested in asking the experts, you guys, since TechNet had no relavent information.... ) I did like others, did a search on the web, found the IETF site, and here I found you guys. I still subscribe to your list because it is interesting and I am learning from it, but it would be great to have a place where us "normal" humans in the field, and interested in DHCP, or having a DHCP problem, could ask questions. I learned, and other than this will not post my ignorance in public, but will sit and read and learn... There must be others here like me though and will be more to come... dm ---------------------- Forwarded by Donna Maciolek/CA/KAIPERM on 06/18/99 10:04 AM --------------------------- mellon@isc.org on 06/18/99 09:50:00 AM To: dhcp-v4@bucknell.edu@Internet cc: (bcc: Donna Maciolek/CA/KAIPERM) Subject: Re: Questions pertaining to a particular vendor's products We do actually get a reasonable number of general protocol questions on the ISC DHCP mailing lists, and generally try to answer them to the best of our ability. It's perfectly acceptable to refer people to the ISC mailing lists. I don't know if it's likely that there would be another free mailing list besides the WG mailing list on which there'd be people technically literate enough to answer questions like this. The ISC would be very happy to set up a dhcp-interest mailing list for this purpose, however, if there'd be some interest here in people who'd subscribe to it so that questions like this could be answered. FWIW, I sent an answer to the guy who asked this particular question... _MelloN_ From dhcp-v4@bucknell.edu Fri Jun 18 14:59: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 OAA28613 for ; Fri, 18 Jun 1999 14:59: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 OAA03455; Fri, 18 Jun 1999 14:55:26 -0400 (EDT) Date: Fri, 18 Jun 1999 14:55:26 -0400 (EDT) Message-Id: <376A8FAE.A278AE45@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: Questions pertaining to a particular vendor's products 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 > but it would be great to have a place where us "normal" humans in the > field, and interested in DHCP, or having a DHCP problem, could ask > questions. > There must be others here like me though and will be more to come... It would be nice if you had a place to go explicitly designed to help you resolve your problems, and where you could help others as well. I believe that this purpose would be best served with a DHCP-Interest list. If ISC is willing to host it, I am willing to read it and do my best to help. I don't feel like this list is the best place for these questions though, for the simple reason that not that many people read it. A lot more people (including more end-users hopefully) would probably read a general DHCP-Interest list if such an animal existed and were made known to the general public. Maybe vendors can post links on their sites? I also strongly believe that more end-users should get involved in the IETF process in particular, which means subscribing to the dev lists and making your desires, wishes and problems known. Most end-users only lurk, which doesn't really count. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Sun Jun 20 21:54: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 VAA16677 for ; Sun, 20 Jun 1999 21:54: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 VAA14146; Sun, 20 Jun 1999 21:49:05 -0400 (EDT) Date: Sun, 20 Jun 1999 21:49:05 -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: DHCP with multicasting relay agents... 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 11:38 PM 6/16/99 -0400, Ted Lemon wrote: >The function it would provide would be that you'd have a relay agent >in each router, just like you do now, but instead of having to >configure each relay agent with a list of DHCP servers to which to >forward packets, you would simply have the relay agent forward all >client DHCP packets to a well-known, routed multicast address. The >protocol would otherwise be unchanged - the relay agent would still >stuff giaddr, and the server would still unicast the response to the >relay agent, which would either broadcast or unicast it to the client >on the local network. Using multi-cast in this way is, in fact, exactly how DHCPv6 works. DHCPv6, in fact, specifies *only* the use of multicast by relay agents for forwarding DHCP messages; there is no mention of configured unicast direct to DHCP servers. You raise an interesting point that is not currently discussed in the DHCPv6 draft - the relay agents should transmit to (but not join) the DHCP servers multicast address. Changing contexts back to DHCPv4, I'm not sure that using multicast would in any way change the protocol, per se. My first thought was that the multicast mechanism might only require a short informational RFC. After thinking a little harder, seems like we ought to get an address from IANA and then write a standards track RFC documenting the use of that address and any specific details. Does anyone have operational experience with the use of multicast by relay agents? We did originally consider the use of multicast in DHCPv4 but decided against it because it was not widely deployed or available when we originally decvised the protocol. - Ralph From dhcp-v4@bucknell.edu Mon Jun 21 04:54: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 EAA02528 for ; Mon, 21 Jun 1999 04:54: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 EAA24553; Mon, 21 Jun 1999 04:48:59 -0400 (EDT) Date: Mon, 21 Jun 1999 04:48:59 -0400 (EDT) Message-Id: <376DF492.B0ED20D@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: DHCP with multicasting relay agents... 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 > Changing contexts back to DHCPv4, I'm not sure that using multicast > would in any way change the protocol, per se. It wouldn't. > After thinking a little harder, seems like we ought to get an address > from IANA and then write a standards track RFC documenting the use of > that address and any specific details. I asked IANA for a Class D address last week, and am writing a draft that Ted will implement based on our conversations. If it works (and it should) we'll turn it over for further process. If this is bad form somebody let me know. I don't see any reason it can't go into the main proto, unless there are timing concerns or other issues outside of the proto itself. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Mon Jun 21 07:48: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 HAA03299 for ; Mon, 21 Jun 1999 07:48: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 HAA31879; Mon, 21 Jun 1999 07:39:10 -0400 (EDT) Date: Mon, 21 Jun 1999 07:39:10 -0400 (EDT) Message-Id: <199906211111.HAA09668@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: DHCP with multicasting relay agents... 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 04:49 AM 6/21/99 -0400, Eric A. Hall wrote: >I asked IANA for a Class D address last week, and am writing a draft >that Ted will implement based on our conversations. If it works (and it >should) we'll turn it over for further process. If this is bad form >somebody let me know. Sounds like good form to me. Thanks for taking the initiative to formalize the multicast mechanism. >I don't see any reason it can't go into the main proto, unless there are >timing concerns or other issues outside of the proto itself. Eventually, the use of multicast should be documented in the main protocol spec. Until we republish the spec as a new RFC - which probably won't happen until the spec goes to Full Standard - it would be best to publish the multicast doc as a separate RFC. - Ralph From dhcp-v4@bucknell.edu Mon Jun 21 09:00:14 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 JAA03706 for ; Mon, 21 Jun 1999 09:00:13 -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 IAA29608; Mon, 21 Jun 1999 08:52:44 -0400 (EDT) Date: Mon, 21 Jun 1999 08:52:44 -0400 (EDT) Message-Id: <376E35FA.34E753D@germany.sun.com> Errors-To: droms@bucknell.edu Reply-To: Erik.Guttman@germany.sun.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Erik Guttman To: Multiple recipients of list Subject: Re: DHCP with multicasting relay agents... 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] (X11; I; SunOS 5.5.1 sun4m) Content-Transfer-Encoding: 7bit "Eric A. Hall" wrote: > > I asked IANA for a Class D address last week, and am writing a draft > that Ted will implement based on our conversations. If it works (and it > should) we'll turn it over for further process. If this is bad form > somebody let me know. Eric, Is a global multicast address really what we want? I would think that an administratively scoped multicast address would be more appropriate. There are two possibilities here: One is to require the use of MADCAP to allocate and discover the multicast address dynamicly. The other, probably more desirable, is to request an assignment of a fixed multicast address from IANA in the administrative multicast range. RFC 2365: 9. Structure and Use of a Scoped Region The high order /24 in every scoped region is reserved for relative assignments. A relative assignment is an integer offset from highest address in the scope and represents a 32-bit address (for IPv4). For example, in the Local Scope defined above, 239.255.255.0/24 is reserved for relative allocations. The de-facto relative assignment "0", (i.e., 239.255.255.255 in the Local Scope) currently exists for SAP [SAP]. The next relative assignment, "1", corresponds to the address 239.255.255.254 in the Local Scope. The rest of a scoped region below the reserved /24 is available for dynamic assignment (presumably by an address allocation protocol). There are only 255 such relative address assignments available, and only for fundamental discovery/configuration protocols - which clearly describes DHCP. The process is to make an application to IANA for one of these protocols carefully describing that it is to be a "relative assignment for use with administrative scoped multicast addresses" & cite RFC 2365, section 9. The reason you *don't* want a global multicast address is there is no case I can imagine where you'd want these messages being routed outside of the periphery of an administered network, ie. into the global Internet. Erik From dhcp-v4@bucknell.edu Mon Jun 21 09:41:15 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 JAA03969 for ; Mon, 21 Jun 1999 09:41: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 JAA14142; Mon, 21 Jun 1999 09:33:36 -0400 (EDT) Date: Mon, 21 Jun 1999 09:33:36 -0400 (EDT) Message-Id: <199906211310.JAA16554@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: DHCP with multicasting relay agents... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Excellent. I thought there was a way to do this. This solves the TTL problem quite nicely. _MelloN_ From dhcp-v4@bucknell.edu Mon Jun 21 18:57:31 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 SAA11927 for ; Mon, 21 Jun 1999 18:57:30 -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 SAA09182; Mon, 21 Jun 1999 18:44:50 -0400 (EDT) Date: Mon, 21 Jun 1999 18:44:50 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: ndlane@wal-mart.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Nathan Lane To: Multiple recipients of list Subject: RE: DHCP with multicasting relay agents... 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 > With Ted's prooposal, nothing else changes anywhere in the spec. > > I'm wondering if instead of writing a new spec we could just modify the > existing DHCP spec? These two changes would be optional, and would not > require changes to any existing implementations. > [Nathan Lane] Sounds good...but we don't have a multicast infrastructure. I have a pretty simple solution to at least the discover part of the protocol - all my boot servers for networks that need relay agents are on a single segment and the relay agents are configured to send the DHCPDISCOVERS/bootp requests to the broadcast address on that segment. It doesn't solve all the problems but it covers 99% of all outage cases at our sites: DHCP server dead or unresponsive. If I had a multicast infrastructure, that'd be even better from an agent configuration perspective. > -Nathan Lane Senior Network Engineer Wal-Mart Stores, Inc. (501) 277-5786 > From dhcp-v4@bucknell.edu Tue Jun 22 07:13: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 HAA01571 for ; Tue, 22 Jun 1999 07:13: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 HAA29306; Tue, 22 Jun 1999 07:05:31 -0400 (EDT) Date: Tue, 22 Jun 1999 07:05:31 -0400 (EDT) Message-Id: <199906221700.OAA20895@sun1.ksu.edu.sa> Errors-To: droms@bucknell.edu Reply-To: umit@ksu.edu.sa Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Umit Dericioglu To: Multiple recipients of list Subject: DHCP problem X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii Mime-Version: 1.0 Hello, We have a big flat university LAN here. Most of the clients are running Win 95 or Win NT. Our DHCP server is a Win NT 4.0 with service pack 3. Last few days, the clients have been failing to get the IP addr, etc from the DHCP server. Everytime we try to renew the lease on a Win95 (or NT client), "Access denied" message is displayed. As for the DHCP server, we believe it is working fine as there are no error messages and it seems to serve fine as the "Active leases" display shows around 2000 addresses leased with more than 25% of address space still unused. Besides, we've set up another NT box as the DHCP server, after stopping the first one. The problem is the same. Then, we stopped that one too, to see if there is another unauthorized DHCP server somewhere in the network, causing the trouble. There is none. The clients display "DHCP server unavailable" during the renewal of lease when all DHCP servers are down. We've also watched the packets. We could not find any unusual activity. Has anybody faced a similar problem? Or any suggestion where to look as a possible cause? Any hint will be greatly appreciated. This problem is driving us crazy.. Umit Dericioglu King Saud University Riyadh From dhcp-v4@bucknell.edu Tue Jun 22 08:46:28 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 IAA03112 for ; Tue, 22 Jun 1999 08:46: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 IAA20183; Tue, 22 Jun 1999 08:17:35 -0400 (EDT) Date: Tue, 22 Jun 1999 08:17:35 -0400 (EDT) Message-Id: <199906221208.IAA21575@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: DHCP problem X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Setting up a second DHCP server may not have been a good idea, unless you were careful to assign each DHCP server seperate address ranges from which to allocate IP addresses. The symptoms you describe actually suggest that somebody has set up a DHCP server on your network without your knowledge, and that that DHCP server is sending DHCPNAK messages to DHCP clients when they receive IP addresses from the DHCP server. If there is a rogue DHCP server, you can probably find it using a network sniffer (e.g., tcpdump). The ISC DHCP client can also be used, since it prints meaningful log messages describing what's happening, rather than sanitized dialog boxes that just tell you something went wrong. You'll need a Unix, BSD or Linux system on which to run the ISC DHCP client or tcpdump. _MelloN_ From dhcp-v4@bucknell.edu Tue Jun 22 13:56: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 NAA10954 for ; Tue, 22 Jun 1999 13:56: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 NAA21472; Tue, 22 Jun 1999 13:48:55 -0400 (EDT) Date: Tue, 22 Jun 1999 13:48:55 -0400 (EDT) Message-Id: <376FC588.4548EEA3@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: DHCP with multicasting relay agents... 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 > > I asked IANA for a Class D address last week > Is a global multicast address really what we want? I would think that > an administratively scoped multicast address would be more > appropriate. > There are only 255 such relative address assignments available, and > only for fundamental discovery/configuration protocols - which clearly > describes DHCP. Looking at IANA's list of currently defined administratively scoped addresses shows the following: Relative Description Reference --------- -------------------------------------------- --------- 1 MDHCP Protocol [Patel] Apparently a DHCP group address is already there. I'm assuming this is the v6 group address. I wonder if we can share this group address, and what the ramifications would be from a protocol perspective. Any thoughts from anybody who knows? -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Tue Jun 22 13: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 NAA10970 for ; Tue, 22 Jun 1999 13: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 NAA03497; Tue, 22 Jun 1999 13:53:50 -0400 (EDT) Date: Tue, 22 Jun 1999 13:53:50 -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: Subnet Selection Option Draft 02 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 > -----Original Message----- > From: dhcp-v4@bucknell.edu [mailto:dhcp-v4@bucknell.edu]On Behalf Of Kim > Kinnear > Sent: Thursday, June 17, 1999 17:43 > To: Multiple recipients of list > Subject: Re: Subnet Selection Option Draft 02 > > > At 04:51 PM 6/17/99 -0400, Rob Stevens wrote: > >If I could just risk raising my head above the parapet > >and risk having it blown off by all this exploding multicast ordnance... > > > >I wondered if this draft could use some words of > >explanation about the conditions under which a > >DHCP server's reply will reach the client. > > > >If giaddr is set, then the router configured with that > >giaddr must know how to route to the subnet > >implied by the subnet selection option. > >This is likely, and perhaps not controversial. > > > >But when giaddr is not set (so the "proxy" is > >on the same segment as the server) the > >server is going to try and unicast to the > >Ip address on the subnet-selected, > >presumably by attempting to add an > >entry to its own ARP table. But that > >isn't going to work, because ARP caches > >know that they are only supposed to have > >IP's in them which are directly reachable. > >The solution might be to force the server > >to broadcast, as it would with the > >Broadcast-bit set. > > > >Also, when the proxy renews the address > >the server will try a simple unicast, independant > >of giaddr (which ought to be zero on a real renewal). > > Ah, but it *could* be set, as for a > rebinding, and that is what we should probably > recommend, I'd say. could you clarify which you meant when you said "could be set", the broadcast bit or the giaddr? i believe we need to say that the giaddr needs to be set. > Cheers -- Kim > > >At some point a router will ARP for the IP address > >being renewed. Is the "control plane" of the entity > >in question going to respond to that ARP? > > > >I realise the words "proxy" haven't been used in the > >draft, but I still think these points should be addressed. > > > >Rob Stevens > > > > From dhcp-v4@bucknell.edu Tue Jun 22 14:55: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 OAA13211 for ; Tue, 22 Jun 1999 14:55:21 -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 OAA19715; Tue, 22 Jun 1999 14:50:51 -0400 (EDT) Date: Tue, 22 Jun 1999 14:50:51 -0400 (EDT) Message-Id: <199906221817.OAA23297@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: DHCP with multicasting relay agents... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > 1 MDHCP Protocol [Patel] > > Apparently a DHCP group address is already there. I'm assuming this is > the v6 group address. I wonder if we can share this group address, and > what the ramifications would be from a protocol perspective. Any > thoughts from anybody who knows? No, this is the Multicast Allocation group, which was formerly known as MDHCP. It actually has nothing to do with DHCP. We'll need address number 2, I guess. :') _MelloN_ From dhcp-v4@bucknell.edu Tue Jun 22 14:55: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 OAA13222 for ; Tue, 22 Jun 1999 14:55:24 -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 OAA15880; Tue, 22 Jun 1999 14:51:38 -0400 (EDT) Date: Tue, 22 Jun 1999 14:51:38 -0400 (EDT) Message-Id: <376FD589.8CE84177@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: DHCP with multicasting relay agents... 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 I resubmitted the request, explicitly asking for a relative address. I also asked that IANA update the existing MDHCP entry to be MADCAP. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Tue Jun 22 14:55: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 OAA13234 for ; Tue, 22 Jun 1999 14:55: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 OAA27687; Tue, 22 Jun 1999 14:50:20 -0400 (EDT) Date: Tue, 22 Jun 1999 14:50:20 -0400 (EDT) Message-Id: <199906221814.OAA24283@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: DHCP with multicasting relay agents... 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 01:53 PM 6/22/99 -0400, Eric A. Hall wrote: >Looking at IANA's list of currently defined administratively scoped >addresses shows the following: > > Relative Description Reference > --------- -------------------------------------------- --------- > 1 MDHCP Protocol [Patel] This address was allocated for a (now defunct) proposal for a service to allocate multicast addresses via DHCP or a DHCP-like protocol. It has nothing to do with either DHCPv4 or DHCPv6. We'll need a different administratively scoped address for DHCP relay agents. - Ralph From dhcp-v4@bucknell.edu Tue Jun 22 14:56:00 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 OAA13245 for ; Tue, 22 Jun 1999 14:55: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 OAA23639; Tue, 22 Jun 1999 14:49:35 -0400 (EDT) Date: Tue, 22 Jun 1999 14:49:35 -0400 (EDT) Message-Id: <199906221800.OAA01450@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: kkinnear@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Kim Kinnear To: Multiple recipients of list Subject: RE: Subnet Selection Option Draft 02 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.2 At 01:19 PM 6/22/99 -0400, Glenn Waters wrote: > > >> -----Original Message----- >> From: dhcp-v4@bucknell.edu [mailto:dhcp-v4@bucknell.edu]On Behalf Of Kim >> Kinnear >> Sent: Thursday, June 17, 1999 17:43 >> To: Multiple recipients of list >> Subject: Re: Subnet Selection Option Draft 02 >> >> >> At 04:51 PM 6/17/99 -0400, Rob Stevens wrote: >> >If I could just risk raising my head above the parapet >> >and risk having it blown off by all this exploding multicast ordnance... >> > >> >I wondered if this draft could use some words of >> >explanation about the conditions under which a >> >DHCP server's reply will reach the client. >> > >> >If giaddr is set, then the router configured with that >> >giaddr must know how to route to the subnet >> >implied by the subnet selection option. >> >This is likely, and perhaps not controversial. >> > >> >But when giaddr is not set (so the "proxy" is >> >on the same segment as the server) the >> >server is going to try and unicast to the >> >Ip address on the subnet-selected, >> >presumably by attempting to add an >> >entry to its own ARP table. But that >> >isn't going to work, because ARP caches >> >know that they are only supposed to have >> >IP's in them which are directly reachable. >> >The solution might be to force the server >> >to broadcast, as it would with the >> >Broadcast-bit set. >> > >> >Also, when the proxy renews the address >> >the server will try a simple unicast, independant >> >of giaddr (which ought to be zero on a real renewal). >> >> Ah, but it *could* be set, as for a >> rebinding, and that is what we should probably >> recommend, I'd say. > >could you clarify which you meant when you said "could be set", the >broadcast bit or the giaddr? > >i believe we need to say that the giaddr needs to be set. Yes, I meant the giaddr, and I agree with you. Kim > >> Cheers -- Kim >> >> >At some point a router will ARP for the IP address >> >being renewed. Is the "control plane" of the entity >> >in question going to respond to that ARP? >> > >> >I realise the words "proxy" haven't been used in the >> >draft, but I still think these points should be addressed. >> > >> >Rob Stevens >> > >> >> > From dhcp-v4@bucknell.edu Wed Jun 23 05:04: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 FAA23101 for ; Wed, 23 Jun 1999 05:04: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 EAA07658; Wed, 23 Jun 1999 04:57:58 -0400 (EDT) Date: Wed, 23 Jun 1999 04:57:58 -0400 (EDT) Message-Id: <01BEBD5A.79EF3A20@South-3> Errors-To: droms@bucknell.edu Reply-To: proyse@pracl.demon.co.uk Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Phil Royse To: Multiple recipients of list Subject: help 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 Content-Transfer-Encoding: 7bit help From dhcp-v4@bucknell.edu Wed Jun 23 06:16: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 GAA24064 for ; Wed, 23 Jun 1999 06:16: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 GAA22220; Wed, 23 Jun 1999 06:11:34 -0400 (EDT) Date: Wed, 23 Jun 1999 06:11:34 -0400 (EDT) Message-Id: <5104D4DBC598D211B5FE0000F8FE7EB2021A9734@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: Using 2 DHCP servers to retrieve configuration information X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Internet Mail Service (5.5.2448.0) Is there a way to use DHCP server (A) to get an IP address and to use a different DHCP server (B) to retrieve the rest of the configuration? Thanks, Jerome From dhcp-v4@bucknell.edu Wed Jun 23 09:10: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 JAA27893 for ; Wed, 23 Jun 1999 09:10:11 -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 IAA02270; Wed, 23 Jun 1999 08:59:30 -0400 (EDT) Date: Wed, 23 Jun 1999 08:59:30 -0400 (EDT) Message-Id: <199906231255.IAA03675@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: Using 2 DHCP servers to retrieve configuration information X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Is there a way to use DHCP server (A) to get an IP address and to use a > different DHCP server (B) to retrieve the rest of the configuration? It depends on your client. Assuming that you're writing the client, you can have the client do the usual DHCPDISCOVER/DHCPREQUEST to get an address and then send a DHCPINFORM to the other DHCP server to get the rest of the information. Of course, the client somehow has to know about the other server in order to send a DHCPINFORM to it (or it can broadcast the DHCPINFORM). _MelloN_ From dhcp-v4@bucknell.edu Wed Jun 23 12:48:47 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 MAA05370 for ; Wed, 23 Jun 1999 12:48: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 MAA21382; Wed, 23 Jun 1999 12:40:46 -0400 (EDT) Date: Wed, 23 Jun 1999 12:40:46 -0400 (EDT) Message-Id: <199906231559.LAA07530@cichlid.raleigh.ibm.com> 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: draft-ietf-ip1394-dhcp-01.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 DHCP WG: The following document is a product of the ip1394 WG, but the document arguably should be a joint DHCP/1394 effort. It describes how DHCP should work over 1394 networks. 1394 is different from common link-layers in that it can't just use a link-layer address for the 'chaddr' field. I've appended the entire draft in this note (it's less than three pages of meat), on the hope that some of you need a quick diversion and might be able to return some quick comments. I also think it might be good to discuss this in Oslo. Thanks!!! Thomas 1. Introduction IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. IETF IP1394 Working Group specified the method to carry IPv4 datagrams and ARP packets over an IEEE1394 network [IP1394]. The Dynamic Host Configuration Protocol (DHCP) [RFC2131] provides a framework for passing configuration information to hosts on a TCP/IP network. 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. See [RFC2131] for the mechanism of DHCP and the explanations of each fields. This document is a product of the IP1394 working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ip1394@mailbag.intel.com and/or the author. 2. Issues related to 1394 link address By the conventional link-layer protocols, such as an Ethernet, the 'chaddr' (client hardware address) field may be used to return a reply message from a DHCP server (or relay-agent) to a client. Since 1394 link address (node_ID) is transient and will not be consistent across the 1394 bridge, we have chosen not to put it in the 'chaddr' field. A DHCP client should request the server to send a broadcast reply by setting the BROADCAST flag when ARP is not possible yet. 3. 1394 specific usage of DHCP message fields Following rules should be used when a DHCP client is connected to an IEEE1394 network. 'htype' (hardware address type) MUST be 24 [ARPPARAM]. 'hlen' (hardware address length) MUST be 0. The 'chaddr' (client hardware address) field is reserved. The recipient shall not check the value of this field. A DHCP client on 1394 SHOULD set a BROADCAST flag in DHCPDISCOVER and DHCPREQUEST messages to request the server (or the relay agent) to send a broadcast reply if its 'ciaddr' (client IP address) is zero. K. Fujisawa Expires July 1999 [Page 2] Internet Draft draft-ietf-ip1394-dhcp-01.txt January 1999 'client identifier' option MUST be used in DHCP messages from the client to the server due to the lack of the 'chaddr'. 'client identifier' option may consist of any data. When an EUI-64 (node unique ID) [EUI64] is used as a 'client identifier', the type value for the EUI-64 is 27 [ARPPARAM], and the format is illustrated as follows. Code Len Type Client-Identifier +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 61 | 9 | 27 | EUI-64 (node unique ID) | +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ Note that the use of other 'client identifier' type, such as a fully qualified domain name (FQDN), is not precluded by this memo. For more details, see "9.14. Client-identifier" in [RFC2132]. Security Considerations Security issues are not discussed in this document. References [IP1394] P. Johansson, "IPv4 over IEEE 1394", draft-ietf-ip1394-ipv4-12.txt, work in progress. [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC2131, March 1997. [RFC2132] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC2132, March 1997. [EUI64] http://standards.ieee.org/regauth/oui/tutorials/EUI64.html [ARPPARAM] http://www.isi.edu/in-notes/iana/assignments/arp-parameters Author's address Kenji Fujisawa Sony Corporation IT Laboratories, Computer Systems Laboratory 6-7-35, Kitashinagawa, Shinagawa-ku, Tokyo, 141-0001 Japan Phone: +81-3-5448-4602 E-mail: fujisawa@sm.sony.co.jp K. Fujisawa Expires July 1999 [Page 3] From dhcp-v4@bucknell.edu Wed Jun 23 14:10: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 OAA07987 for ; Wed, 23 Jun 1999 14:10: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 OAA10669; Wed, 23 Jun 1999 14:02:11 -0400 (EDT) Date: Wed, 23 Jun 1999 14:02:11 -0400 (EDT) Message-Id: <199906231702.NAA15987@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: kkinnear@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Kim Kinnear To: Multiple recipients of list Subject: Re: draft-ietf-ip1394-dhcp-01.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.2 My first take on this is that the general idea seems ok, to wit: On 1394 you have to use a client-identifier. Period. That said, I think the form of MAC address used will break a lot of servers (ours, for instance, :-( ). We get upset with a zero length MAC address, and I suspect we're not alone. If the draft said that the hlen MUST be 1 and that chaddr[0] MUST be 0, then it would be a "legal" MAC address, and all 1394 devices would have the same legal MAC address with different client-identifiers, which would work with most if not all servers. Cheers -- Kim At 12:41 PM 6/23/99 -0400, Thomas Narten wrote: >DHCP WG: > >The following document is a product of the ip1394 WG, but the document >arguably should be a joint DHCP/1394 effort. It describes how DHCP >should work over 1394 networks. 1394 is different from common >link-layers in that it can't just use a link-layer address for the >'chaddr' field. > >I've appended the entire draft in this note (it's less than three >pages of meat), on the hope that some of you need a quick diversion >and might be able to return some quick comments. > >I also think it might be good to discuss this in Oslo. > >Thanks!!! >Thomas > > >1. Introduction > > IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. > IETF IP1394 Working Group specified the method to carry IPv4 > datagrams and ARP packets over an IEEE1394 network [IP1394]. > > The Dynamic Host Configuration Protocol (DHCP) [RFC2131] provides a > framework for passing configuration information to hosts on a TCP/IP > network. > > 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. > See [RFC2131] for the mechanism of DHCP and the explanations of each > fields. > > This document is a product of the IP1394 working group within the > Internet Engineering Task Force. Comments are solicited and should > be addressed to the working group's mailing list at > ip1394@mailbag.intel.com and/or the author. > >2. Issues related to 1394 link address > > By the conventional link-layer protocols, such as an Ethernet, the > 'chaddr' (client hardware address) field may be used to return a > reply message from a DHCP server (or relay-agent) to a client. Since > 1394 link address (node_ID) is transient and will not be consistent > across the 1394 bridge, we have chosen not to put it in the 'chaddr' > field. A DHCP client should request the server to send a broadcast > reply by setting the BROADCAST flag when ARP is not possible yet. > >3. 1394 specific usage of DHCP message fields > > Following rules should be used when a DHCP client is connected to > an IEEE1394 network. > > 'htype' (hardware address type) MUST be 24 [ARPPARAM]. > > 'hlen' (hardware address length) MUST be 0. > > The 'chaddr' (client hardware address) field is reserved. The > recipient shall not check the value of this field. > > A DHCP client on 1394 SHOULD set a BROADCAST flag in DHCPDISCOVER and > DHCPREQUEST messages to request the server (or the relay agent) to > send a broadcast reply if its 'ciaddr' (client IP address) is zero. > > > > >K. Fujisawa Expires July 1999 [Page 2] > >Internet Draft draft-ietf-ip1394-dhcp-01.txt January 1999 > > > 'client identifier' option MUST be used in DHCP messages from the > client to the server due to the lack of the 'chaddr'. 'client > identifier' option may consist of any data. When an EUI-64 (node > unique ID) [EUI64] is used as a 'client identifier', the type value > for the EUI-64 is 27 [ARPPARAM], and the format is illustrated as > follows. > > Code Len Type Client-Identifier > +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ > | 61 | 9 | 27 | EUI-64 (node unique ID) | > +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ > > Note that the use of other 'client identifier' type, such as a fully > qualified domain name (FQDN), is not precluded by this memo. > For more details, see "9.14. Client-identifier" in [RFC2132]. > >Security Considerations > > Security issues are not discussed in this document. > >References > > [IP1394] P. Johansson, "IPv4 over IEEE 1394", > draft-ietf-ip1394-ipv4-12.txt, work in progress. > > [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC2131, > March 1997. > > [RFC2132] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor > Extensions", RFC2132, March 1997. > > [EUI64] http://standards.ieee.org/regauth/oui/tutorials/EUI64.html > > [ARPPARAM] http://www.isi.edu/in-notes/iana/assignments/arp-parameters > >Author's address > > Kenji Fujisawa > Sony Corporation > IT Laboratories, Computer Systems Laboratory > 6-7-35, Kitashinagawa, > Shinagawa-ku, Tokyo, 141-0001 Japan > Phone: +81-3-5448-4602 > E-mail: fujisawa@sm.sony.co.jp > > > > > > > >K. Fujisawa Expires July 1999 [Page 3] > > From dhcp-v4@bucknell.edu Wed Jun 23 14:12:36 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 OAA08051 for ; Wed, 23 Jun 1999 14:12: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 OAA08024; Wed, 23 Jun 1999 14:03:37 -0400 (EDT) Date: Wed, 23 Jun 1999 14:03:37 -0400 (EDT) Message-Id: <21839C593E75D211BF7800805FCCD0264B08A6@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: draft-ietf-ip1394-dhcp-01.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 Thomas et al.-- first, there is an obvious typo that should be corrected: in the discussion about header fields, htype is specified to be 27 (ARPPARAM), but in discussion of the client identifier, the type octet is given as 24 (ARPPARAM). Which is correct? Second, the use of chaddr is troubling, if only because we are so conditioned to its existence and usage as the secondary index for locating leases in our server's local storage. Or am I being too fussy? --Barr From dhcp-v4@bucknell.edu Wed Jun 23 15:21: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 PAA10838 for ; Wed, 23 Jun 1999 15:21:01 -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 PAA31783; Wed, 23 Jun 1999 15:17:00 -0400 (EDT) Date: Wed, 23 Jun 1999 15:17:00 -0400 (EDT) Message-Id: <199906231818.OAA04912@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: draft-ietf-ip1394-dhcp-01.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > If the draft said that the hlen MUST be 1 and that chaddr[0] MUST be 0, then > it would be a "legal" MAC address, and all 1394 devices would have the same > legal MAC address with different client-identifiers, which would work with > most if not all servers. Yow. I have to disagree. I would have to fix my server either way. To accept a zero-length link-layer address requires me to not make an entry in my link-layer address table for clients that send zero-length addresses. To accept a link-layer address whose length is 1 and that's the same for every client requires me to add a special case for my server that treats such addresses as null. It also requires me to assume that I will never receive a legitimate link-layer address with a length of 1, which is an assumption that, while likely to be true, I would rather not have to make. I think that a lot of people will have to change their servers as a result of this RFC. I'd rather make the change that is most correct, which I think is what the RFC currently does. _MelloN_ From dhcp-v4@bucknell.edu Wed Jun 23 15:21: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 PAA10843 for ; Wed, 23 Jun 1999 15:21: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 PAA00618; Wed, 23 Jun 1999 15:17:48 -0400 (EDT) Date: Wed, 23 Jun 1999 15:17:48 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v6@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: Re: DHCP with multicasting relay agents... 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-v6@bucknell.edu by STEVE.HANNA@SUN.COM follows. -------------------------------------------------------------------- Since we have been discussing the possible use of multicast with DHCPv4, I decided to look at the DHCPv6 draft to see how it uses multicast. It seems that a significant amount of time was devoted to this particular issue during the design of DHCPv6. We should take advantage of this effort. Here's what I found: * All-DHCP-Agents (a reserved link-local multicast address listed in the spec) is used for sending messages from clients to relays. * All-DHCP-Servers (a reserved site-local multicast address listed in the spec) is used for sending messages from relays to servers. * A server may tell a client to listen to a multicast address for reconfigure messages. In this case, the multicast address is apparently chosen by the server and may have any scope. * A site-local multicast address named All-DHCP-Relays is defined, but I can't find anywhere that it's used. I welcome corrections or clarifications from any of the DHCPv6 developers. The proposal we have been considering corresponds to the use of the All-DHCP-Servers address. This raises one question that I had been considering: If we use a scope-relative multicast address for this purpose, which scope should a relay use? IPv4 Local Scope? A subrange of Organization Local Scope? It seems that this would have to be another configuration parameter. IPv4 Local Scope would be a reasonable default for this parameter, since this scope must always exist whenever IPv4 administrative scoping is in effect. When administrative scoping is in effect, packets sent to an administratively scoped address should have an initial TTL of 255. However, if administrative scoping is not in effect, such packets may leak out of the organization. Therefore, I would suggest that this multicast feature be turned off by default. Just a few ideas. Comments welcome. -Steve From dhcp-v4@bucknell.edu Wed Jun 23 15:21: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 PAA10879 for ; Wed, 23 Jun 1999 15:21:31 -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 PAA29118; Wed, 23 Jun 1999 15:18:11 -0400 (EDT) Date: Wed, 23 Jun 1999 15:18:11 -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: DHCP with multicasting relay agents... 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 STEVE.HANNA@SUN.COM follows. -------------------------------------------------------------------- "Eric A. Hall" wrote: > Looking at IANA's list of currently defined administratively scoped > addresses shows the following: > > Relative Description Reference > --------- -------------------------------------------- --------- > 1 MDHCP Protocol [Patel] > > Apparently a DHCP group address is already there. I'm assuming this is > the v6 group address. I wonder if we can share this group address, and > what the ramifications would be from a protocol perspective. Any > thoughts from anybody who knows? This assignment should be updated to say "MADCAP Protocol." MADCAP is a client-server protocol used for dynamically allocating multicast addresses. Its design was originally based on DHCP and its name was originally MDHCP. There are still a few resemblances, but it is certainly not compatible. The MADCAP spec has been submitted to the IESG for publication as a Proposed Standard. The latest version is draft-ietf-malloc-madcap-05.txt I haven't been following this discussion, but I would strongly suggest not using the same scope-relative address as MADCAP. Thanks, Steve Hanna From dhcp-v4@bucknell.edu Wed Jun 23 15:22:32 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 PAA10913 for ; Wed, 23 Jun 1999 15:22:31 -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 PAA29746; Wed, 23 Jun 1999 15:18:34 -0400 (EDT) Date: Wed, 23 Jun 1999 15:18:34 -0400 (EDT) Message-Id: <199906231902.PAA21419@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: kkinnear@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Kim Kinnear To: Multiple recipients of list Subject: Re: draft-ietf-ip1394-dhcp-01.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.2 At 02:18 PM 6/23/99 -0400, Ted Lemon wrote: > >> If the draft said that the hlen MUST be 1 and that chaddr[0] MUST be 0, then >> it would be a "legal" MAC address, and all 1394 devices would have the same >> legal MAC address with different client-identifiers, which would work with >> most if not all servers. > >Yow. I have to disagree. I would have to fix my server either way. >To accept a zero-length link-layer address requires me to not make an >entry in my link-layer address table for clients that send zero-length >addresses. To accept a link-layer address whose length is 1 and >that's the same for every client requires me to add a special case for >my server that treats such addresses as null. It also requires me to >assume that I will never receive a legitimate link-layer address with >a length of 1, which is an assumption that, while likely to be true, I >would rather not have to make. That's not what I meant, but it brings up an interesting question. I wasn't proposing any special processing for the MAC address that would come in from the 1394 clients (if they made the change that I proposed, so that it was a "legal" MAC address). Why do you need to add a special case for this? My understanding is that if there is no client-identifier in a packet, then the chaddr/hlen/htype -> MAC address is used as the "identity" of the client for the purposes of giving out an IP addresss lease. However, if there *is* a client-identifier, then it MUST be used as the "identity" of the client. In this second case, the actual value of the MAC address doesn't matter, and it is perfectly reasonable for them to be all the same, since it will not be used as the identity of the client. So, why do you have a problem with lots of clients that have the same (legal) MAC address? ------------ I was proposing the change I suggested because I believe that there are no clients today that do not give a valid MAC address even *if* they use a client-identifier, and that the RFC isn't too clear on whether they need to specify a chaddr or not if they use a client-identifier. Thus, I think with the change that I proposed, the 1394 approach will work with most if not all existing servers, some of which might well have a problem with *no* MAC address at all. ? Cheers -- Kim > >I think that a lot of people will have to change their servers as a >result of this RFC. I'd rather make the change that is most correct, >which I think is what the RFC currently does. > > _MelloN_ > From dhcp-v4@bucknell.edu Wed Jun 23 16:38: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 QAA14444 for ; Wed, 23 Jun 1999 16:38:16 -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 QAA23656; Wed, 23 Jun 1999 16:31:58 -0400 (EDT) Date: Wed, 23 Jun 1999 16:31:58 -0400 (EDT) Message-Id: <199906231934.PAA31813@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: draft-ietf-ip1394-dhcp-01.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 message sent to dhcp-v4@bucknell.edu by RWEATHER@LIBERATE.COM follows. ---------------------------------------------------------------------- Kim Kinnear wrote on Wed, 23 Jun 1999 11:02:27 GMT: > If the draft said that the hlen MUST be 1 and that chaddr[0] MUST be 0, then > it would be a "legal" MAC address, and all 1394 devices would have the same > legal MAC address with different client-identifiers, which would work with > most if not all servers. If a legal-looking address needs to be there, then why can't the 8-byte EUI-64 node unique ID be used there as well as in the client ID field, with the same hardware type value used in both places? Since client ID always overrides the MAC address, and the BROADCAST bit is always set, the contents of chaddr mostly exists to fool overly paranoid packet verification checks. The closer it is to the client ID, the easier it will be to fool such servers. chaddr is 16 bytes long, so it is big enough to hold the EUI-64. Putting the EUI-64 into the header would also make the DHCP packet a valid BOOTP packet, so there is at least some chance that BOOTP servers can be used as well for 1394 hosts (yes, BOOTP is obsolete, but some people still use it worse luck). Maybe a bit more information about 1394 might be useful. Are hosts expected to keep some kind of dynamic table that maps EUI-64 values into the transient link addresses? If so, then some kernels might already have the information to do a direct link send. Then again, maybe not. I don't know anything about 1394, so I'm probably wrong. :) Other than that, the spec looks reasonable to me. Cheers, Rhys. From dhcp-v4@bucknell.edu Wed Jun 23 16:38: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 QAA14466 for ; Wed, 23 Jun 1999 16:38: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 QAA17059; Wed, 23 Jun 1999 16:34:05 -0400 (EDT) Date: Wed, 23 Jun 1999 16:34:05 -0400 (EDT) Message-Id: <199906232006.QAA24483@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: kkinnear@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Kim Kinnear To: Multiple recipients of list Subject: Re: draft-ietf-ip1394-dhcp-01.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.2 At 03:40 PM 6/23/99 -0400, Ted Lemon wrote: .. >I understand, but I think this is an extrapolation from your >understanding of your own server that isn't actually valid for all >servers. I've no idea how many servers would have problems with >either solution, though. My server will probably operate correctly as >it is with either solution, but it'll be slow if there are a lot of >clients like this, and I'd prefer to avoid that. I understand. My server isn't going to like one solution, but will operate fine with the other. You are correct, we don't hash the MAC address if there is a client-identifier. > >Where I think you and I are really differing is as to whether or not >this standard requires that people install a new DHCP server. My >take on it is that it's okay if it requires that. It sounds like >you'd prefer not to require that. I don't know what to suggest - >it's obviously easier on me if 1394 requires a server upgrade than it >is for you, but I still think I'm right! :') I'm not really worried about this for my customers, since I've made the changes to allow no MAC addresses recently (and know just how many places that it affected, which was more than I expected). My real issue was that it seemed like if there was a reasonable way for the 1394 folks to write a draft that would "just work" with existing servers, that would be better than requiring server changes. But it sounds like that may be hard to do, since it depends on edge conditions that few have really explored and are likely to differ between server implementations. So I guess it isn't really a big deal. Cheers -- Kim > >BTW, is 1394 == firewire? > > _MelloN_ > From dhcp-v4@bucknell.edu Wed Jun 23 16:38: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 QAA14479 for ; Wed, 23 Jun 1999 16:38: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 QAA19268; Wed, 23 Jun 1999 16:33:19 -0400 (EDT) Date: Wed, 23 Jun 1999 16:33:19 -0400 (EDT) Message-Id: <199906231955.PAA05295@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: DHCP with multicasting relay agents... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 I'll respond to two points that you raise, Steve. First, with respect to DHCPv6 specifically: I think it would be a mistake to try to shoehorn the DHCPv6 effort back into IPv4. The goal here is to come up with a simple change to the DHCPv4 protocol that doesn't affect clients at all, and that can be rapidly deployed to good effect. What we have proposed is a very simple extension to the existing protocol whose sole purpose is to eliminate the need to configure DHCP relay agents with the IP addresses of DHCP servers. Instead, the DHCP relay agent simply multicasts any packets it receives from clients to a well-known multicast address on which all servers listen. The server unicasts its response to the relay agent, which unicasts or broadcasts its response to the client, as the client requested. When you folks were designing DHCPv6, you had one major luxury that we DHCPv4 people don't have - you don't have a large installed base of clients. So you could change the behaviour of the client quite dramatically, and it was okay, because you were changing the behaviour of a client whose widespread deployment was still in the future. The change that we are proposing to the DHCPv4 protocol to support relay agent multicast does not preclude future DHCPv4 enhancements along the lines you suggest. However, if we try to shoehorn those enhancements into the current proposal, the result will be that the current proposal will not be useful in the short term. Now, with respect to administratively scoped multicast: > When administrative scoping is in effect, packets sent to an > administratively scoped address should have an initial TTL of 255. > However, if administrative scoping is not in effect, such packets may > leak out of the organization. Therefore, I would suggest that this > multicast feature be turned off by default. How can packets multicast to an administratively scoped multicast address leak out of one organization and into another? I think the only way this can happen is that the administrators of both organizations have to have misconfigured their border routers - it is not sufficient for just one organization to have done this, because even if the multicasts make it across their border router, some other border router has to be interested in forwarding the multicasts inward. So I think this is a non-problem. I am, however, very interested in what the DHCPv6 people have to say about this particular issue. _MelloN_ From dhcp-v4@bucknell.edu Wed Jun 23 16:38: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 QAA14510 for ; Wed, 23 Jun 1999 16:38: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 QAA08466; Wed, 23 Jun 1999 16:32:55 -0400 (EDT) Date: Wed, 23 Jun 1999 16:32:55 -0400 (EDT) Message-Id: <199906231940.PAA05257@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: draft-ietf-ip1394-dhcp-01.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > I wasn't proposing any special processing for the MAC address > that would come in from the 1394 clients (if they made the > change that I proposed, so that it was a "legal" MAC address). Does the RFC say that a zero-length MAC address isn't legal? I can't find any such statement. > Why do you need to add a special case for this? Because the ISC DHCP server records every link-layer address in a hash table. If a bunch of clients all have the same link-layer address, they're all going to wind up in the same hash bucket, which isn't going to make any difference to them, but will make things really slow for any other client that winds up in the same hash bucket. > if there *is* a client-identifier, then it MUST be used as the > "identity" of the client. In this second case, the actual value of > the MAC address doesn't matter, True. > and it is perfectly reasonable for them to be all the same, since it > will not be used as the identity of the client. Depends on how you implemented your server, doesn't it? It sounds like you don't hash the hardware address if you get a client identifier, but the ISC server does, so for us it's a problem. :'( > I was proposing the change I suggested because I believe that there > are no clients today that do not give a valid MAC address even *if* > they use a client-identifier, and that the RFC isn't too clear on > whether they need to specify a chaddr or not if they use a > client-identifier. I think you'd have to squint real hard to get anything out of the current draft other than that the client has to send its link-layer address regardless of whether or not it sends a client identifier. > Thus, I think with the change that I proposed, the 1394 > approach will work with most if not all existing servers, some of > which might well have a problem with *no* MAC address at all. I understand, but I think this is an extrapolation from your understanding of your own server that isn't actually valid for all servers. I've no idea how many servers would have problems with either solution, though. My server will probably operate correctly as it is with either solution, but it'll be slow if there are a lot of clients like this, and I'd prefer to avoid that. Where I think you and I are really differing is as to whether or not this standard requires that people install a new DHCP server. My take on it is that it's okay if it requires that. It sounds like you'd prefer not to require that. I don't know what to suggest - it's obviously easier on me if 1394 requires a server upgrade than it is for you, but I still think I'm right! :') BTW, is 1394 == firewire? _MelloN_ From dhcp-v4@bucknell.edu Wed Jun 23 16:39:02 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 QAA14532 for ; Wed, 23 Jun 1999 16:39:01 -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 QAA01509; Wed, 23 Jun 1999 16:33:40 -0400 (EDT) Date: Wed, 23 Jun 1999 16:33:40 -0400 (EDT) Message-Id: <21839C593E75D211BF7800805FCCD0264B08A9@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: draft-ietf-ip1394-dhcp-01.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 Kim, Ted, et al.-- I expect that many servers would require modification for this case, and I wonder if it might be better to specify that instead of a null chaddr, some unique octet string be used, much like Microsoft inserts a string in packets for RAS requests? Of course, I don't know if the EUI-64 identifier suggested by the draft is sufficiently unique for this purpose, but if it is it would seem a likely candidate. > My understanding is that if there is no client-identifier > in a packet, then the chaddr/hlen/htype -> MAC address is > used as the "identity" of the client for the purposes of > giving out an IP addresss lease. However, if there *is* > a client-identifier, then it MUST be used as the "identity" > of the client. In this second case, the actual value > of the MAC address doesn't matter, and it is perfectly > reasonable for them to be all the same, since it will > not be used as the identity of the client. > > I was proposing the change I suggested because I believe > that there are no clients today that do not give a valid > MAC address even *if* they use a client-identifier, and > that the RFC isn't too clear on whether they need to specify > a chaddr or not if they use a client-identifier. > My understanding is a bit different from yours, Kim... I believe that the client identifier is preferred over any other means of identifying a lease (such as MAC address, IP address, or hostname--which my support people insist on using!), but is not exclusively used instead of, say, chaddr. But as for the impact on various server implementations, in my case if chaddr were "missing" I simply wouldn't try to index the lease using it, just as I don't index the lease on client identifier or hostname if they are missing. I would have to add another rule that requires a client identifier if chaddr is null, but that is not really any different than requiring certain other fields to be present or absent based on received options and message type. Maybe we do need some editorial changes in the RFCs as well. --Barr From dhcp-v4@bucknell.edu Wed Jun 23 17:37: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 RAA16237 for ; Wed, 23 Jun 1999 17:37: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 RAA03118; Wed, 23 Jun 1999 17:32:26 -0400 (EDT) Date: Wed, 23 Jun 1999 17:32:26 -0400 (EDT) Message-Id: <199906232116.RAA11698@atlantic.East.Sun.COM> 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: Re: draft-ietf-ip1394-dhcp-01.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_21 SunOS 5.8 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii Mime-Version: 1.0 Thanks for passing this along, Thomas. I too think that this should be a joint DHCP/1394 effort. (is the 1394 WG in agreement?) When I read this note, a few hairs were raised on the back of my neck like the other implementors. After checking our code, it turns out that the draft as it is now will work just fine with our implementation. The "IPv4 over IEEE 1394" draft states that a node_ID changes each time a device is added or removed from the bus, which explains the node_ID's transience. I'm not at all familiar with IEEE 1394. Any chance of having someone from the 1394 WG either send a brief description of the architecture to the DHC WG alias (preferred) or stop by in Oslo and give a brief talk (less preferred, for those that can't make oslo)? One question I have is: What does a 1394 topology look like? How many devices does one typically connect to a bus? The draft mentions a bridge, which seems to suggest you could have quite a few devices. Using the limited broadcast address for replies is typically something we try to avoid, particularly when there's lots of nodes that could be affected. Mike Carney SNT Internet Engineering Sun Microsystems, Inc. Mailstop UBUR02-212 One Network Drive Burlington, MA 01803 From dhcp-v4@bucknell.edu Wed Jun 23 17:37: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 RAA16248 for ; Wed, 23 Jun 1999 17:37: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 RAA03292; Wed, 23 Jun 1999 17:31:38 -0400 (EDT) Date: Wed, 23 Jun 1999 17:31:38 -0400 (EDT) Message-Id: <47FEF5D2BE22D311AA8600508B10891503F5E9@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: Using 2 DHCP servers to retrieve configuration information 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 Isn't there a field in the DHCP response with the "server" address for FTP and file-based configuration? ------------------------------------------- Eric L. Michelsen, Copper Mountain Networks > -----Original Message----- > From: Ted Lemon [mailto:mellon@isc.org] > Sent: Wednesday, June 23, 1999 6:00 > To: Multiple recipients of list > Subject: Re: Using 2 DHCP servers to retrieve configuration > information > > > > > Is there a way to use DHCP server (A) to get an IP address > and to use a > > different DHCP server (B) to retrieve the rest of the configuration? > > It depends on your client. Assuming that you're writing the client, > you can have the client do the usual DHCPDISCOVER/DHCPREQUEST to get > an address and then send a DHCPINFORM to the other DHCP server to get > the rest of the information. Of course, the client somehow has to > know about the other server in order to send a DHCPINFORM to it (or it > can broadcast the DHCPINFORM). > > _MelloN_ > From dhcp-v4@bucknell.edu Wed Jun 23 19:19:06 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 TAA18252 for ; Wed, 23 Jun 1999 19:19: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 TAA14489; Wed, 23 Jun 1999 19:14:45 -0400 (EDT) Date: Wed, 23 Jun 1999 19:14:45 -0400 (EDT) Message-Id: <47FEF5D2BE22D311AA8600508B10891503F5F2@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: Using 2 DHCP servers to retrieve configuration information 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 wasn't clear. Though the "siaddr" field is often used for FTP and file based configuration, RFC2131 defines the "siaddr" field as the "IP address of next server to use in bootstrap" [p. 10]. Seems like that next server could be a DHCP server, if the client knew to interpret it as such. ------------------------------------------- Eric L. Michelsen, Copper Mountain Networks > -----Original Message----- > From: Ted Lemon [mailto:mellon@isc.org] > Sent: Wednesday, June 23, 1999 15:04 > To: emichelsen@coppermountain.com > Subject: Re: Using 2 DHCP servers to retrieve configuration > information > > > > > Isn't there a field in the DHCP response with the "server" > address for FTP > > and file-based configuration? > > Yes. But that doesn't have anything to do with contacting a second > DHCP server after getting an address assignment. > > _MelloN_ > From dhcp-v4@bucknell.edu Wed Jun 23 19:19:14 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 TAA18263 for ; Wed, 23 Jun 1999 19:19:13 -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 TAA02608; Wed, 23 Jun 1999 19:16:21 -0400 (EDT) Date: Wed, 23 Jun 1999 19:16:21 -0400 (EDT) Message-Id: <199906232311.TAA06051@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: Using 2 DHCP servers to retrieve configuration information X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > I wasn't clear. Though the "siaddr" field is often used for FTP and file > based configuration, RFC2131 defines the "siaddr" field as the "IP address > of next server to use in bootstrap" [p. 10]. Seems like that next server > could be a DHCP server, if the client knew to interpret it as such. I suppose that's true, yes. _MelloN_ From dhcp-v4@bucknell.edu Wed Jun 23 19:19: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 TAA18274 for ; Wed, 23 Jun 1999 19:19:27 -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 TAA32055; Wed, 23 Jun 1999 19:15:31 -0400 (EDT) Date: Wed, 23 Jun 1999 19:15: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 E. Droms" To: Multiple recipients of list Subject: RE: Using 2 DHCP servers to retrieve configuration information 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 On Wed, 23 Jun 1999, Eric Michelsen wrote: > Isn't there a field in the DHCP response with the "server" address for FTP > and file-based configuration? > ------------------------------------------- > Eric L. Michelsen, Copper Mountain Networks Yes, but that second server would not use DHCP to return the parameters to the client. The original message specified a "different DHCP server" for the rest of the configuration. > > -----Original Message----- > > From: Ted Lemon [mailto:mellon@isc.org] > > Sent: Wednesday, June 23, 1999 6:00 > > To: Multiple recipients of list > > Subject: Re: Using 2 DHCP servers to retrieve configuration > > information > > > > > > > > > Is there a way to use DHCP server (A) to get an IP address > > and to use a > > > different DHCP server (B) to retrieve the rest of the configuration? > > > > It depends on your client. Assuming that you're writing the client, > > you can have the client do the usual DHCPDISCOVER/DHCPREQUEST to get > > an address and then send a DHCPINFORM to the other DHCP server to get > > the rest of the information. Of course, the client somehow has to > > know about the other server in order to send a DHCPINFORM to it (or it > > can broadcast the DHCPINFORM). > > > > _MelloN_ > > > From dhcp-v4@bucknell.edu Wed Jun 23 21:18:32 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 VAA19849 for ; Wed, 23 Jun 1999 21:18:31 -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 VAA29423; Wed, 23 Jun 1999 21:14:41 -0400 (EDT) Date: Wed, 23 Jun 1999 21:14:41 -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: draft-ietf-ip1394-dhcp-01.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 At 12:42 PM 6/23/99 -0400, Thomas Narten wrote: >I also think it might be good to discuss this in Oslo. Thanks to all for your quick read and response to this I-D. We should discuss the I-D in Oslo and I will put it on the agenda. Any volunteers to lead the discussion? - Ralph From dhcp-v4@bucknell.edu Wed Jun 23 21:56: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 VAA21128 for ; Wed, 23 Jun 1999 21:56: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 VAA04813; Wed, 23 Jun 1999 21:52:32 -0400 (EDT) Date: Wed, 23 Jun 1999 21:52:32 -0400 (EDT) Message-Id: <199906240150.KAA22161@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: draft-ietf-ip1394-dhcp-01.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Dear all, Thank you for your review and comments. Barr said: >first, there is an obvious typo that should be corrected: in the discussion >about header fields, htype is specified to be 27 (ARPPARAM), but in >discussion of the client identifier, the type octet is given as 24 >(ARPPARAM). Which is correct? As you can see in [ARPPARAM], both values are correct. htype IEEE1394 24 client ID type EUI-64 27 Since EUI-64 does not mean IEEE1394, we can use EUI-64 on some other datalinks. We discussed this issue in Chicago IETF42. http://www.ietf.org/proceedings/98aug/98aug-60.htm :The only technical change for a new EUI-64 Hardware :Type requires a number to be allocated by IANA. _MelloN_ said: >BTW, is 1394 == firewire? Yes, 1394 == firewire == i.LINK Mike Carney said: >I too think that this should be >a joint DHCP/1394 effort. (is the 1394 WG in agreement?) Yes. :Once complete, the "DHCP Extensions for IP/1394" draft will be :submitted for review by the DHCP WG with the intention of our WG :producing an informational RFC. >One question I have is: What does a 1394 topology look like? How many >devices does one typically connect to a bus? The link-address of 1394 is node_ID. It has 10bit busID portion and 6bit PhyID portion. So, single 1394-bus can have upto 63 nodes. But 10 or 16 will be a typical maximum number due to arbitration overhead. >The draft mentions a bridge, >which seems to suggest you could have quite a few devices. The 1394 bus bridge is discussed in IEEE P1394.1 Working Group, the detail of the bus bridge has not been fixed yet. 1394 bus bridge devides arbitration domain and connects two 1394 buses. Since the busID is 10bit, upto 1023 buses can be connected theoretically, but nobody believes it is possible in reality. 1394 bus bridge WILL do some node_ID (busID+phyID) mapping, it means that link address of node-A may be different for node-B and node-C. -+-------+-----Bridge------+-------- A B C >Using the >limited broadcast address for replies is typically something we try >to avoid, particularly when there's lots of nodes that could be affected. Yes. The use of broadcast reply is a compromise to handle the link address mapping by the 1394 bus bridge. Best Regards, Kenji Fujisawa From dhcp-v4@bucknell.edu Wed Jun 23 22:33: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 WAA22360 for ; Wed, 23 Jun 1999 22:33: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 WAA10913; Wed, 23 Jun 1999 22:28:58 -0400 (EDT) Date: Wed, 23 Jun 1999 22:28:58 -0400 (EDT) Message-Id: <21839C593E75D211BF7800805FCCD0264B08AB@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: draft-ietf-ip1394-dhcp-01.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 Thaks for the clarification! --Barr > As you can see in [ARPPARAM], both values are correct. > htype IEEE1394 24 > client ID type EUI-64 27 > > Since EUI-64 does not mean IEEE1394, we can use EUI-64 on some other > datalinks. We discussed this issue in Chicago IETF42. > From dhcp-v4@bucknell.edu Wed Jun 23 22:33: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 WAA22378 for ; Wed, 23 Jun 1999 22:33: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 WAA05893; Wed, 23 Jun 1999 22:29:47 -0400 (EDT) Date: Wed, 23 Jun 1999 22:29:47 -0400 (EDT) Message-Id: <199906240213.WAA18957@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: draft-ietf-ip1394-dhcp-01.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 message sent to dhcp-v4@bucknell.edu by LAPP@NORTELNETWORKS.COM follows. ------------------------------------------------------------------------ Kim Kinnear wrote: > > My first take on this is that the general idea seems ok, to wit: On 1394 > you have to use a client-identifier. Period. > > That said, I think the form of MAC address used will break a lot of servers > (ours, for instance, :-( ). We get upset with a zero length > MAC address, and I suspect we're not alone. > > If the draft said that the hlen MUST be 1 and that chaddr[0] MUST be 0, then > it would be a "legal" MAC address, and all 1394 devices would have the same > legal MAC address with different client-identifiers, which would work with > most if not all servers. > Having seen (half) the discussion between yourself and Ted might I suggest: - have the client include its 1394 address in chaddr (with hlen set appropriately) - change the "SHOULD" set the broadcast bit requirement to a "MUST" This would provide both a non-zero length MAC address and some variability in MAC address value. Of course, the ISC server may still see some hash collisions if it has more then one 1394 subnet or 1394 subnets that include bridges but I gather that a reduction in the collisions would help. It also seems cleaner then mandating chaddr[0] = 0 Dave Lapp Nortel Networks From dhcp-v4@bucknell.edu Wed Jun 23 23:43:36 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 XAA23457 for ; Wed, 23 Jun 1999 23:43: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 XAA23342; Wed, 23 Jun 1999 23:39:50 -0400 (EDT) Date: Wed, 23 Jun 1999 23:39:50 -0400 (EDT) Message-Id: <199906240332.MAA22625@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: draft-ietf-ip1394-dhcp-01.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 >Thanks to all for your quick read and response to this I-D. We should >discuss the I-D in Oslo and I will put it on the agenda. Any volunteers to >lead the discussion? I'll attend the Oslo meeting, and will make a brief explanation of this I-D. But my listening capability of English is very bad, I probably can not lead the discussion. I need your help. Best Regards, Kenji Fujisawa From dhcp-v4@bucknell.edu Thu Jun 24 00:58: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 AAA24362 for ; Thu, 24 Jun 1999 00:58: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 AAA31418; Thu, 24 Jun 1999 00:54:31 -0400 (EDT) Date: Thu, 24 Jun 1999 00:54:31 -0400 (EDT) Message-Id: <199906240428.AAA13587@atlantic.East.Sun.COM> 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: Re: draft-ietf-ip1394-dhcp-01.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_21 SunOS 5.8 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii Mime-Version: 1.0 Thanks for 1394-in-a-nutshell description. This helps alot. Looks like a maximum number of possible nodes is 64k, but more likely will be much smaller than that maximum. Is limited broadcast (255.255.255.255) traffic judged not to be a big deal in your environment? (was that consideration discussed as part of the DHCP/1394 draft?). If not, then you might want to add a few words saying that you understand and accept the consequences of the use of the broadcast bit as part of your solution. Mike Carney SNT Internet Engineering Sun Microsystems, Inc. Mailstop UBUR02-212 One Network Drive Burlington, MA 01803 From dhcp-v4@bucknell.edu Thu Jun 24 00:58: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 AAA24373 for ; Thu, 24 Jun 1999 00:58: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 AAA26251; Thu, 24 Jun 1999 00:55:07 -0400 (EDT) Date: Thu, 24 Jun 1999 00:55:07 -0400 (EDT) Message-Id: <199906240451.NAA22809@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: draft-ietf-ip1394-dhcp-01.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 >Is limited broadcast (255.255.255.255) traffic >judged not to be a big deal in your environment? (was that consideration >discussed as part of the DHCP/1394 draft?). Yes. >If not, then you might want >to add a few words saying that you understand and accept the consequences >of the use of the broadcast bit as part of your solution. I agree that adding a few words will be useful for the readers. I'll do in next revision. Thanks! Kenji Fujisawa From dhcp-v4@bucknell.edu Thu Jun 24 04:36: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 EAA08980 for ; Thu, 24 Jun 1999 04:36: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 EAA31134; Thu, 24 Jun 1999 04:28:37 -0400 (EDT) Date: Thu, 24 Jun 1999 04:28:37 -0400 (EDT) Message-Id: <5104D4DBC598D211B5FE0000F8FE7EB2021A9CE1@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: RE: Using 2 DHCP servers to retrieve configuration information X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Internet Mail Service (5.5.2448.0) Hmm, I thought about the 2 ideas you described: 1) client does standard DHCP exchange with DHCP server 1 and then use DHCPINFORM to query DHCP server 2. 2) DHCP server 1 returns IP address of DHCP server 2 in the "siaddr" field. But none of the above cases works with standard clients/relay agents. Am I right? For case 1, the relay agent should send DHCPINFORM requests to a different DHCP server (no. 2) than the other requests. For case 2, the client has to understand that the IP address returned in the "siaddr" is the one of a DHCP server (and not a server where to retrieve a boot file) and should send a DHCPINFORM to it. Do we agree that the two-phase configuration that I'd like is not possible with standard DHCP clients/relay agents? Thanks, Jerome -----Original Message----- From: Ted Lemon [SMTP:mellon@isc.org] Sent: Thursday, June 24, 1999 12:17 AM To: Multiple recipients of list Subject: Re: Using 2 DHCP servers to retrieve configuration information > I wasn't clear. Though the "siaddr" field is often used for FTP and file > based configuration, RFC2131 defines the "siaddr" field as the "IP address > of next server to use in bootstrap" [p. 10]. Seems like that next server > could be a DHCP server, if the client knew to interpret it as such. I suppose that's true, yes. _MelloN_ From dhcp-v4@bucknell.edu Thu Jun 24 11:08: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 LAA15502 for ; Thu, 24 Jun 1999 11:08: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 HAA14205; Thu, 24 Jun 1999 07:36:26 -0400 (EDT) Date: Thu, 24 Jun 1999 07:36:26 -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-authentication-10.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 : Authentication for DHCP Messages Author(s) : R. Droms, W. Arbaugh Filename : draft-ietf-dhc-authentication-10.txt Pages : 15 Date : 17-Jun-99 The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. In some situations, network administrators may wish to constrain the allocation of addresses to authorized hosts. Additionally, some network administrators may wish to provide for authentication of the source and contents of DHCP messages. This document defines a new DHCP option through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-authentication-10.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-authentication-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-authentication-10.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: <19990617123611.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-authentication-10.txt From dhcp-v4@bucknell.edu Thu Jun 24 11:42:14 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 LAA16069 for ; Thu, 24 Jun 1999 11:42:13 -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 LAA27909; Thu, 24 Jun 1999 11:42:10 -0400 (EDT) Date: Thu, 24 Jun 1999 11:42:10 -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: Using 2 DHCP servers to retrieve configuration information 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 SUJAN@TRISHUL.WIPINFO.SOFT.NET follows. ---------------------------------------------------------------------------- --- On Thu, 24 Jun 1999 jerome.privat@bt.com wrote: > Hmm, I thought about the 2 ideas you described: > 1) client does standard DHCP exchange with DHCP server 1 and then use > DHCPINFORM > to query DHCP server 2. > 2) DHCP server 1 returns IP address of DHCP server 2 in the "siaddr" > field. > > But none of the above cases works with standard clients/relay agents. Am I > right? > For case 1, the relay agent should send DHCPINFORM requests to a different > DHCP server (no. 2) than the other requests. > For case 2, the client has to understand that the IP address returned in the > "siaddr" is the one of a DHCP server (and not a server where to retrieve a > boot file) and should send a DHCPINFORM to it. > > Do we agree that the two-phase configuration that I'd like is not possible > with standard DHCP clients/relay agents? > That is true .. Sujan > Thanks, > Jerome From dhcp-v4@bucknell.edu Thu Jun 24 11:47: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 LAA16189 for ; Thu, 24 Jun 1999 11:47:00 -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 LAA13903; Thu, 24 Jun 1999 11:46:38 -0400 (EDT) Date: Thu, 24 Jun 1999 11:46:38 -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-nsso-00.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 : The Name Service Search Option for DHCP Author(s) : C. Smith Filename : draft-ietf-dhc-nsso-00.txt Pages : 4 Date : 21-Jun-99 This document defines a new DHCP option which is passed from the DHCP Server to the DHCP Client to specify the order in which name services should be consulted when resolving hostnames and other information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-nsso-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-nsso-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-nsso-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19990621101402.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-nsso-00.txt From dhcp-v4@bucknell.edu Thu Jun 24 11:48: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 LAA16231 for ; Thu, 24 Jun 1999 11:48: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 LAA15129; Thu, 24 Jun 1999 11:47:32 -0400 (EDT) Date: Thu, 24 Jun 1999 11:47:32 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v6@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: Re: DHCP with multicasting relay agents... 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-v6@bucknell.edu by MELLON@ISC.ORG follows. --------------------------------------------------------------- I'll respond to two points that you raise, Steve. First, with respect to DHCPv6 specifically: I think it would be a mistake to try to shoehorn the DHCPv6 effort back into IPv4. The goal here is to come up with a simple change to the DHCPv4 protocol that doesn't affect clients at all, and that can be rapidly deployed to good effect. What we have proposed is a very simple extension to the existing protocol whose sole purpose is to eliminate the need to configure DHCP relay agents with the IP addresses of DHCP servers. Instead, the DHCP relay agent simply multicasts any packets it receives from clients to a well-known multicast address on which all servers listen. The server unicasts its response to the relay agent, which unicasts or broadcasts its response to the client, as the client requested. When you folks were designing DHCPv6, you had one major luxury that we DHCPv4 people don't have - you don't have a large installed base of clients. So you could change the behaviour of the client quite dramatically, and it was okay, because you were changing the behaviour of a client whose widespread deployment was still in the future. The change that we are proposing to the DHCPv4 protocol to support relay agent multicast does not preclude future DHCPv4 enhancements along the lines you suggest. However, if we try to shoehorn those enhancements into the current proposal, the result will be that the current proposal will not be useful in the short term. Now, with respect to administratively scoped multicast: > When administrative scoping is in effect, packets sent to an > administratively scoped address should have an initial TTL of 255. > However, if administrative scoping is not in effect, such packets may > leak out of the organization. Therefore, I would suggest that this > multicast feature be turned off by default. How can packets multicast to an administratively scoped multicast address leak out of one organization and into another? I think the only way this can happen is that the administrators of both organizations have to have misconfigured their border routers - it is not sufficient for just one organization to have done this, because even if the multicasts make it across their border router, some other border router has to be interested in forwarding the multicasts inward. So I think this is a non-problem. I am, however, very interested in what the DHCPv6 people have to say about this particular issue. _MelloN_ From dhcp-v4@bucknell.edu Thu Jun 24 11:57: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 LAA16383 for ; Thu, 24 Jun 1999 11:57: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 LAA21731; Thu, 24 Jun 1999 11:45:29 -0400 (EDT) Date: Thu, 24 Jun 1999 11:45:29 -0400 (EDT) Message-Id: <199906241234.IAA08787@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: Using 2 DHCP servers to retrieve configuration information X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Do we agree that the two-phase configuration that I'd like is not possible > with standard DHCP clients/relay agents? That's correct, yes. _MelloN_ From dhcp-v4@bucknell.edu Thu Jun 24 13:06: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 NAA17669 for ; Thu, 24 Jun 1999 13:06: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 NAA03965; Thu, 24 Jun 1999 13:06:31 -0400 (EDT) Date: Thu, 24 Jun 1999 13:06:31 -0400 (EDT) Message-Id: <37725261.3B90C8A8@sun.com> Errors-To: droms@bucknell.edu Reply-To: steve.hanna@sun.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Steve Hanna To: Multiple recipients of list Subject: Re: DHCP with multicasting relay agents... 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.5 [en] (WinNT; U) Content-Transfer-Encoding: 7bit Ted Lemon wrote: > I'll respond to two points that you raise, Steve. First, with respect > to DHCPv6 specifically: I think it would be a mistake to try to > shoehorn the DHCPv6 effort back into IPv4. The goal here is to come > up with a simple change to the DHCPv4 protocol that doesn't affect > clients at all, and that can be rapidly deployed to good effect. I agree with you on this. I wasn't proposing that DHCPv4 adopt all of the multicast features of DHCPv6. I was just describing them. The extension to DHCPv4 that you have proposed seems very similar to the use of the All-DHCP-Servers address in DHCPv6. Relays forward packets to this address for delivery to all DHCP servers within a particular domain. However, DHCPv6 has a single well-known multicast address for this purpose, whereas you have proposed using a scope-relative multicast address. This address will appear separately in each scope that a relay is in: IPv4 Local Scope, Organization Local Scope, etc. So my first question was: which scope should the relay use? I suggested IPv4 Local Scope as a reasonable choice, since it will always be around. However, it would probably be good to make this a configurable parameter. > > When administrative scoping is in effect, packets sent to an > > administratively scoped address should have an initial TTL of 255. > > However, if administrative scoping is not in effect, such packets > > may leak out of the organization. Therefore, I would suggest that > > this multicast feature be turned off by default. > > How can packets multicast to an administratively scoped multicast > address leak out of one organization and into another? I think the > only way this can happen is that the administrators of both > organizations have to have misconfigured their border routers - it is > not sufficient for just one organization to have done this, because > even if the multicasts make it across their border router, some other > border router has to be interested in forwarding the multicasts > inward. So I think this is a non-problem. I am, however, very > interested in what the DHCPv6 people have to say about this particular > issue. Administrative scoping is put into effect by configuring routers so that they don't forward packets sent to an administratively scoped multicast address outside of the intended administrative scope. If nobody has done this configuration at a particular site, nothing will prevent packets sent to an administratively scoped multicast address from that site from being forwarded out of the site. Effectively, the community of people who haven't configured their routers to enable administrative scoping forms a single scope. Traffic sent to administratively scoped addresses will be forwarded to group members throughout that community so long as the TTL is greater than zero. Since most sites have not enabled administrative scoping, we should definitely consider this when designing our protocols. That's why I suggested that the multicast feature be turned off by default. Otherwise, naive admins will end up with a system that forwards messages from their relay agents to DHCP servers around the world. And they'll be very confused when their users get address assignments from somebody else's DHCP server (or vice versa). I don't know if this is an issue for DHCPv6 or not. Perhaps the site-local addresses they're using will always be constrained properly. Thanks, Steve P.S. I wasn't involved in the development of DHCPv6. It looks very nice, but I can't take any credit for it. From dhcp-v4@bucknell.edu Thu Jun 24 13:08: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 NAA17691 for ; Thu, 24 Jun 1999 13:08: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 NAA26168; Thu, 24 Jun 1999 13:08:07 -0400 (EDT) Date: Thu, 24 Jun 1999 13:08:07 -0400 (EDT) Message-Id: <199906241647.MAA19364@cichlid.raleigh.ibm.com> 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: Re: Status of draft-ietf-dhc-agent-options-05.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > I just joined the list and I have a special interest in the I-D > draft-ietf-dhc-agent-options-05.txt, particularly the 'Agent Circuit ID' > sub-option. > What is the current status of this I-D? Is it on the way to becoming an > RFC? This ID is (was?) close to being approved by the IESG to become a Proposed Standard. All that is needed is a revised document submitted as an Internet Draft. You'll need to contact the document's author directly to find out when a new draft will be submitted. Thomas From dhcp-v4@bucknell.edu Fri Jun 25 16:02: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 QAA03064 for ; Fri, 25 Jun 1999 16:02: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 QAA03271; Fri, 25 Jun 1999 16:01:53 -0400 (EDT) Date: Fri, 25 Jun 1999 16:01:53 -0400 (EDT) Message-Id: <199906251943.PAA26675@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: I-D ACTION:draft-ietf-dhc-subnet-option-03.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 : The Subnet Selection Option for DHCP Author(s) : G. Waters Filename : draft-ietf-dhc-subnet-option-03.txt Pages : 6 Date : 24-Jun-99 This memo defines a new DHCP option for selecting the subnet on which to allocate an address. This option would override a DHCP server's normal methods of selecting which subnet on which to allocate an address for a client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-subnet-option-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-subnet-option-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-subnet-option-03.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: <19990624134159.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-subnet-option-03.txt From dhcp-v4@bucknell.edu Fri Jun 25 17:32: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 RAA05951 for ; Fri, 25 Jun 1999 17:32: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 RAA02334; Fri, 25 Jun 1999 17:32:02 -0400 (EDT) Date: Fri, 25 Jun 1999 17:32:02 -0400 (EDT) Message-Id: <63D30D6E10CFD11190A90000F805FE8601545773@lespaul.process.com> Errors-To: droms@bucknell.edu Reply-To: Bennett@process.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Andy Bennett To: Multiple recipients of list Subject: draft-ietf-dhc-schema-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: multipart/mixed; X-Mailer: Internet Mail Service (5.0.1460.8) Mime-Version: 1.0 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BEBF4D.E67724EC Content-Type: text/plain The attached Internet-Draft has been submitted. I'm not sure if it gets automatically sent to this list or not, so I thought I'd post it. Abstract This document presents an LDAP schema to represent the configuration of the DHCP protocol within a TCP/IP network. It can be used to represent the configuration(s) of an entire enterprise network, a subset of the network, or even a single server. <> ------ =_NextPart_000_01BEBF4D.E67724EC Content-Type: text/plain; name="draft-ietf-dhc-schema-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-dhc-schema-00.txt" Network Working Group Andy = Bennett INTERNET-DRAFT Bernie = Volz Process = Software Andrea = Westerinen = Microsoft June = 1999 Expires December = 1999 DHCP Schema for LDAP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This document presents an LDAP schema to represent the configuration of the DHCP protocol within a TCP/IP network. It can be used to represent the configuration(s) of an entire enterprise network, a subset of the network, or even a single server. Bennett, et. al. Expires December 1999 [Page = 1] =0C Internet Draft DHCP Schema for LDAP June = 1999 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. In places where different sets of terminology are commonly used to represent similar DHCP concepts, this schema uses the terminology of the Internet Software Consortium's DHCP server reference implementa- tion. For more information see www.isc.org. 2. Open Issues The following known issues are not (yet) resolved by this Internet- Draft. These issues will be addressed in a future revision of this document. o This schema cannot represent a configuration where a DHCP server would use two (or more) pieces of information from the DHCPREQUEST packet to make decisions. Examples of this include: (1) a lease- pool in a subnet that is class-specific (2) a client without a fixed address having different sets of options depending on which subnet it is booting on. There are other examples like this. o This document does not thoroughly address the issue of how objects should be named. Specifically, it does not identify the attribute on each object that should be used as a "relative distinguished name" (or "rdn") for generating a unique "distinguished name" (or "dn"). o The attribute definitions need to be reviewed to make sure the = syn- tax and datatypes are correct. In some cases there are enumera- tions that may not be complete. 3. Design Considerations Some of the design considerations for this schema were: o Heterogeneous server environment - This schema is not designed to represent the configuration of a specific DHCP server implementa- tion. The intent of this schema is to provide a basic framework for the representation of the most common elements used in the = con- figuration of DHCP. This should allow other network services to obtain and use basic DHCP configuration information in a server- independent way. Also note that it is highly unlikely that this schema will be able to represent every feature of every = implementa- tion (and it is not intended to do so). It is expected that some implementations may need to extend the schema objects in order to Bennett, et. al. Expires December 1999 [Page = 2] =0C Internet Draft DHCP Schema for LDAP June = 1999 fully implement all their features. o Relationship to DEN/DMTF - This document takes into consideration the object-oriented information model for representing Network information (including DHCP information) currently under develop- ment as part of the Common Information Model (CIM) activity in the Distributed Management Task Force (DMTF). It should be noted that the CIM schema is still under development and subject to change. The DMTF efforts continue and draw upon the Directory-Enabled Net- works (DEN) specification. The schema described in this Internet- Draft is intended to be an LDAP implementation of the appropriate objects in the DMTF model. The DMTF schema was used as a source for defining certain terminology within this schema. For more information see [DMTF] and [DEN]. o Use of the schema - This draft does not define any "minimal = compli- ance criteria" for using the schema. It is recommended that you use the object classes defined in this draft if you are represent- ing DHCP configuration information in an LDAP directory. Some implementations may choose not to support all of the objects defined here. In particular, the following two decisions are explicitly left up to the implementation: - it is up to the implementation to determine whether or not the lease information will be stored in the directory. Some imple- mentations may choose not to store this information. - it is up to the implementation to determine if the data in the directory is considered "authoritative", or if it is simply a copy of data from an authoritative source. o The schema is focused on the representation of configuration = infor- mation. It does not provide for the representation of statistical data, or historical lease data, only the current state of the DHC protocol's configuration. o The schema is designed to allow many of the dhcp configuration objects to be present anywhere in a directory hierarchy. This was done to allow those objects to be placed in the directory for man- aging administrative control and access to the objects. This includes objects like subnets, address ranges, services, clients, etc. There are certain other objects which are assumed to be located under a "dhcpConfiguration" object (simply because it doesn't make sense for them to exist as a management object = without being part of a dhcp configuration). Bennett, et. al. Expires December 1999 [Page = 3] =0C Internet Draft DHCP Schema for LDAP June = 1999 4. Object Class Descriptions This section of the document provides a high level description of = the proposed object classes and how they relate to one another. Also provided is a mapping to the CIM (Common Information Model) DHCP Schema defined by the DMTF. 4.1. Configurations and Services The DHC working group is currently considering several proposals for failover and redundancy of DHCP servers. These may require the = shar- ing of configuration information between servers. This schema pro- vides a generalized mechanism for supporting any of these proposals, by separating the definition of a server from the definition of the configuration being provided by the server. By separating these two concepts, a configuration may be provided by one or by several servers, and similarly, a server may provide one = or more configurations. The schema does allow for a server to be = config- ured as either a primary or secondary provider of a configuration. Configurations are also defined so that one configuration can = include some of the objects that are defined in another configuration. This allows for a hierarchy of related configuration items. 4.1.1. dhcpConfiguration A "dhcpConfiguration" is the collection of configuration information that represents everything a server would need to know to provide = DHC service to some set of clients. From the perspective of an LDAP schema, it is basically a collection of objects. NAME dhcpConfiguration DESCRIPTION This represents a configuration, or a collection of settings for related objects. A single ser- vice may have multiple configurations. A = config- uration may be provided by multiple services, = but only one can be primary. TYPE Structural DERIVED FROM dhcpConfigurableObject POSSIBLE SUPERIORS ( ) MUST CONTAIN ( dhcpConfigurationName ) MAY CONTAIN ( dhcpPrimaryService dhcpSecondaryService dhcpParentConfiguration dhcpIncludeFromParent dhcpLocator ) Bennett, et. al. Expires December 1999 [Page = 4] =0C Internet Draft DHCP Schema for LDAP June = 1999 4.1.1.1. CIM Mapping The DMTF Schema defines a CIM_DHCPConfiguration object (derived from CIM_Configuration) that corresponds to dhcpConfiguration. The CIM class has the following properties: - A Name string that is the object's key, and conceptually is a DN - Description and Caption strings The dhcpConfigurationName string is mapped into the CIM_DHCPConfigu- ration class' Name property, if it satisfies the uniqueness charac- teristics of CIM naming. Otherwise, it should be mapped into the Caption property. The remainder of the dhcpConfiguration properties are mapped to = asso- ciations in the DMTF Schema. The correspondence is as follows: - dhcpPrimaryService and dhcpSecondaryService map to the CIM_Ser- viceForDHCPConfiguration association. This association ties together a CIM_DHCPConfiguration and a CIM_DHCPService, and includes a boolean property to identify the PrimaryService. - dhcpParentConfiguration (subsetted by the dhcpIncludeFromParent property) is defined by instantiating various CIM_DHCPConfigura- tion objects and then grouping them using the CIM_Configura- tionComponent relationship. The aggregation in CIM defines the parts or components of the parent, as opposed to the LDAP DHCP Schema which defines the parent and then subsets it. The dhcpLocator property is unique to the LDAP Schema and has no CIM correspondence. 4.1.2. dhcpService A "dhcpService" is a single instance of DHC server software running on a computer system that provides the DHCP service defined by a "dhcpConfiguration". NAME dhcpService DESCRIPTION This represents a single dhcp server. TYPE Structural DERIVED FROM Top POSSIBLE SUPERIORS ( ) MUST CONTAIN ( dhcpServiceName ) MAY CONTAIN ( dhcpConfiguration dhcpImplementation ) 4.1.2.1. CIM Mapping The DMTF Schema specifies a CIM_DHCPService object (derived from CIM_Service) that corresponds to dhcpService. In CIM, Services are defined and named relative to the System that hosts them. = Therefore, the keys of CIM_DHCPService are defined as: Bennett, et. al. Expires December 1999 [Page = 5] =0C Internet Draft DHCP Schema for LDAP June = 1999 - The hosting System's CreationClassName (for example, CIM_Uni- taryComputerSystem) and Name. - The Service's CreationClassName (=3D "CIM_DHCPService") and = Name. These string properties taken together form the object's key and = con- ceptually are a DN. That CIM_DHCPService is named and scoped by a CIM_System is consis- tent with the definition of a as a "possible superior" of dhcpService. In CIM, this relationship is described using the CIM_HostedService association. CIM_DHCPService also contains the following properties: - Description and Caption strings (inherited from CIM_ManagedSys- temElement) - ImplementationMatchingStrings, an array of strings - Numerous other properties defining runtime characteristics of = the DHCP Service. For example, whether or not the Service provides ProxyDNSSupport (a boolean) or the BootPLeaseLength (a uint32) are properties of CIM_DHCPService. The dhcpServiceName string can be mapped into the CIM_DHCPService class' Name property, if the uniqueness characteristics of CIM = naming are satisfied. Otherwise, it should be mapped into the Caption string. And, the dhcpImplementation multi-valued string can be mapped into the ImplementationMatchingStrings property. The dhcpConfiguration property is mapped to an association, CIM_Ser- viceForDCHPConfiguration, in the DMTF Schema. This association was explained above. 4.2. Addresses and Collections of Addresses The schema provides several object classes for representing configu- ration information based on IP address(es). 4.2.1. dhcpAddress This class represents a DHCP leaseable IP address. It may exist even though a lease is not currently active. Bennett, et. al. Expires December 1999 [Page = 6] =0C Internet Draft DHCP Schema for LDAP June = 1999 NAME dhcpAddress DESCRIPTION This class represents an IP Address, which may = or may not have been leased. TYPE Structural DERIVED FROM dhcpConfigurableObject POSSIBLE SUPERIORS ( dhcpSubnet ) MUST CONTAIN ( dhcpIpAddress dhcpAddressType = dhcpAddressState) MAY CONTAIN ( dhcpDomainName dhcpLastTransactionTime dhcpExpirationTime dhcpStartTimeOfState dhcpRequestedHostName dhcpBootpFlag dhcpAssignedHostName dhcpDnsStatus dhcpReservedForClient dhcpAssignedToClient dhcpRelayAgentInfo ) 4.2.1.1. CIM Mapping The DMTF Schema defines a CIM_DHCPAllocatedEndpoint (a subclass of CIM_ProtocolEndpoint) that corresponds to the dhcpAddress class. However, in CIM, to obtain all the data for an IP address, one must examine several classes. These are: - CIM_DHCPAllocatedEndpoint containing lease specific information - CIM_IPProtocolEndpoint containing address specific data, such as address type and IP version support - CIM_EndpointIdentity, an association instantiated between the CIM_DHCPAllocatedEndpoint and CIM_IPProtocolEndpoint, to tie together these different aspects of the same address - CIM_DHCPAddressAssignment, an association relating a CIM_DHCPAl- locatedEndpoint with a DHCP client Mapping the dhcpAddress properties into the DMTF Schema results in the following list: - dhcpIPAddress =3D CIM_DHCPAllocatedEndpoint.Address string - dhcpAddressType =3D CIM_DHCPAllocatedEndpoint.DHCPAddressType = enu- meration - dhcpAddressState =3D CIM_DHCPAllocatedEndpoint.AddressState = enumer- ation - dhcpDomainName =3D CIM_DHCPAllocatedEndpoint.DomainName string - dhcpLastTransactionTime =3D = CIM_DHCPAllocatedEndpoint.LastTransac- tionTime datetime - dhcpExpirationTime =3D CIM_DHCPAllocatedEndpoint.Expiration = date- time - dhcpStartTimeOfState =3D = CIM_DHCPAllocatedEndpoint.TimeOfLastState- Change datetime - dhcpRequestedHostName =3D CIM_DHCPAllocatedEnd- point.RequestedDNSName string - dhcpBootpFlag =3D CIM_DHCPAllocatedEndpoint.BootPAddress boolean - dhcpAssignedHostName =3D = CIM_DHCPAllocatedEndpoint.AssignedDNSName string Bennett, et. al. Expires December 1999 [Page = 7] =0C Internet Draft DHCP Schema for LDAP June = 1999 - dhcpDnsStatus =3D CIM_DHCPAllocatedEndpoint.DNSStatus = enumeration - dhcpReservedForClient =3D An instance of the = CIM_DHCPAddressAssign- ment association with the Reserved boolean set to TRUE - dhcpAssignedToClient =3D An instance of the = CIM_DHCPAddressAssign- ment association indicating the current lease assignment - dhcpRelayAgentInfo =3D CIM_DHCPAllocatedEndpoint.RelayAgent = octet string To identify CIM_IPProtocolEndpoint or CIM_DHCPAllocatedEndpoint instances, key (naming) properties are needed. Names are defined = rel- ative to the System that hosts the Endpoints. So, the keys of any CIM_ProtocolEndpoint are specified as: - The hosting System's CreationClassName (for example, CIM_Uni- taryComputerSystem) and Name. - The ProtocolEndpoint's CreationClassName (=3D = "CIM_IPProtocolEnd- point" or "CIM_DHCPAllocatedEndpoint") and Name. These string properties taken together form the object's key and = con- ceptually are a DN. Any instances of CIM_ProtocolEndpoints (or instances of its sub- classes) can be members of CIM_LogicalNetworks. This is specified using the CIM_InLogicalNetwork association. Using this association, one can relate CIM_DHCPAllocatedEndpoints and CIM_IPProtocolEnd- points to a CIM_IPSubnet. The InLogicalNetwork association becomes the mapping for the dhcpSubnet "possible superior" relationship to dhcpAddress. 4.2.2. dhcpRangeGroup A "dhcpRangeGroup" represents information about a group of addresses specified by one or more ranges of addresses. If there are multiple ranges specified, they do not need to be contiguous, and it is not required that all the addresses be contained on the same IP subnet. NAME dhcpRangeGroup DESCRIPTION This stores configuration information about one (or more) ranges of addresses. TYPE Structural DERIVED FROM dhcpConfigurableObject POSSIBLE SUPERIORS ( dhcpSubnet ) MUST CONTAIN ( dhcpAddressRange ) MAY CONTAIN ( ) 4.2.2.1. CIM Mapping Different than the LDAP schema, the DMTF Schema defines a CIM_IPAd- dressRange entity to uniquely identify and manipulate ranges. The key properties of the class are its start and end addresses. Bennett, et. al. Expires December 1999 [Page = 8] =0C Internet Draft DHCP Schema for LDAP June = 1999 CIM_IPAddressRanges can be aggregated into CIM_RangeGroups using the CIM_CollectionOfRanges association. Regarding dhcpSubnet being a "possible superior" of dhcpRangeGroup, this is mapped in the DMTF Schema using the CIM_RangeGroupInSubnet aggregation association. 4.2.3. dhcpSubnet A "dhcpSubnet" represents an IP subnet. NAME dhcpSubnet DESCRIPTION This class defines a subnet. TYPE Structural DERIVED FROM dhcpConfigurableObject POSSIBLE SUPERIORS ( dhcpSubnet ) MUST CONTAIN ( dhcpIpAddress dhcpSubnetMaskLength) MAY CONTAIN ( dhcpSubnetName dhcpSharedNetwork ) 4.2.3.1. CIM Mapping The DMTF Schema specifies a CIM_IPSubnet object (derived from CIM_LogicalNetwork) that corresponds to the dhcpSubnet class. The property correspondence is as follows: - dhcpIpAddress =3D CIM_IPSubnet.SubnetNumber - dhcpSubnetMaskLength =3D (mapping is not 1 to 1 in that = CIM_IPSub- net specifies the complete mask, as the SubnetMask property) - dhcpSubnetName =3D CIM_IPSubnet.Name, inherited from = CIM_Logical- Network and part of the key structure for the class The dhcpSubnetName string can be mapped into the CIM_DHCPService class' Name property, only if the uniqueness characteristics of CIM naming are satisfied. Otherwise, it should be mapped into the Cap- tion property. Participation in a SharedNetwork (indicated by the dhcpSharedNetwork attribute in the LDAP Schema) is indicated by the = CIM_SubnetInShared- Network aggregation. This association would relate an instance of CIM_IPSubnet and an instance of CIM_SharedNetwork. Regarding dhcpSubnet being a "possible superior" of another Subnet, this is mapped in the DMTF Schema using the CIM_SubnetInSubnet = aggre- gation association. 4.2.4. dhcpSharedNetwork A "dhcpSharedNetwork" represents multiple subnets on the same physi- cal cabling. Bennett, et. al. Expires December 1999 [Page = 9] =0C Internet Draft DHCP Schema for LDAP June = 1999 NAME dhcpSharedNetwork DESCRIPTION A class represents multiple subnets on the same physical cabling. TYPE Structural DERIVED FROM dhcpConfigurableObject POSSIBLE SUPERIORS ( ) MUST CONTAIN ( ) MAY CONTAIN ( dhcpSharedNetworkName ) 4.2.4.1. CIM Mapping CIM_SharedNetwork (subclassed from CIM_CollectionOfMSEs) is defined in the DMTF Schema to correspond to the dhcpSharedNetwork class. A property of the CIM_SharedNetwork class, Name (its key), maps the dhcpSharedNetworkName information. This mapping is allowed if the dhcpSharedNetworkName satisfies the uniqueness characteristics of = CIM naming. Otherwise, the Name data should be mapped into the CIM_SharedNetwork.Caption property, inherited from = CIM_CollectionOfM- SEs. 4.3. dhcpClass A "dhcpClass" represents information about a collection of clients. The DHC protocol provides 2 mechanisms for managing this information (User Class and Vendor Class). The schema also provides 2 = additional mechanisms for configuring groups of clients that are supported by some servers. A "Client Group" is simply a list of clients that are in the specified class. A "Client Class" is more dynamic - the = class is defined by listing a set of "characteristics" that must be = matched by a client in order to be associated with the class. Each client has a list of its own characteristics and the members of the class are those clients whose characteristics match the class's selection criteria. NAME dhcpClass DESCRIPTION Represents information about a collection of related clients. TYPE Structural DERIVED FROM dhcpConfigurableObject POSSIBLE SUPERIORS ( dhcpConfiguration ) MUST CONTAIN ( dhcpClassName dhcpClassType ) MAY CONTAIN ( dhcpClassCharacteristics dhcpUserClass dhcpVendorClass ) 4.3.1. CIM Mapping The DMTF Schema defines CIM_DHCPClientCollection (derived from CIM_CollectionOfMSEs) to correspond to dhcpClass. In the Bennett, et. al. Expires December 1999 [Page = 10] =0C Internet Draft DHCP Schema for LDAP June = 1999 CIM_DHCPClientCollection object, UserClass and VendorClass informa- tion is individually called out (addressing the DHC protocol mecha- nisms for determining a collection of clients). Also, it is permis- sible to define other membership Characteristics, as well as to = spec- ify explicit membership. In CIM, properties can be left unde- fined/unspecified. Therefore, if the UserClass, VendorClass or = other Characteristics are not applicable, they can be left NULL (unde- fined). The mapping of properties from dhcpClass to CIM_DHCPClientCollection is straightforward. - dhcpClassName corresponds to the CIM_DHCPClientCollection's Name property ( if CIM naming requirements for uniqueness are met). Otherwise, dhcpClassName should be mapped into the Caption prop- erty, inherited from CIM_CollectionOfMSEs. - dhcpClassType is mapped to the CollectionType enumeration. - dhcpClassCharacteristics corresponds to the Characteristics string array property. - dhcpUserClass and dhcpVendorClass map to the UserClass and Ven- dorClass string arrays, respectively. Explicit membership by a client in a particular instance of = CIM_DHCP- ClientCollection is specified using the CIM_DHCPEndpointCollection aggregation association. (In the LDAP Schema, this is defined by placing the DN of the dhcpClass in the client's dhcpMemberOfGroup attribute.) CIM_DHCPEndpointCollection is also useful when = enumerat- ing the client members of a Collection, after evaluation of the = User- Class, VendorClass and Characteristics requirements. Regarding dhcpConfiguration as a "possible superior" for dhcpClass, this is mapped in the DMTF Schema as an instance of the CIM_Collec- tionConfiguration association. The association would be = instantiated to reference the CIM_DHCPClientCollection and the appropriate CIM_DHCPConfiguration. 4.4. dhcpNamedOptionSet A "dhcpNamedOptionSet" is an object class for associating a name = with a collection of option settings. The entire set of options can be associated with a dhcp object by referring to the name. This allows a common set of option settings to be re-used without repeating the option settings on each configured object. Bennett, et. al. Expires December 1999 [Page = 11] =0C Internet Draft DHCP Schema for LDAP June = 1999 NAME dhcpNamedOptionSet DESCRIPTION This is a named collection of settings for options and/or server parameters. TYPE Structural DERIVED FROM dhcpConfigurableObject POSSIBLE SUPERIORS ( dhcpConfiguration ) MUST CONTAIN ( dhcpConfiguration dhcpOptionSetName ) MAY CONTAIN ( ) 4.4.1. CIM Mapping In the DMTF Schema, the CIM_DHCPOptionConfiguration object corre- sponds to the dhcpNamedOptionSet class. dhcpOptionSetName is mapped into the Name property (a key property) of the CIM class. This is acceptable if dhcpOptionSetName meets CIM's requirements for unique- ness. Otherwise, its data should be placed into the Caption prop- erty, inherited from CIM_Configuration. If the instance of CIM_DHCPOptionConfiguration is part of a higher level CIM_DHCPConfiguration, this is indicated by instantiating the CIM_ConfigurationComponent association and referencing both Configu- rations. 4.5. dhcpClient The "dhcpClient" object class is used to store configuration = informa- tion related to a specific host. This is defined as an auxiliary class since it is assumed that many clients may also be defined in the directory as a Computer object (or some similar object class). These objects can be created to manage the configuration or they may also be created by a DHCP server in order to track lease information in conjunction with the dhcpAddress object. NAME dhcpClient DESCRIPTION This is an auxiliary class for indicating that = an object is a dhcp client. TYPE Auxiliary DERIVED FROM dhcpConfigurableObject POSSIBLE SUPERIORS ( ) MUST CONTAIN ( dhcpClientIdentifier ) MAY CONTAIN ( dhcpUserClass dhcpVendorClass dhcpAssignedAddress dhcpMemberOfGroup dhcpCharacteristics dhcpCreatedByServer ) 4.5.1. CIM Mapping The DMTF Schema defines a CIM_DHCPClientEndpoint object (derived = from CIM_ProtocolEndpoint) that corresponds to dhcpClient. The CIM class Bennett, et. al. Expires December 1999 [Page = 12] =0C Internet Draft DHCP Schema for LDAP June = 1999 maps the LDAP Schema properties as follows: - dhcpClientIdentifier =3D DHCPClientID string - dhcpUserClass =3D UserClass string array - dhcpVendorClass =3D VendorClass string - dhcpCharacteristics =3D Characteristics string array - dhcpCreatedByServer =3D CreatedForUnlistedClient boolean The remainder of the dhcpClient properties are mapped to = associations in the DMTF Schema. The correspondence is as follows: - Information in dhcpAssignedAddress is mapped to the CIM_DHCPAd- dressAssignment association, relating CIM_DHCPClientEndpoint = and CIM_DHCPAllocatedEndpoint (as discussed in Section 3.2.1) - Information in dhcpMemberOfGroup is mapped to the CIM_DHCPEnd- pointCollection association, relating CIM_DHCPClientEndpoint and CIM_DHCPClientCollection (as discussed in Section 3.3 To identify instances of CIM_DHCPClientEndpoint, key (naming) = proper- ties are needed. Names are defined relative to the System that hosts the Endpoints. So, the keys of any CIM_ProtocolEndpoint are = specified as: - The hosting System's CreationClassName (for example, CIM_Uni- taryComputerSystem) and Name, - The ProtocolEndpoint's CreationClassName (=3D = "CIM_DHCPClientEnd- point") and Name. These string properties taken together form the object's key and = con- ceptually are a DN. 4.6. Dictionary Objects The schema provides several object classes which are used to define site-specific or implementation-specific customizations without requiring schema extensions. This is done by defining a = "dictionary" of the types of Options and Parameters. 4.6.1. dhcpOptionDictionary "dhcpOptionDictionary" objects define the options that can be set when configuring various DHCP entities. Bennett, et. al. Expires December 1999 [Page = 13] =0C Internet Draft DHCP Schema for LDAP June = 1999 NAME dhcpOptionDictionary DESCRIPTION This class defines an option that can have a value. TYPE Structural DERIVED FROM Top POSSIBLE SUPERIORS ( dhcpConfiguration ) MUST CONTAIN ( dhcpConfigurationName dhcpOptionName dhcpOptionTag dhcpDataType ) MAY CONTAIN ( dhcpMultiValued dhcpDefault dhcpVendorClass dhcpDescription dhcpLegalValues dhcpTypeRestriction ) 4.6.1.1. CIM Mapping The DMTF Schema defines a CIM_DHCPOptionDictionary object (derived from CIM_Setting) that corresponds to dhcpOptionDictionary. Instances of CIM_DHCPOptionDictionary may be grouped by CIM_DHCPCon- figurations using the CIM_SettingContext association. This associa- tion aggregates one or more Settings into a Configuration, and = corre- sponds to the definition of dhcpConfiguration as a "possible supe- rior" of dhcpOptionDictionary. It also is the mapping for the dhcp- ConfigurationName string attribute. The property values of the CIM_DHCPOptionDictionary class map = one-to- one to those of dhcpOptionDictionary. The explicit mapping is: - dhcpOptionName =3D OptionName string - dhcpOptionTag =3D OptionTag uint32 - dhcpDataType =3D DataType enumeration - dhcpMultiValued =3D MultiValued boolean - dhcpDefault =3D DefaultValue octet string - dhcpVendorClass =3D VendorClass string - dhcpDescription =3D Description string, inherited from = CIM_Setting - dhcpLegalValues =3D LegalValues octet string - dhcpTypeRestriction =3D RestrictedTo enumerated integer array To identify instances of CIM_DHCPOptionDictionary, one or more key (naming) properties are needed. The key of CIM_DHCPOptionDictionary is specified as its SettingID (a string). This property conceptually is a DN. 4.6.2. dhcpParameterDictionary "dhcpParameterDictionary" objects define server parameters that can be defined to customize a server's behavior. Bennett, et. al. Expires December 1999 [Page = 14] =0C Internet Draft DHCP Schema for LDAP June = 1999 NAME dhcpParameterDictionary DESCRIPTION This class defines server parameters that can be set to control the server behavior. TYPE Structural DERIVED FROM Top POSSIBLE SUPERIORS ( dhcpConfiguration ) MUST CONTAIN ( dhcpConfigurationName dhcpParameterName dhcpDataType ) MAY CONTAIN ( dhcpMultiValued dhcpDefault dhcpImplementation dhcpDescription dhcpLegalValues dhcpTypeRestriction ) 4.6.2.1. CIM Mapping The DMTF Schema defines a CIM_DHCPParameterDictionary object = (derived from CIM_Setting) that corresponds to dhcpParameterDictionary. Instances of CIM_DHCPParameterDictionary may be grouped by CIM_DHCP- Configurations using the CIM_SettingContext association. This asso- ciation aggregates one or more Settings into a Configuration, and corresponds to the definition of dhcpConfiguration as a "possible superior" of dhcpParameterDictionary. It also is the mapping for = the dhcpConfigurationName string attribute. The property values of the CIM_DHCPParameterDictionary class map = one- to-one to those of dhcpParameterDictionary. The explicit mapping is: - dhcpParameterName =3D ParameterName string - dhcpDataType =3D DataType enumeration - dhcpMultiValued =3D MultiValued boolean - dhcpDefault =3D DefaultValue octet string - dhcpImplementation =3D ImplementationMatchingStrings string = array - dhcpDescription =3D Description string, inherited from = CIM_Setting - dhcpLegalValues =3D LegalValues octet string - dhcpTypeRestriction =3D RestrictedTo enumerated integer array To identify instances of CIM_DHCPParameterDictionary, one or more = key (naming) properties are needed. The key of = CIM_DHCParameterDictionary is specified as its SettingID (a string). This property conceptually is a DN. 4.7. dhcpConfigurableObject Many of the object classes represent objects that are configurable within DHCP, and therefore have a common set of attributes. Instead of repeating these throughout the schema on each class, we have defined an abstract class "dhcpConfigurableObject" where we define the basic, common set of attributes for configuring dhcp objects. Most of the other DHCP object classes are derived from this class. Bennett, et. al. Expires December 1999 [Page = 15] =0C Internet Draft DHCP Schema for LDAP June = 1999 NAME dhcpConfigurableObject DESCRIPTION An abstract class that provides attributes for configuring options and server parameters for various DHCP object classes. TYPE Abstract DERIVED FROM Top POSSIBLE SUPERIORS ( ) MUST CONTAIN ( ) MAY CONTAIN ( dhcpOptionSetting dhcpParameterSetting dhcpFieldSetting dhcpIncludeOptionSet dhcpConfiguration dhcpForcedOptions ) 4.7.1. CIM Mapping The DMTF Schema maps the setting and parameter data in the dhcpCon- figurableObject class using instances of CIM_Setting classes and associations. The individual dhcpOption, Parameter and Field Settings are = instances of the CIM_DHCPSetting class (derived from CIM_Setting). The CIM_DHCPSetting class defines key properties and an octet string to hold the OptionData. The CIM_DHCPSetting instances are associated with the various subclasses of dhcpConfigurableObject using the CIM_ElementSetting, CIM_SettingContext or CIM_CollectionSetting = rela- tionships. (Which association is used depends on the derivation of the dhcpConfigurableObject in the CIM class hierarchy.) The individual dhcpConfigurations and dhcpIncludeOptionSets are instances of the CIM_DHCPConfiguration class or of its subclass, CIM_DHCPOptionConfiguration (both classes were discussed earlier in this document). The CIM_DHCPConfiguration instances are associated with the various subclasses of dhcpConfigurableObject using the CIM_ElementConfiguration, CIM_ConfigurationComponent or CIM_Collec- tionConfiguration relationships. (As above, the association that to be used depends on the derivation of the dhcpConfigurableObject in the CIM class hierarchy.) dhcpForcedOptions is mapped to the CIM_DHCPForcedOptions class (derived from CIM_Setting). CIM_DHCPForcedOptions defines key prop- erties and an integer array to hold the option tags being "forced". It is associated with the various subclasses of dhcpConfigurableOb- ject using the CIM_ElementSetting, CIM_SettingContext or CIM_Collec- tionSetting relationships. (As above, the association that is used depends on the derivation of the dhcpConfigurableObject in the CIM class hierarchy.) Since the CIM_DHCPSetting and CIM_DHCPForcedOptions classes were not discussed previously, a brief overview of their properties is = needed. Bennett, et. al. Expires December 1999 [Page = 16] =0C Internet Draft DHCP Schema for LDAP June = 1999 Both classes contain only key properties for identification, plus = one additional property in each object. The CIM_DHCPSetting class has = an octet string to hold the option, parameter or field data. The CIM_DHCPForcedOptions class has an integer array holding option = tags. The key properties of CIM_DHCPSetting and CIM_DHCPForcedOptions are: - ConfiguredObject, a string identifying the entity to which the Setting or ForcedOptions applies - SettingID, a string identifier for the instance - For CIM_DHCPSetting only, a SettingType enumerated integer = defin- ing whether an option, parameter or field setting is specified. These string properties taken together form the objects' key and = con- ceptually are a DN. 4.8. Object Classes not defined in this schema There are some object classes which are not defined in this schema but we have assumed they exist in the directory. A few in = particular are worth mentioning: is a general = refer- ence to object classes that are present in most directories that are used for creating an administrative hierarchy to manage objects. Examples include Organization (O), OrganizationalUnit (OU), Country (C), etc. Also, it is assumed that some type of object class is = pre- sent for representing a computer, or computer system - this is referred to as in some places in this document. 5. Object Containment These diagrams depict the containment hierarchy of the objects: | +---dhcpConfiguration | +---dhcpOptionDictionary | +---dhcpParameterDictionary | +---dhcpNamedOptionSet | +---dhcpClass Bennett, et. al. Expires December 1999 [Page = 17] =0C Internet Draft DHCP Schema for LDAP June = 1999 | +---dhcpRangeGroup | +---dhcpSubnet | +---dhcpAddress | +---dhcpService 6. Object Class Inheritance The following diagram shows the inheritance hierarchy of the = classes: Top | +---dhcpOptionDictionary | +---dhcpParameterDictionary | +---dhcpService | +---dhcpConfigurableObject | +---dhcpAddress | +---dhcpClass | +---dhcpClient | +---dhcpConfiguration | +---dhcpNamedOptionSet | +---dhcpRangeGroup | +---dhcpSharedNetwork | +---dhcpSubnet Bennett, et. al. Expires December 1999 [Page = 18] =0C Internet Draft DHCP Schema for LDAP June = 1999 7. Attribute Definitions These are the definitions of the attributes: NAME dhcpAddressRange DESCRIPTION The starting & ending IP Addresses in a range, = separated by a hyphen. Each range is defined as an independent string. SYNTAX String MULTI-VALUE NAME dhcpAddressState DESCRIPTION This stores information about the current = binding-status of an address, using the states defined in the safe- failover draft. For more information see [FAILOVR]. SYNTAX Integer SINGLE-VALUE NAME dhcpAddressType DESCRIPTION This describes how an address is to be assigned to a client. There will be a limited set of values for this attribute. For example: Unknown, Dynamic, Fixed, Unas- signed, Should Not Be Assigned. SYNTAX Integer SINGLE-VALUE NAME dhcpAssignedAddress DESCRIPTION The distinguished name of the dhcpAddress object which has been assigned to a client. SYNTAX DN MULTI-VALUE NAME dhcpAssignedHostName DESCRIPTION This is the actual hostname that was assigned to a client. It may not be the name that was requested by = the client. The fully qualified domain name can be deter- mined by appending the value of "dhcpDomainName" (with = a dot separator) to this name. SYNTAX String SINGLE-VALUE NAME dhcpAssignedToClient DESCRIPTION This is the distinguished name of a "dhcpClient" that = an address is currently assigned to. This only has a = value when the address is leased. SYNTAX DN SINGLE-VALUE NAME dhcpBootpFlag DESCRIPTION This indicates whether an address is assigned via BOOTP SYNTAX Boolean SINGLE-VALUE Bennett, et. al. Expires December 1999 [Page = 19] =0C Internet Draft DHCP Schema for LDAP June = 1999 NAME dhcpCharacteristics DESCRIPTION This is a list of characteristics for a client that can be used to determine if the client is a member of any = of the defined dhcpClass(es) of type "ClientClass". Mem- bership is defined by comparison of the client's dhcpCharacteristics attribute with the dhcpClassCharac- teristics attribute of dhcpClass. SYNTAX String MULTI-VALUE NAME dhcpClassCharacteristics DESCRIPTION This is a set of characteristics for a dhcpClass object that should be matched by a client in order to be con- sidered a member of the class. If there is more than = one characteristic specified then they must all be matched. A client's dhcpCharacteristics are found in the dhcp- Client class. SYNTAX String MULTI-VALUE NAME dhcpClassName DESCRIPTION The name of a dhcpClass. SYNTAX String SINGLE-VALUE NAME dhcpClassType DESCRIPTION This is the type of a dhcpClass. One of: VendorClass, UserClass, ClientGroup, ClientClass, Combination. A ClientGroup is an enumerated list of clients (see the dhcpMemberOfGroup attribute in dhcpClient class). A ClientClass is dynamic - membership in the class is determined by matching dhcpCharacteristics of a client with match criteria specified by the class (using the dhcpClassCharacteristics attribute). SYNTAX Integer SINGLE-VALUE NAME dhcpClientIdentifier DESCRIPTION The DHCP client identifier used by the configuration to identify a client. This is either the MAC address = (pre- fixed with the media type) or the DHCP client = identifier for the client. SYNTAX String SINGLE-VALUE NAME dhcpConfiguration DESCRIPTION The distinguished name(s) of the configurations = provided by a server. SYNTAX DN MULTI-VALUE Bennett, et. al. Expires December 1999 [Page = 20] =0C Internet Draft DHCP Schema for LDAP June = 1999 NAME dhcpConfigurationName DESCRIPTION The name of the configuration that contains this = object. SYNTAX String SINGLE-VALUE NAME dhcpCreatedByServer DESCRIPTION This attribute indicates if an object was created by = the DHCP server (and can therefore be removed by the server when it is no longer needed). This can be applied to dhcpClient objects that are created for the life of a lease to record additional information beyond what is recorded in the dhcpAddress object. If the attribute has no value it is assumed to be FALSE. SYNTAX Boolean SINGLE-VALUE NAME dhcpDataType DESCRIPTION The data type for values of this option. The set of valid data types are defined by the DHCP protocol. For more information see [RFC2131]. SYNTAX Integer SINGLE-VALUE NAME dhcpDefault DESCRIPTION Indicates the default value of a parameter or option definition in a dictionary object. This is encoded the same way as the parameter or option value would be set in the dhcpConfigurableObject object class. SYNTAX OctetString SINGLE-VALUE NAME dhcpDescription DESCRIPTION A textual description of an object. SYNTAX String SINGLE-VALUE NAME dhcpDnsStatus DESCRIPTION This indicates which resource records were added to the domain on behalf of the client by the dhcp server. The allowed values are: "No DNS Activity", "Update A Records", "Update PTR Records", and "Update Both A and PTR Records" SYNTAX Integer SINGLE-VALUE NAME dhcpDomainName DESCRIPTION This is the name of the domain assigned to a client by the server. SYNTAX String SINGLE-VALUE Bennett, et. al. Expires December 1999 [Page = 21] =0C Internet Draft DHCP Schema for LDAP June = 1999 NAME dhcpExpirationTime DESCRIPTION This is the time the current lease for an address expires. SYNTAX DateTime SINGLE-VALUE NAME dhcpFieldSetting DESCRIPTION Encoded settings of fields (such as siaddr, file) in = the DHCP message whose values may be configurable for send- ing back to a client. For more information see [RFC951]. Encoded in the form (FieldName, FieldValue). SYNTAX OctetString MULTI-VALUE NAME dhcpForcedOptions DESCRIPTION This is a list of dhcp option tags that MUST be sent to clients. If not specified, the server only sends the options back to the client which were requested. SYNTAX Integer MULTI-VALUE NAME dhcpImplementation DESCRIPTION If this is a dictionary object that only applies to = cer- tain server implementations these are the implementa- tion(s) that it applies to. SYNTAX String MULTI-VALUE NAME dhcpIncludeFromParent DESCRIPTION This attribute defines the type of objects that should be included from the parent configuration. It is lim- ited to the following values: OptionDictionary, Parame- terDictionary, GlobalOptions, NamedOptionSets, Classes, Characteristics. SYNTAX Integer MULTI-VALUE NAME dhcpIncludeOptionSet DESCRIPTION The name(s) of dhcpNamedOptionSet objects whose = settings should be included for this object. If there are = multi- ple values the order in which the option sets are checked is important so each value is preceded by it's precedence, followed by a colon as in "1:name1", "2:name2", etc. Any optionSettings defined locally on this object take precedence over any settings found in = a named option set. SYNTAX String MULTI-VALUE NAME dhcpIpAddress DESCRIPTION A DHCP leasable IP address. SYNTAX String SINGLE-VALUE Bennett, et. al. Expires December 1999 [Page = 22] =0C Internet Draft DHCP Schema for LDAP June = 1999 NAME dhcpLastTransactionTime DESCRIPTION This is the last time a valid DHCP packet was received from a client. SYNTAX DateTime SINGLE-VALUE NAME dhcpLegalValues DESCRIPTION The list of allowed values for a dictionary entry (such as an option definition or parameter definition). SYNTAX OctetString MULTI-VALUE NAME dhcpLocator DESCRIPTION This attribute defines the objects that are included in a configuration. Each value is an LdapURL [RFC2255] (specifying search criteria) that is evaluated to find other objects that are included in this configuration. Note that in addition to these objects, all objects located "under" the configuration object in the direc- tory are also automatically include in the configura- tion. SYNTAX String MULTI-VALUE NAME dhcpMemberOfGroup DESCRIPTION This is a list of distinguished names for any dhcp- Class(es) to which a client belongs. SYNTAX DN MULTI-VALUE NAME dhcpMultiValued DESCRIPTION Indicates whether a parameter or option can have more than one value. SYNTAX Boolean SINGLE-VALUE NAME dhcpOptionName DESCRIPTION The name of a option. SYNTAX String SINGLE-VALUE NAME dhcpOptionSetName DESCRIPTION This is the name of a "Named Option Set" (see dhcpName- dOptionSet class). SYNTAX String SINGLE-VALUE NAME dhcpOptionSetting DESCRIPTION Encoded option values to be sent to clients. Each = value represents a single option and contains (OptionTag, Length, OptionValue) stored in the 16-bit format used = by the dhcp protocol. For more information see [DHCPOPT]. SYNTAX OctetString MULTI-VALUE Bennett, et. al. Expires December 1999 [Page = 23] =0C Internet Draft DHCP Schema for LDAP June = 1999 NAME dhcpOptionTag DESCRIPTION The numeric tag that identifies an option. SYNTAX Integer SINGLE-VALUE NAME dhcpParameterName DESCRIPTION The name of a parameter. SYNTAX String SINGLE-VALUE NAME dhcpParameterSetting DESCRIPTION Encoded values of parameters that control server behav- ior. Each value represents a single parameter setting in the form (ParameterName, ParameterValue). SYNTAX OctetString MULTI-VALUE NAME dhcpParentConfiguration DESCRIPTION This is the distininguished name of a "dhcpConfigura- tion" object. When this is set some of the parent con- figuration's objects may be referenced in this configu- ration. This allows for an administrative hierarchy of related configurations. SYNTAX DN SINGLE-VALUE NAME dhcpPrimaryService DESCRIPTION The "dhcpService" which is the primary for a configura- tion. SYNTAX DN SINGLE-VALUE NAME dhcpRelayAgentInfo DESCRIPTION If the client request was received via a relay agent, this attribute contains information about the relay agent that was available from the DHCP request. This = is a hex-encoded option value. For more information see [RELAY]. SYNTAX OctetString SINGLE-VALUE NAME dhcpRequestedHostName DESCRIPTION This is the hostname that was requested by a client. SYNTAX String SINGLE-VALUE NAME dhcpReservedForClient DESCRIPTION This is the distinguished name of a "dhcpClient" that = an address is reserved for. This may not be the same as the "dhcpAssignedToClient" attribute if the address is being reassigned but the current lease has not yet expired. SYNTAX DN SINGLE-VALUE Bennett, et. al. Expires December 1999 [Page = 24] =0C Internet Draft DHCP Schema for LDAP June = 1999 NAME dhcpSecondaryService DESCRIPTION The "dhcpService(s)" which provide backup for a = configu- ration. SYNTAX DN MULTI-VALUE NAME dhcpServiceName DESCRIPTION The name of a server (aka dhcpService). SYNTAX String SINGLE-VALUE NAME dhcpSharedNetwork DESCRIPTION A unique identifier for a shcpSharedNetwork that this subnet may be part of. This is the distinguished name of an object which represents the shared-network. SYNTAX DN SINGLE-VALUE NAME dhcpSharedNetworkName DESCRIPTION The name of a shared network. SYNTAX String SINGLE-VALUE NAME dhcpStartTimeOfState DESCRIPTION This is the time of the last state change for a leased address. SYNTAX DateTime SINGLE-VALUE NAME dhcpSubnetMaskLength DESCRIPTION The subnet mask length for a subnet. The actual mask can be easily computed from this length. SYNTAX Integer SINGLE-VALUE NAME dhcpSubnetName DESCRIPTION A descriptive name of a subnet. SYNTAX String SINGLE-VALUE NAME dhcpTypeRestriction DESCRIPTION This attribute is used to specify that an option or parameter (see dictionary objects) should only be used with specific types of objects. If not defined, the option/parameter can be used on any object. Values should be one of: Any, Other, Address, Class, Client, Configuration, RangeGroup, SharedNetwork, Subnet. SYNTAX Integer MULTI-VALUE NAME dhcpUserClass DESCRIPTION The DHCP user class associated with a client. SYNTAX String MULTI-VALUE Bennett, et. al. Expires December 1999 [Page = 25] =0C Internet Draft DHCP Schema for LDAP June = 1999 NAME dhcpVendorClass DESCRIPTION The DHCP vendor class associated with a client. SYNTAX String SINGLE-VALUE 8. References [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC = 2131, March 1997. [RFC2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [DMTF] Distributed Management Task Force, "Common Information Model (CIM) Specification", Version 2.0, Mar 1998. [DEN] Strassner, J., "Directory-Enabled Networks, Information Model and Base Schema", DEN Specification v3.0c, July = 1998. [MSDHCP] Gu, Y., Vyaghrapuri, R., "An LDAP Schema for Dynamic Host Configuration Protocol Service", Internet Draft , August 1998. [NOVDHCP] Miller, T., Patel, A., Rao, P., "Lightweight Directory Access Protocol (v3): Schema for Dynamic Host = Configuration Protocol (DHCP)", Internet Draft , June 1998. [FAILOVR] Droms, R., Rabil, G., Dooley, M., Kapur, A., Gonczi, S., Volz, B., "DHCP Failover Protocol", Internet Draft , November 1998. [RELAY] Patrick, M., "DHCP Relay Agent Information Option", Inter- net Draft , November 1998. [DHCPOPT] Carney, M., "New Option Review Guidelines and Additional Option Namespace", Internet Draft , June 1999. [RFC2251] Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [RFC2255] Howes, T., Smith, M., "The LDAP URL Format", RFC 2255, December 1997. [RFC951] Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", RFC 951, September 1985. Bennett, et. al. Expires December 1999 [Page = 26] =0C Internet Draft DHCP Schema for LDAP June = 1999 [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate = Require- ment Levels", RFC 2119, March 1997. 9. Acknowledgements This document is closely aligned with the work being done in the Distributed Management Task Force (DMTF) Networks working group. Design ideas included in this document are primarily based on = dis- cussions during two meetings with some members of the IETF DHC Working Group and the DMTF Networks working group. The contribu- tions of these individuals is gratefully acknowledged. Special thanks to Lee Rafalow, Steve Gonczi, Steve Chirokas, Kim Kinnear, Ellen Stokes, Tom Miller, Ye Gu, Glenn Waters, Mike Car- ney, Ralph Droms, Greg Rabil and Steve Bazyl for their contribu- tions. Thanks also to Ester Burwell, Andy Sudduth, Fred Hunter, Paul = Rai- son, Josh Littlefield, Peter Heitman, Neil Russell and Linda = Scobo for their participation in these meetings. 10. Author information Andy Bennett Bernie Volz Process Software Corporation 959 Concord St. Framingham, MA 01701 Phone: (508) 879-6994 Email: bennett@process.com Email: volz@process.com Andrea Westerinen Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: +1 425-705-2553 Email: andreawe@microsoft.com 11. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without Bennett, et. al. Expires December 1999 [Page = 27] =0C Internet Draft DHCP Schema for LDAP June = 1999 restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to = the Internet Society or other Internet organizations, except as = needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into = lan- guages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGI- NEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR = PURPOSE. Bennett, et. al. Expires December 1999 [Page = 28] ------ =_NextPart_000_01BEBF4D.E67724EC-- ------- From dhcp-v4@bucknell.edu Mon Jun 28 14:04: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 OAA08567 for ; Mon, 28 Jun 1999 14:04:10 -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 OAA16371; Mon, 28 Jun 1999 14:03:19 -0400 (EDT) Date: Mon, 28 Jun 1999 14:03:19 -0400 (EDT) Message-Id: <199906281750.NAA10646@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: I-D ACTION:draft-ietf-dhc-option-review-and-namespace-00.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 : New Option Review Guidelines and Additional Option Namespace Author(s) : M. Carney Filename : draft-ietf-dhc-option-review-and-namespace-00.txt Pages : 13 Date : 25-Jun-99 This document outlines deficiencies that have become evident since RFC 2131 and RFC 2132 were published regarding the allocation of new option codes, the review of drafts covering these new option codes, and the availability of option codes for new parameters. The document then presents proposals for correcting these deficiencies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-option-review-and-namesp ace-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-option-review-and-namespace-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-option-review-and-namespace-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19990625135306.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-option-review-and-namespace-00.txt From dhcp-v4@bucknell.edu Wed Jun 30 08:49: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 IAA15456 for ; Wed, 30 Jun 1999 08:49:27 -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 IAA11377; Wed, 30 Jun 1999 08:48:46 -0400 (EDT) Date: Wed, 30 Jun 1999 08:48:46 -0400 (EDT) Message-Id: <199906301247.IAA30517@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: I-D ACTION:draft-ietf-dhc-authentication-11.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 : Authentication for DHCP Messages Author(s) : R. Droms, W. Arbaugh Filename : draft-ietf-dhc-authentication-11.txt Pages : 15 Date : 29-Jun-99 The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. In some situations, network administrators may wish to constrain the allocation of addresses to authorized hosts. Additionally, some network administrators may wish to provide for authentication of the source and contents of DHCP messages. This document defines a new DHCP option through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-authentication-11.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-authentication-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-authentication-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19990629142230.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-authentication-11.txt From dhcp-v4@bucknell.edu Wed Jun 30 08:53: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 IAA15613 for ; Wed, 30 Jun 1999 08:53: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 IAA29718; Wed, 30 Jun 1999 08:53:29 -0400 (EDT) Date: Wed, 30 Jun 1999 08:53:29 -0400 (EDT) Message-Id: <199906301247.IAA03153@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: I-D ACTION:draft-ietf-dhc-schema-00.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 Schema for LDAP Author(s) : A. Bennett, B. Volz, A. Westerinen Filename : draft-ietf-dhc-schema-00.txt Pages : 28 Date : 29-Jun-99 This document presents an LDAP schema to represent the configuration of the DHCP protocol within a TCP/IP network. It can be used to represent the configuration(s) of an entire enterprise network, a subset of the network, or even a single server A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-schema-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-schema-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-schema-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19990629142242.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-schema-00.txt From dhcp-v4@bucknell.edu Wed Jun 30 13:30: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 NAA22094 for ; Wed, 30 Jun 1999 13:30: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 NAA21285; Wed, 30 Jun 1999 13:29:50 -0400 (EDT) Date: Wed, 30 Jun 1999 13:29:50 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: Vipul.Gupta@Eng.Sun.COM Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Vipul Gupta To: Multiple recipients of list Subject: New draft X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii Mime-Version: 1.0 Due to an apparent mix-up, the announcement for this draft was posted to the Mobile IP mailing list rather than the DHCP mailing list. thanks for your time, vipul --------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Flexible Authentication for DHCP Messages Author(s) : V. Gupta Filename : draft-gupta-dhcp-auth-00.txt Pages : 11 Date : 29-Jun-99 This memo proposes minor extensions to the draft by Droms and Arbaugh [DrAr98] with the aim of offering greater flexibility in authenticating Dynamic Host Configuration Protocol (DHCP) messages. In particular, these changes add support for digital signatures to the existing support for keyed hashes. The use of digital signatures simplifies key management and also allows authentication of mobile clients that roam between different administrative domains. This proposal also includes hooks to support multiple forms of replay detection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gupta-dhcp-auth-00.txt -- Vipul Gupta, Ph.D. (Networking and Security Center, Sun Labs) Sun Microsystems, Inc Phone: +1-650-786-3614 901 San Antonio Road, MS UMPK15-214 Fax: +1-650-786-6445 Palo Alto, CA 94303 (USA) Email: vgupta@eng.sun.com