From dhcp-v4@bucknell.edu Thu Jul 1 08:42: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 IAA28648 for ; Thu, 1 Jul 1999 08:42:23 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA21213; Thu, 1 Jul 1999 08:41:40 -0400 (EDT) Date: Thu, 1 Jul 1999 08:41:40 -0400 (EDT) Message-Id: <199907011228.IAA26621@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-failover-04.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 Failover Protocol Author(s) : R. Droms, K. Kinnear, M. Stapp, B. Volz, S. Gonczi, G. Rabil, M. Dooley, A. Kapur Filename : draft-ietf-dhc-failover-04.txt Pages : 100 Date : 30-Jun-99 DHCP [RFC 2131] allows for multiple servers to be operating on a single network. Some sites are interested in running multiple servers in such a way so as to provide redundancy in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information. This implies that servers will need to coordinate any and all lease activity so that this information is synchronized in case of failover. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-failover-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-failover-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-failover-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19990630145923.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-failover-04.txt From dhcp-v4@bucknell.edu Thu Jul 1 11:40: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 LAA06120 for ; Thu, 1 Jul 1999 11:40: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 LAA09048; Thu, 1 Jul 1999 11:39:54 -0400 (EDT) Date: Thu, 1 Jul 1999 11:39:54 -0400 (EDT) Message-Id: <199907011455.KAA29337@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: 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.2 Mike, I was reading over draft-ietf-dhc-option-review-and-namespace-00.txt. Nice job! I had several questions and comments: 1. What about a new message type? What category would the INFORM message go into if we didn't already have one? Does a new message type fit into this category scheme at all? I wouldn't bring it up if it wasn't defined by a new value defined for an existing option, but since it is... 2. I remember that the DHCP ?R5? options were supposed to overmap the new 16 bit options. Was that in there and I missed it, or was it only implicit? If it is supposed to be there it might make sense to highlight it, and if it isn't -- what *are* we doing about the issue? 3. In section 2.1, you have a table of implicit/explict option relationships. The first entry in this table is "Client class". I think you mean option 60, which used to be called Client Class in some older draft, but in 2132 is called (more correctly and less confusingly, I think) Vendor Class Identifier (page 29). 4. Section 3.3 says "two implementations", but I thought that was for Category 2 or 3 options only, that category 1 options didn't need 2 or more implementations. If what I think is true, then fix section 3.3, if what I think is false, then fix section 2.2 which agrees with what I remember. 5. Section 3.7, #2. IPv6 Addresses. I'm a bit confused here. We don't just do the 16 octets, but rather turn these into text? 6. Section 3.7, #3. Would you include Relay-agent-info in this class of encapsulated options? (We've taken to calling these type of options "compound" options, and the #4 style "structured" options around here, but those words might or might not be good ones to use.) 7. Section 3.7. Do you imagine that we will allow options where they are mixed #4 and #3 options, with some constant fields at the front, and then some sub-options inside at the end? Do we want to specifically allow or disallow such options in this draft? Personally, I think an option should either but style #4 (which I call structured), possibly with a variable length last field, or style #3 (which I call compound) which contains only sub-options in any order, but not some hybrid of both, but that's just my opinion. I *do* think we should explicitly allow or disallow these hybrids in the draft. Again, nice job. Thanks for doing this. Cheers -- Kim From dhcp-v4@bucknell.edu Fri Jul 2 21:31: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 VAA28633 for ; Fri, 2 Jul 1999 21:31: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 VAA04076; Fri, 2 Jul 1999 21:30:40 -0400 (EDT) Date: Fri, 2 Jul 1999 21:30:40 -0400 (EDT) Message-Id: <01C843625423D211AC3F00A0C969E890018C7131@orsmsx35.jf.intel.com> Errors-To: droms@bucknell.edu Reply-To: myron.hattig@intel.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Hattig, Myron" To: Multiple recipients of list Subject: 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 Sorry, I missed the previous discussion on the DHCP list. I got on the list after the discussion ended. I'll be in the DHCP meeting at Oslo and ready to talk then. As far as leading the discussion we, can just play it by ear. Thanks, -myron > -----Original Message----- > From: fujisawa@sm.sony.co.jp [mailto:fujisawa@sm.sony.co.jp] > Sent: Wednesday, June 23, 1999 6:50 PM > To: Multiple recipients of list > Cc: myron.hattig@intel.com > Subject: Re: draft-ietf-ip1394-dhcp-01.txt > > > > 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 Sun Jul 4 06:17: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 GAA04596 for ; Sun, 4 Jul 1999 06:17: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 GAA15212; Sun, 4 Jul 1999 06:16:54 -0400 (EDT) Date: Sun, 4 Jul 1999 06:16:54 -0400 (EDT) Message-Id: <199907041010.GAA13896@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-dhcp-dns-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 : Interaction between DHCP and DNS Author(s) : Y. Rekhter, M. Stapp Filename : draft-ietf-dhc-dhcp-dns-10.txt Pages : 17 Date : 01-Jul-99 DHCP provides a powerful mechanism for IP host configuration. However, the configuration capability provided by DHCP does not include updating DNS, and specifically updating the name to address and address to name mappings maintained in the DNS. This document specifies how DHCP clients and servers should use the Dynamic DNS Updates mechanism in [RFC2136] to update the DNS name to address and address to name mappings so that the mappings for DHCP clients will be consistent with the IP addresses that the clients acquire via DHCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcp-dns-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-dhcp-dns-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-dhcp-dns-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: <19990701143622.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcp-dns-10.txt From dhcp-v4@bucknell.edu Mon Jul 5 11:18: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 LAA02439 for ; Mon, 5 Jul 1999 11:18: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 LAA27638; Mon, 5 Jul 1999 11:17:31 -0400 (EDT) Date: Mon, 5 Jul 1999 11:17:31 -0400 (EDT) Message-Id: <199907051447.KAA10059@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: DHC 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 I've posted the agenda and links to relevant I-Ds at http://www.dhcp.org/9907-meeting.html John Wobus' DHCP FAQ seems to have become unavailable. I've not heard from John nor from the Syracuse webmaster in reponse to queries about the status of the FAQ. Does anyone know what might have happened and is there another source for the FAQ? - Ralph From dhcp-v4@bucknell.edu Mon Jul 5 13:27: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 NAA03638 for ; Mon, 5 Jul 1999 13:27: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 NAA11522; Mon, 5 Jul 1999 13:27:44 -0400 (EDT) Date: Mon, 5 Jul 1999 13:27:44 -0400 (EDT) Message-Id: <3780EADF.9E0716AD@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: DHC WG meetings in Oslo 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 > John Wobus' DHCP FAQ seems to have become unavailable. I'll be glad to host it if we need a new maintainer. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Wed Jul 7 17:48: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 RAA24083 for ; Wed, 7 Jul 1999 17:48: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 RAA18572; Wed, 7 Jul 1999 17:46:25 -0400 (EDT) Date: Wed, 7 Jul 1999 17:46:25 -0400 (EDT) Message-Id: <199907072119.RAA26017@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: TCP for failover protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Folks, As you no doubt noticed, there is a new version of the failover draft, which I put together with the help of Bernie Volz and Steve Gonzci: draft-ietf-dhc-failover-04.txt I wanted to continue a discussion that Dave Erdmann started a while back about using only a single TCP connection for the failover protocol, instead of using a TCP connection for bulk data transfer *and* a UDP connection for sensing whether one can communicate with the partner server. Ted Lemon started the drive for this during the failover meeting last February. Well, the -04 draft indeed is defined with only one TCP connection and no UDP connection, so in that sense I believe that I've achieved the goal. However, as is so common, there are tradeoffs. Let me quote from the draft and add some words to try to explain what I did and why, and generate some discussion on it prior to Oslo. First, let me set the stage a little bit. There are two reasons a failover server needs a connection to its failover partner: 1. To pass binding database updates between them. 2. To determine if the partner is able to communicate with it. One of the slightly unusual characteristics of the failover protocol is that, because of the "lazy update" nature of the dataflow in #1, it is not a particularly time critical dataflow. The long term throughtput is important, but the latency of individual messages is not. In particular, on the receiving server, processing DHCP client requests is considerably more important than processing failover binding database updates. Note also that as part of initialization or during recovery, a server may have 10,000 or 20,000 BNDUPD messages to send to its partner, which may take many minutes to processes. While large, these aren't contrived situations, but real world examples. However, the sensing and detection required by #2 is moderately time critical, in that a server that doesn't know that the other server is not responding will not itself respond to the correct DHCP client requests (i.e., DHCPDISCOVERS), and new clients will not be able to get IP addresses if one server doesn't know that its partner is down or disconnected. TCP is well suited to use #1 by just passing data down the wire and processing it as fast as possible (but with less priority than DHCP client requests on the receiving server). However, if the TCP connection is being used in this way, there are problems in using it for the sensing and detection function required by #2, above. Below I quote from section 3.5 of the most recent failover draft: ------------------------------------------- 3.5. Using TCP to detect partner server failure There are several characteristics of TCP that are important to the functioning of the failover protocol, which uses one TCP connection for both bulk data transfer as well as to assess communications integrity with the other server. Reliable and ordered message delivery are chief among these important characteristics. It would be nice to use the capabilities built in to TCP to allow it to determine if communications integrity exists to the failover partner but this strategy contains some problems which require analysis. There exist three fundamental cases for an open TCP con- nection that must be examined. 1. When no data is being sent then no messages are traveling across the TCP connection. 2. When data is queued to be sent, and the receiver has not blocked the sending of additional data, then messages are flowing across the TCP connection containing the applications data. 3. When data is queued to be sent, and the receiver has blocked the transmission of additional data, then persist messages are flowing from the receiver to the sender to ensure that the sender doesn't miss the receiver opening the window for further transmissions. The first case can be turned into the second case by sending application-level keep-alive messages periodically when there is no other data queued to be sent. Note TCP keep-alive messages might be used as well, but they present additional problems. [And are not further considered here -- we can discuss them if necessary.] Thus, we can ensure that the TCP connection has messages flowing periodically across the connection fairly easily. The question remains as to what TCP will do if the other end of the connection fails to respond (either because of network partition or because the receiving server crashes). TCP will attempt to retransmit a message with an exponential backoff, and will eventually timeout that retransmission. However, the length of that timeout cannot, in gen- eral, be set on a per-connection basis, and is frequently as long as nine minutes, though in some cases it may be as short as two minutes. One some systems it can be set system-wide, while on some systems it cannot be changed at all. A value for this timeout that would be appropriate for the failover protocol, say less than 1 minute, could have unpleasant side-effects on other applications running on the same server, assuming that it could be changed at all on the host operating system. Nine minutes is a long time for the DHCP service to be unavailable to any new clients that were being served by the server which has crashed, when there is another server running that could respond to them immediately as soon as it determines that its partner is not operational. The conclusion drawn from this analysis is that TCP provides very useful support for the failover protocol in the areas of reliable and ordered message delivery, but cannot by itself be relied upon to detect partner server failure in a fashion acceptable to the needs of the failover protocol. Additional failover protocol capabilities will need to be created to support timely detection of partner server failure. See section 8.3 for details on this mechanism. ------------------------------------------- This explains the problem. Here is the solution that is contained in the draft: --------------------------------------------- 8.3. Using the TCP connection for determining communications status The TCP connection is used to determine the communications status of the other server, i.e., communications-ok, or communications- interrupted. Three things must happen for a server to consider that communications are ok with respect to another server: 1. A TCP connection must be established to the other server. 2. A CONNECT message must be received and a CONNECTACK message sent in response. The CONNECT message is used to determine the identify of the failover endpoint of the other end of the TCP connection -- without it, the failover endpoint cannot be uniquely determined. Without knowledge of the failover end- point, then the entity with which communications is ok is undetermined. 3. A STATE message must be received from the other server over the connection. This STATE message initializes important information necessary to the operation of the state machine the governs the behavior of this failover endpoint. There are two ways that a server can determine that communications has failed: 1. The TCP connection can go down, yielding an error when attempting to send a message. This will happen at least as often as the period of the tSend timer. 2. The tReceive timer can expire. In either of these cases, communications is considered interrupted. Several difficulties arise when trying to use one TCP connection for both bulk data transfer as well as to sense the communications status of the other server. One aspect of the problem stems from the dif- ferent requirements of both uses. The bulk data transfer is of course critically important to the protocol, but the speed with which it is processed is not terribly significant. It might well be minutes before a BNDUPD message is processed, and while not optimal, such an occasional delay doesn't compromise the correctness of the protocol. However, the speed with which one server detects the other server is up (or, more importantly, down) is more highly constrained. Generally one server should be able to detect that the other server is not communicating within a minute or less. These differing time constraints makes it difficult to use the same TCP connection for data transfer as well as to sense communications integrity. See section 3.5 for additional details on TCP. The solution to this problem is to require a that some message be received by each end of the connection within a limited time or that the connection will be considered down. If no messages have been sent recently, then a CONTACT message is sent. In the case where there is no data queued to be sent, this is not a problem, but in the case where there is data queued to be sent to the partner, then the CONTACT message will not actually be transmitted until the queued data is sent. Section 3.5 explains why waiting for TCP to determine that the connection is down is not acceptable, and leads a requirement that the receiving server never block the sending server from sending CONTACT packets. In order to meet this requirement, each server tells the other server the number of outstanding BNDUPD messages that it will accept. The receiving server is required to always be able to accept that many BNDUPD messages off of the connection's input queue even if it cannot process them immediately, and to accept all other messages immedi- ately. Thus, the sending server's TCP is never blocked from sending a mes- sage except for very short periods, less than a few seconds unless the network connection itself has problems. In this case, if the CONTACT messages don't make it to the partner then the partner will close the connection. 8.4. Using the TCP connection for binding data Binding data, in the form of BNDUPD messages and BNDACK messages to respond to them, are sent across the TCP connection. In order to support timely detection of any failure in the partner server, the TCP connection MUST NOT block for more than a very short time, on the order of a few seconds. Therefore, a server that is sending BNDUPD messages MUST send only a restricted number before receiving BNDACK messages about previous messages sent. The number of outstanding BNDUPD messages that each server will accept without causing TCP to block transmission of additional data (i.e, CONTACT messages) is sent by each server in the CONNECT and CONNECTACK messages in the max-unacked-bndupd option. 8.5. Using the TCP connection for control messages The TCP connection is used for control messages: POOLREQ, UPDREQ, STATE, UPDREQALL and the corresponding reply messages: POOLRESP, UPDDONE. A server MUST immediately accept all of these messages from the TCP connection. A server MUST immediately accept any BNDACK which is received as well. 8.6. Losing the TCP connection When the TCP connection is lost, then communications is not ok with the other server. A server which has lost communications SHOULD immediately attempt to reconnect to the other server, and should retry these connection attempts periodically. Any BNDUPD or other messages that have been received but not yet pro- cessed from the partner SHOULD be processed as soon as possible. ------------------------------------- Thus, the solution documented above, is for the servers to agree on the number of un-acked binding update messages that they can *always* accept, and then for one server to never send more than that to its partner. In this way, the TCP connection is always kept open for control messages and for CONTACT messages. Thus each server will receive a message (and be *able* to receive a message) of some type within every few 10's of seconds -- usually either a BNDUPD or CONTACT message, but it could be any message. And because the TCP connection is kept "open", that message will always go through, and the receiving server will never be flooded with 10,000 or 20,000 BNDUPD messages. I expect we'll be discussing this a lot over the coming months, and I'm planning on hosting a conference call at some time after Oslo to discuss this (and other) issues in the failover protocol. Cheers - Kim From dhcp-v4@bucknell.edu Wed Jul 7 19:30: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 TAA24735 for ; Wed, 7 Jul 1999 19:30:37 -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 TAA06508; Wed, 7 Jul 1999 19:30:31 -0400 (EDT) Date: Wed, 7 Jul 1999 19:30:31 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: mike.henry@intel.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Henry, Mike" 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 I'm not quite sure where to jump in here as there are a couple of interesting entry points, but, here goes.... First, it seems like the requirement for the 1394 device to use EUI-64 as the Client ID would be a problem if the 1394 device was ever expected to use authenticated DHCP messages, as it would then also need to use a UUID Client ID instead of it EUI-64 ID for those transactions. The authors of Authentication for DHCP Messages (sect. 5.5.1) propose using a UUID type of client ID as a means for the client to ID itself to the DHCP service . One suggestion would be for 1394 to use a UUID Client ID rather than a EUI-64 Client ID. Besides solving this particular problem, we think it would be very useful in general to establish a truly universal identifier that could be universally used as a convenient index for devices independent of the device's network protocol, media type, presence of a network, etc. Also, wouldn't the suggestion that the 1394 device place it's Client ID in chadder to facilitate keying by the DHCP service theoretically be a problem if a different device using a different protocol had a matching 64bit MAC address (72bit if 1394 also included Client ID type number)? This is very unlikely, but it *is* the problem with identifiers that are expected to be unique outside of their scope. Would it be reasonable to reserve 128 bit MAC address format to be identically the UUID? - Mike H. 7/7 ----------------- Michael D. Henry PXE Engineering Manager Intel - IAL/MPL mike.henry@intel.com (503) 264-9689 (503) 804-8011 (cell) > -----Original Message----- > From: Ted Lemon [mailto:mellon@isc.org] > Sent: Wednesday, June 23, 1999 1:33 PM > To: Multiple recipients of list > Subject: Re: draft-ietf-ip1394-dhcp-01.txt > > > > > 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 Jul 7 22:32: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 WAA27194 for ; Wed, 7 Jul 1999 22:32: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 WAA21540; Wed, 7 Jul 1999 22:32:03 -0400 (EDT) Date: Wed, 7 Jul 1999 22:32:03 -0400 (EDT) Message-Id: <199907080155.KAA15251@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 Hi, Thanks for comment. >First, it seems like the requirement for the 1394 device to use EUI-64 as >the Client ID would be a problem if the 1394 device was ever expected to use >authenticated DHCP messages, as it would then also need to use a UUID Client >ID instead of it EUI-64 ID for those transactions. The authors of >Authentication for DHCP Messages >(sect. 5.5.1) propose using a UUID type of client ID > as a means for the client to ID >itself to the DHCP service . Although I don't know the detail of UUID and DHCP-Authentication, I don't see any problem here since DHCP/1394 does NOT restrict to use only EUI-64 client ID. One MAY use a UUID Client ID for 1394 device. >Also, wouldn't the suggestion that the 1394 device place it's Client ID in >chadder to facilitate keying by the DHCP service theoretically be a problem >if a different device using a different protocol had a matching 64bit MAC >address (72bit if 1394 also included Client ID type number)? This is very >unlikely, but it *is* the problem with identifiers that are expected to be >unique outside of their scope. Would it be reasonable to reserve 128 bit >MAC address format to be identically the UUID? I think this is a point of discussion. What is a meaning of 'chaddr'? My understanding is it is a client link address to return a response message, since we have a Client ID to identify a client. In the case of IEEE1394, we don't have a constant link address of a node. This is the reason to set 'hlen' = 0. What do you/others think? Best Regards, Kenji Fujisawa From dhcp-v4@bucknell.edu Wed Jul 7 23:18: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 XAA27644 for ; Wed, 7 Jul 1999 23:18: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 XAA10256; Wed, 7 Jul 1999 23:18:37 -0400 (EDT) Date: Wed, 7 Jul 1999 23:18:37 -0400 (EDT) Message-Id: <199907080238.LAA15396@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 >One MAY use a UUID Client ID for 1394 device. This is true, but.. http://www.opengroup.org/onlinepubs/9629399/apdxa.htm says, : This UUID specification assumes the availability of an IEEE 802 : address. This will be a problem since TYPICAL IEEE1394 node does not have IEEE 802 address. Kenji Fujisawa From dhcp-v4@bucknell.edu Thu Jul 8 03:05: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 DAA14194 for ; Thu, 8 Jul 1999 03:05: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 DAA10729; Thu, 8 Jul 1999 03:05:23 -0400 (EDT) Date: Thu, 8 Jul 1999 03:05:23 -0400 (EDT) Message-Id: <000c01bec910$4a5fbac0$2a8939cc@vaio> 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: TCP for failover protocol 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 Overall, I think that this is a good solution to the problem. As you state, the keepalive messages are sent if no other data is being sent in order to keep the connection up. I would not attempt to use TCP keepalive for this since it was created for quite a different purpose. I would also note that there is no need to wait until TCP times out in order to conclude that a connection is down. It is possible to set your own timer for a shorter value and close the connection if nothing is received up to that point. Of course, you don't want to set the timer too short or you will close connections unnecessarily. From dhcp-v4@bucknell.edu Thu Jul 8 11:22: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 LAA16845 for ; Thu, 8 Jul 1999 11:22: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 LAA06923; Thu, 8 Jul 1999 11:21:06 -0400 (EDT) Date: Thu, 8 Jul 1999 11:21:06 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: mike.henry@intel.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Henry, Mike" 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 Kenji, The UUID spec does not assume the device has an IEEE 802 address. It assumes the UUID generator (the entity creating UUIDs for devices) uses an IEEE 802 address as a "spatially unique value". It is common for devices to be assigned UUIDs based on the IEEE 802 address of the machine generating the UUIDs. For example, in a manufacturing environment a single machine may generate UUIDs for the devices being manufactured in much the same way that serial numbers are created centrally and applied to each device. The device itself is not required to provide the seed (i.e. IEEE 802 address). This is really not much different than the assumptions EUI-64 is built on. - Mike H. 7/6 ---------------- > -----Original Message----- > From: fujisawa@sm.sony.co.jp [mailto:fujisawa@sm.sony.co.jp] > Sent: Wednesday, July 07, 1999 8:19 PM > To: Multiple recipients of list > Subject: Re: draft-ietf-ip1394-dhcp-01.txt > > > > >One MAY use a UUID Client ID for 1394 device. > > This is true, but.. > http://www.opengroup.org/onlinepubs/9629399/apdxa.htm > says, > : This UUID specification assumes the availability of an IEEE 802 > : address. > > This will be a problem since TYPICAL IEEE1394 node does not have > IEEE 802 address. > > Kenji Fujisawa > From dhcp-v4@bucknell.edu Thu Jul 8 13:51: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 NAA17845 for ; Thu, 8 Jul 1999 13:51: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 NAA31640; Thu, 8 Jul 1999 13:50:59 -0400 (EDT) Date: Thu, 8 Jul 1999 13:50:59 -0400 (EDT) Message-Id: <199907081631.MAA16589@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 general interest mailing list. X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 The Internet Software Consortium is pleased to announce the creation of a new mailing list, dhcp-interest@isc.org, for users of the DHCP protocol. This list is not restricted to users of the ISC DHCP Distribution, but rather is intended to be a place where anybody who is using the DHCP protocol can ask questions, and hopefully get answers. We would like to invite anybody who is willing to try to help other people who are using DHCP to subscribe to the mailing list and answer questions there. We also invite anybody who has questions they'd like to have answered (or expects that they may need questions answered in the future) to subscribe. To subscribe, please send mail to dhcp-interest-request@isc.org with the word "subscribe" in the subject. Please do not send your subscription request directly to the mailing list. Peter Losher set this up, so by all means thank him, not me. Please feel free to forward this to people that you think would be interested, and if you provide support for DHCP products, feel free to mention the mailing list to your customers. From dhcp-v4@bucknell.edu Thu Jul 8 15:07: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 PAA18345 for ; Thu, 8 Jul 1999 15:07: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 PAA08262; Thu, 8 Jul 1999 15:06:10 -0400 (EDT) Date: Thu, 8 Jul 1999 15:06:10 -0400 (EDT) Message-Id: <3784E691.DD2A515F@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 general interest mailing list. X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.6 [en] (WinNT; I) Content-Transfer-Encoding: 7bit > feel free to forward this to people that you think would be > interested, and if you provide support for DHCP products, feel free to > mention the mailing list to your customers. Actually, it would probably help everybody if some of the vendors here put links to the mailing list on their support pages. The FAQ ought to have a reference to the list too, as should the DHC WG home page. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Fri Jul 9 10:58: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 KAA13122 for ; Fri, 9 Jul 1999 10:58: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 KAA19117; Fri, 9 Jul 1999 10:57:23 -0400 (EDT) Date: Fri, 9 Jul 1999 10:57:23 -0400 (EDT) Message-Id: <199907091440.KAA20046@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: TCP for failover protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 At 03:05 AM 7/8/99 -0400, Bernard Aboba wrote: >Overall, I think that this is a good solution to the problem. >As you state, the keepalive messages are sent if no other >data is being sent in order to keep the connection up. I >would not attempt to use TCP keepalive for this since it >was created for quite a different purpose. Thanks! > >I would also note that there is no need to wait until >TCP times out in order to conclude that a connection is >down. It is possible to set your own timer for a shorter >value and close the connection if nothing is received up >to that point. Of course, you don't want to set the timer >too short or you will close connections unnecessarily. > Indeed, the value of tReceive is not specified in the draft because it is installation dependent, but it is both independent of the TCP timeout and, in all cases I can imagine, considerably shorter. In a LAN environment (i.e., not a situation where servers are separated by a 56K link) I would expect to configure tReceive to be 30 seconds and tSend to be 10 seconds. Thus a message would be sent every 10 seconds from each server to the other, and if either server didn't receive a message for 30 seconds, it would drop the connection and assume that communications with the other server was interrupted. I don't think I'd want to configure them much shorter, but then I don't think I'd want to configure them much longer either. But your mileage may vary. Cheers -- Kim From dhcp-v4@bucknell.edu Tue Jul 13 02:18: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 CAA08659 for ; Tue, 13 Jul 1999 02:18:38 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id CAA01090; Tue, 13 Jul 1999 02:17:49 -0400 (EDT) Date: Tue, 13 Jul 1999 02:17:49 -0400 (EDT) Message-Id: <199907130558.OAA21702@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: UUID client ID X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Hi, >The authors of >Authentication for DHCP Messages >(sect. 5.5.1) propose using a UUID type of client ID > as a means for the client to ID >itself to the DHCP service . It seems DHCP Authentication document does not mention a type of the Client ID. draft-ietf-dhc-authentication-11.txt : 1. The client MUST include the authentication request option in : its DHCPDISCOVER message along with option 61 [6] to identify : itself uniquely to the server. Is it necessary to use UUID type for the authentication? Os just an uniqueness is good enough? Best Regards, Kenji Fujisawa From dhcp-v4@bucknell.edu Tue Jul 13 02:22:53 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08678 for ; Tue, 13 Jul 1999 02:22:53 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id CAA00114; Tue, 13 Jul 1999 02:22:52 -0400 (EDT) Date: Tue, 13 Jul 1999 02:22:52 -0400 (EDT) Message-Id: <199907130607.PAA21727@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: draft-ietf-dhc-authentication-11.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Hi, I have a trivial question in draft-ietf-dhc-authentication-11.txt. :4. Protocol 0 : +----------+----------+----------+----------+ : | Code | n+1 | 0 | 0 | : +----------+----------+----------+----------+- : | Global Replay Counter ... : +----------+----------+----------+----------+- : | Authentication token (n octets) ... : +----------+----------+----------+----------+- :5.2 Format : +----------+----------+----------+----------+ : | Code | 2 | 1 | Algorithm| : +----------+----------+----------+----------+- : | Global Replay Counter ... : +----------+----------+----------+----------+- If the length of 'Global Replay Counter' is 64 bit, it seems that the Length fields above should be 'n+10' and '10' respectively. Am I missing something? Kenji Fujisawa From dhcp-v4@bucknell.edu Wed Jul 14 22:28: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 WAA17785 for ; Wed, 14 Jul 1999 22:28: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 WAA22753; Wed, 14 Jul 1999 22:27:41 -0400 (EDT) Date: Wed, 14 Jul 1999 22:27:41 -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: 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 Yes you are correct. The dangers of "cut and paste". Bill > > Hi, > > I have a trivial question in draft-ietf-dhc-authentication-11.txt. > > :4. Protocol 0 > : +----------+----------+----------+----------+ > : | Code | n+1 | 0 | 0 | > : +----------+----------+----------+----------+- > : | Global Replay Counter ... > : +----------+----------+----------+----------+- > : | Authentication token (n octets) ... > : +----------+----------+----------+----------+- > > :5.2 Format > : +----------+----------+----------+----------+ > : | Code | 2 | 1 | Algorithm| > : +----------+----------+----------+----------+- > : | Global Replay Counter ... > : +----------+----------+----------+----------+- > > If the length of 'Global Replay Counter' is 64 bit, it seems that > the Length fields above should be 'n+10' and '10' respectively. > > Am I missing something? > > Kenji Fujisawa > From dhcp-v4@bucknell.edu Wed Jul 14 23:10:58 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19085 for ; Wed, 14 Jul 1999 23:10:57 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id XAA28680; Wed, 14 Jul 1999 23:10:57 -0400 (EDT) Date: Wed, 14 Jul 1999 23:10:57 -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: UUID client ID 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 Uniqueness is definitely a requirement. There probably needs to be some discussion on how people feel on this issue. I'd like to see something like the UUID that provides some inter-domain uniqueness rather than every domain using their own ID. Doing so, however, raises some privacy issues. How do people feel? Bill > > It seems DHCP Authentication document does not mention a type of the > Client ID. > > draft-ietf-dhc-authentication-11.txt > : 1. The client MUST include the authentication request option in > : its DHCPDISCOVER message along with option 61 [6] to identify > : itself uniquely to the server. > > Is it necessary to use UUID type for the authentication? > Os just an uniqueness is good enough? > > Best Regards, > > Kenji Fujisawa > From dhcp-v4@bucknell.edu Thu Jul 15 03:21: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 DAA05015 for ; Thu, 15 Jul 1999 03:21: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 DAA03928; Thu, 15 Jul 1999 03:20:51 -0400 (EDT) Date: Thu, 15 Jul 1999 03:20:51 -0400 (EDT) Message-Id: <199907150702.QAA25542@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: UUID client ID X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Hi, Thank you for your reply. >Uniqueness is definitely a requirement. There probably needs to be some >discussion on how people feel on this issue. I'd like to see something >like the UUID that provides some inter-domain uniqueness rather than every >domain using their own ID. It seems that the global 802 MAC address and EUI-64 are also useful for the authentication. Is this correct? Kenji Fujisawa From dhcp-v4@bucknell.edu Thu Jul 15 09:04: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 JAA09810 for ; Thu, 15 Jul 1999 09:04: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 JAA08184; Thu, 15 Jul 1999 09:04:18 -0400 (EDT) Date: Thu, 15 Jul 1999 09:04:18 -0400 (EDT) Message-Id: <199907151211.IAA19935@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: UUID client ID X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Doing so, however, raises some privacy issues. Can you elaborate on this? I don't see it. A UUID is no more exciting than an IP address, right? _MelloN_ From dhcp-v4@bucknell.edu Thu Jul 15 09:08: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 JAA09865 for ; Thu, 15 Jul 1999 09:08: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 JAA06933; Thu, 15 Jul 1999 09:08:48 -0400 (EDT) Date: Thu, 15 Jul 1999 09:08:48 -0400 (EDT) Message-Id: <199907151220.IAA19988@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: UUID client ID X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > It seems that the global 802 MAC address and EUI-64 are also useful > for the authentication. Do you mean as a global identifier, or as actual authentication? They're probably useful as a global identifier, although 48 bits is kind of small nowadays for a global identifier and will come to seem even smaller as time goes by. _MelloN_ From dhcp-v4@bucknell.edu Thu Jul 15 09:52: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 JAA10602 for ; Thu, 15 Jul 1999 09:52: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 JAA15838; Thu, 15 Jul 1999 09:52:46 -0400 (EDT) Date: Thu, 15 Jul 1999 09:52:46 -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: UUID client ID 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 > > > Doing so, however, raises some privacy issues. > > Can you elaborate on this? I don't see it. A UUID is no more > exciting than an IP address, right? > I think it's a bit stronger than an IP address, but essentially you are correct. I thought several people at the Microsoft Authentication workshop were concerned about global id's. Perhaps I remember it incorrectly, but I wanted it discussed on the list to ensure there weren't any objections. I personally prefer the UUID as I stated at the last meeting in Minn. Bill From dhcp-v4@bucknell.edu Thu Jul 15 11:09: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 LAA11531 for ; Thu, 15 Jul 1999 11:09: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 LAA18765; Thu, 15 Jul 1999 11:08:44 -0400 (EDT) Date: Thu, 15 Jul 1999 11:08:44 -0400 (EDT) Message-Id: <199907151410.XAA26148@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: UUID client ID X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 >> It seems that the global 802 MAC address and EUI-64 are also useful >> for the authentication. > >Do you mean as a global identifier, or as actual authentication? I meant an identifier in a client ID, similar to the use of UUID. >They're probably useful as a global identifier, although 48 bits is >kind of small nowadays for a global identifier and will come to seem >even smaller as time goes by. Anyway, Ethernet node will have a global 802 MAC address while Ethernet is used. And I guess this is one reason why IEEE defined EUI-64 (64bit ID). Kenji Fujisawa From dhcp-v4@bucknell.edu Wed Jul 21 04:48: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 EAA02151 for ; Wed, 21 Jul 1999 04:48:53 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id EAA27559; Wed, 21 Jul 1999 04:48:12 -0400 (EDT) Date: Wed, 21 Jul 1999 04:48:12 -0400 (EDT) Message-Id: <00b701bed356$6fe6d6c0$2a8939cc@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: Another question on draft-ietf-dhc-authentication-11.txt 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 Just reread the draft again, and had the following thought: How are the DHCP servers to verify the authentication option and sign messages? Are we to assume that the DHCP servers have cleartext access to the shared secret? If we are talking about generating the secret from a master secret as described in the Appendix, this might be feasible. However, I don't like that method much since a master secret shared among many clients does not have much security value. So I prefer to think of this as involving a unique shared secret for each client in which case I think the answer to this is "no." Will the shared secret will be set via an SNMP v3 MIB? If so, this capability is not in the current DHCP MIB. Will the DHCP servers will ship the signed DHCP packet and proposed response off to a AAA server for validation, and signing? This sounds like the most deployable approach, but encapsulating DHCP packet payloads in this manner is more than a little awkward. From dhcp-v4@bucknell.edu Wed Jul 21 06:51: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 GAA02751 for ; Wed, 21 Jul 1999 06:51: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 GAA25948; Wed, 21 Jul 1999 06:50:48 -0400 (EDT) Date: Wed, 21 Jul 1999 06:50:48 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: rhandeev@comp.nus.edu.sg Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Rhandeev Singh To: Multiple recipients of list Subject: ISC dhcp server implementation X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: TEXT/PLAIN; charset=US-ASCII Mime-Version: 1.0 Hi Ted, In a Virtual LAN environment, it is desirable to configure some DHCP servers to ignore requests from clients whose chaddr is not recognized. As we couldn't find a way to do this with version 2.0b1 of the ISC dhcp server implementation, we decided to ask if we could implement this and perhaps forward the patch to you. We believe that the introduction of this behaviour does not break compliance with section 4.2 of RFC 2131, but correct us if we're wrong: ---------extract-from-rfc-2131--------------------- 4.2 DHCP server administrative controls DHCP servers are not required to respond to every DHCPDISCOVER and DHCPREQUEST message they receive. For example, a network administrator, to retain stringent control over the clients attached to the network, may choose to configure DHCP servers to respond only to clients that have been previously registered through some external mechanism. The DHCP specification describes only the interactions between clients and servers when the clients and servers choose to interact; it is beyond the scope of the DHCP specification to describe all of the administrative controls that system administrators might want to use. Specific DHCP server ---------end-extract-from-rfc-2131----------------- Thanks. Rhan. --- Rhandeev Singh Linux User Group National University of Singapore From dhcp-v4@bucknell.edu Wed Jul 21 10:42: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 KAA11394 for ; Wed, 21 Jul 1999 10:42: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 KAA30396; Wed, 21 Jul 1999 10:32:19 -0400 (EDT) Date: Wed, 21 Jul 1999 10:32:19 -0400 (EDT) Message-Id: <199907211339.JAA00658@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: ISC dhcp server implementation X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > In a Virtual LAN environment, it is desirable to configure some DHCP > servers to ignore requests from clients whose chaddr is not recognized. You can in fact do this with Version 2.0 of the ISC DHCP server. To do it, you need to start your configuration file with: not authoritative; deny unknown-clients; Then you need to write host declarations for every client, like this: host client-1 { hardware ethernet 08:00:2b:4c:a9:ad; } And then, of course, you need some kind of subnet and address range declarations. The "not authoritative" statement causes the DHCP server to respond negatively only to clients that have host declarations - in other words, it won't send DHCPNAK messages to unknown clients that happen to have configurations the server thinks are incorrect. The "deny unknown-clients" statement tells the server not to supply leases to clients that aren't registered. The host statement registers a client. BTW, there is a mailing list for the ISC DHCP server - visit http://www.isc.org for details. _MelloN_ From dhcp-v4@bucknell.edu Wed Jul 21 10:45: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 KAA11478 for ; Wed, 21 Jul 1999 10:45: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 KAA17883; Wed, 21 Jul 1999 10:35:16 -0400 (EDT) Date: Wed, 21 Jul 1999 10:35:16 -0400 (EDT) Message-Id: <199907211350.JAA00689@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: Another question on draft-ietf-dhc-authentication-11.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Are we to assume that the DHCP servers have cleartext access > to the shared secret? Yes. > If we are talking about generating the secret from a master secret > as described in the Appendix, this might be feasible. This is one alternative, but I like it about as much as you do. > Will the shared secret will be set via an SNMP v3 MIB? > If so, this capability is not in the current DHCP MIB. The authentication draft does not describe the mechanism by which the client and server will arrive at a shared secret. This is left up to a seperate draft that somebody may produce, or to individual implementors. Essentially, we didn't feel that we had enough practical experience to recommend a single mechanism whereby this would be accomplished, although we definitely left it open that we might come up with such a mechanism, or several such mechanisms, in the future. > Will the DHCP servers will ship the signed DHCP > packet and proposed response off to a AAA server > for validation, and signing? This sounds like the > most deployable approach, but encapsulating DHCP > packet payloads in this manner is more than a little > awkward. This isn't the intention of the draft, AFAIK. That's not to say you *couldn't* use some other mechanism, like what you describe, but I don't think this would be an easy thing to do. _MelloN_ From dhcp-v4@bucknell.edu Wed Jul 21 11:22:50 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12015 for ; Wed, 21 Jul 1999 11:22:49 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA07075; Wed, 21 Jul 1999 11:22:42 -0400 (EDT) Date: Wed, 21 Jul 1999 11:22:42 -0400 (EDT) Message-Id: <00bc01bed38a$38f3c540$2a8939cc@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: Another question on draft-ietf-dhc-authentication-11.txt 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 >> Are we to assume that the DHCP servers have cleartext access >> to the shared secret? >Yes. Aside from the case where you only need to store a single master secret, which isn't very secure, I don't think that this approach is very practical. In many cases, systems don't support retrieval of the cleartext password from the directory or wherever they are stored. Creating another store of user information on the DHCP server is not something that most customers will like. >Essentially, we didn't feel that we had enough >practical experience to recommend a single mechanism whereby this >would be accomplished. Just worth noting that companies lookin at deploying this are often large, so that we could be talking about 100K shared secrets here. >This isn't the intention of the draft, AFAIK. >I don't think this would be an easy thing to do. I would agree with this. However, I don't see another alternative that is both reasonably secure and is deployable. I would note that Mobile IP took much the same approach (adding authentication extensions to the Registration request and response messages) in RFC 2002. However, for carrier deployments, centralized authentication management is required and so now they are looking at a challenge-response option. From dhcp-v4@bucknell.edu Wed Jul 21 11:31: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 LAA12167 for ; Wed, 21 Jul 1999 11:31: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 LAA29818; Wed, 21 Jul 1999 11:24:42 -0400 (EDT) Date: Wed, 21 Jul 1999 11:24:42 -0400 (EDT) Message-Id: <199907211450.KAA00976@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: Another question on draft-ietf-dhc-authentication-11.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > I don't think that this approach is very practical. In many cases, > systems don't support retrieval of the cleartext password from the > directory or wherever they are stored. We weren't expecting to use the same password that the user of the DHCP client uses for personal authentication - the security implications of this are not good. > Creating another store of user information on the DHCP > server is not something that most customers will like. Understood. Unfortunately, there's no way to avoid this with a shared secret/HMAC algorithm. Ken Hornstein and I discussed a way of using Kerberos authentication, and we might write a draft for that. The current draft does not preclude other alternatives, but it does provide a mechanism that's not subject to export restrictions and will work. We know it's not the ideal solution. If you're a U.S. citizen, please write your congresscritters. > Just worth noting that companies lookin at deploying this > are often large, so that we could be talking about 100K > shared secrets here. We're painfully aware of this. > However, for carrier deployments, centralized authentication > management is required and so now they are looking at a > challenge-response option. Does this involve public key cryptography? _MelloN_ From dhcp-v4@bucknell.edu Wed Jul 21 12:30: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 MAA12945 for ; Wed, 21 Jul 1999 12:30:37 -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 MAA03415; Wed, 21 Jul 1999 12:30:26 -0400 (EDT) Date: Wed, 21 Jul 1999 12:30:26 -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: Another question on draft-ietf-dhc-authentication-11.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 On Wed, 21 Jul 1999, Bernard Aboba wrote: > Just reread the draft again, and had the following thought: > > How are the DHCP servers to verify the > authentication option and sign messages? > > Are we to assume that the DHCP servers have cleartext access > to the shared secret? If we are talking about generating > the secret from a master secret as described in the > Appendix, this might be feasible. However, I don't like > that method much since a master secret shared among > many clients does not have much security value. So I > prefer to think of this as involving a unique shared > secret for each client in which case I think the > answer to this is "no." > The answer will depend on how the authentication is done. If it's a shared secret model, then I would expect the DHCP server to have access to the clear text secret or some means to pass the verification off via a secure tunnel. (BTW- I don't like the master secret appendix approach either). How, exactly, the DHCP server completes the authentication process is implementation independent and should be so IMHO. Bill From dhcp-v4@bucknell.edu Wed Jul 21 12:33: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 MAA13060 for ; Wed, 21 Jul 1999 12:33: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 MAA06316; Wed, 21 Jul 1999 12:33:05 -0400 (EDT) Date: Wed, 21 Jul 1999 12:33:05 -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: Another question on 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 On Wed, 21 Jul 1999, Ted Lemon wrote: > > Understood. Unfortunately, there's no way to avoid this with a shared > secret/HMAC algorithm. Ken Hornstein and I discussed a way of using > Kerberos authentication, and we might write a draft for that. The > current draft does not preclude other alternatives, but it does > provide a mechanism that's not subject to export restrictions and will > work. We know it's not the ideal solution. If you're a U.S. citizen, > please write your congresscritters. > I'm not an export expert nor do I speak for the U.S. government, but I thought that systems whose sole purpose is authentication are exportable regardless of the crypto involved. I don't know if a license is required though. > > Just worth noting that companies lookin at deploying this > > are often large, so that we could be talking about 100K > > shared secrets here. > > We're painfully aware of this. > And why the draft was designed to permit public key authentication. From dhcp-v4@bucknell.edu Wed Jul 21 12:38: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 MAA13099 for ; Wed, 21 Jul 1999 12:38: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 MAA22962; Wed, 21 Jul 1999 12:34:39 -0400 (EDT) Date: Wed, 21 Jul 1999 12:34:39 -0400 (EDT) Message-Id: <199907211559.LAA01179@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: Another question on draft-ietf-dhc-authentication-11.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > I'm not an export expert nor do I speak for the U.S. government, but I > thought that systems whose sole purpose is authentication are exportable > regardless of the crypto involved. I don't know if a license is required > though. In theory, I think you are correct. In practice, this is something about which people tend to get nervous. > > We're painfully aware of this. > > > And why the draft was designed to permit public key authentication. Yup. _MelloN_ From dhcp-v4@bucknell.edu Wed Jul 21 14:07: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 OAA14504 for ; Wed, 21 Jul 1999 14:07: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 OAA04724; Wed, 21 Jul 1999 14:06:42 -0400 (EDT) Date: Wed, 21 Jul 1999 14:06:42 -0400 (EDT) Message-Id: <492429067.932575944609.JavaMail.vgupta@hsmpka.Eng.Sun.COM> 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@Eng.Sun.COM To: Multiple recipients of list Subject: Re: RE: Another question on draft-ietf-dhc-authentication-11.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Sun(TM) Web Access 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit I presented a generalization of the Droms/Arbaugh authentication draft in Oslo (draft-gupta-dhcp-auth-00.txt) which supports public-key based authentication. It also describes how to support roaming -- there are similarities here with your draft titled "Certificate based Roaming" (in roamops). Could you please review the generalization and post your feedback on whether or not that approach is suitable for the scenarios you have in mind. thanks for your time, vipul >>> Are we to assume that the DHCP servers have cleartext access >>> to the shared secret? > >>Yes. > >Aside from the case where you only need to store a single master >secret, which isn't very secure, I don't think that this approach >is very practical. In many cases, systems don't support retrieval >of the cleartext password from the directory or wherever they are >stored. Creating another store of user information on the DHCP >server is not something that most customers will like. > >>Essentially, we didn't feel that we had enough >>practical experience to recommend a single mechanism whereby this >>would be accomplished. > >Just worth noting that companies lookin at deploying this >are often large, so that we could be talking about 100K >shared secrets here. > >>This isn't the intention of the draft, AFAIK. >>I don't think this would be an easy thing to do. > >I would agree with this. However, I don't see another >alternative that is both reasonably secure and is deployable. >I would note that Mobile IP took much the same approach >(adding authentication extensions to the Registration request >and response messages) in RFC 2002. However, for carrier >deployments, centralized authentication management is required >and so now they are looking at a challenge-response option. > > From dhcp-v4@bucknell.edu Thu Jul 22 03:42: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 DAA10203 for ; Thu, 22 Jul 1999 03:42:47 -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 DAA04769; Thu, 22 Jul 1999 03:42:38 -0400 (EDT) Date: Thu, 22 Jul 1999 03:42:38 -0400 (EDT) Message-Id: <00dc01bed414$254d2600$2a8939cc@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: RE: Another question on draft-ietf-dhc-authentication-11.txt 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 presented a generalization of the Droms/Arbaugh authentication >draft in Oslo (draft-gupta-dhcp-auth-00.txt) which supports >public-key based authentication. It also describes how to support >roaming -- there are similarities here with your draft titled >"Certificate based Roaming" (in roamops). Yes, I think that the approaches are similar. The issue with securing a DHCP message (or Mobile IP registration for that matter) with an authentication option is that to support centralized authentication management (required by most enterprises and ISPs) you need to not only encapsulate the message for validation, but also need to send along the proposed response for signing. This is more than a little awkward. In contrast, including a credential that is verifiable without such proxying (such as a Kerberos ticket or public-key signature) is cleaner. >Could you please review the generalization and post >your feedback on whether or not that >approach is suitable for the scenarios you have in mind. I will read the draft in detail and comment on it. From dhcp-v4@bucknell.edu Thu Jul 22 03:46: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 DAA10242 for ; Thu, 22 Jul 1999 03:46: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 DAA31178; Thu, 22 Jul 1999 03:46:13 -0400 (EDT) Date: Thu, 22 Jul 1999 03:46:13 -0400 (EDT) Message-Id: <00dd01bed416$61d3ebc0$2a8939cc@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: Another question on draft-ietf-dhc-authentication-11.txt 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 >We weren't expecting to use the same password that the user of the >DHCP client uses for personal authentication - the security >implications of this are not good. That's fine. However, even if you want to maintain a separate password for DHCP, I think that customers will want this placed in a central store, like a directory, rather than being kept on the DHCP server. >Ken Hornstein and I discussed a way of using Kerberos authentication. I'd be interested to hear more about this. The problem of course is that typically you won't have a TGT prior to doing a DHCP Discover so that you can't include a DHCP service ticket in that message. Also, you don't have an IP address, and so would need to obtain a TGT with no address and presumably a short lifetime. This can be done by having the DHCP server act as a passthrough for a conversation between the DHCP Client and the KDC. The problem is how to actually authenticate to the DHCP service in the short number of messages that you have available. Hats off to you if you can make this work without changing the state machine :) >Does this involve public key cryptography? The Challenge-Response draft in Mobile IP WG does not involve public key crypto, no. The goal of that is simplifying the proxy authentication case. Of course, public key cryptography is another solution. From dhcp-v4@bucknell.edu Thu Jul 22 10:22: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 KAA22684 for ; Thu, 22 Jul 1999 10:22: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 KAA04997; Thu, 22 Jul 1999 10:13:39 -0400 (EDT) Date: Thu, 22 Jul 1999 10:13:39 -0400 (EDT) Message-Id: <199907221319.JAA04759@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: Another question on draft-ietf-dhc-authentication-11.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > The problem of course > is that typically you won't have a TGT prior to doing a DHCP Discover > so that you can't include a DHCP service ticket in that message. This is actually not a problem - the current protocol does not authenticate DHCPDISCOVER messages. > Also, you don't have an IP address, and so would need to > obtain a TGT with no address and presumably a short lifetime. Ah! Still not a problem. The DHCP server knows what your IP address will be. _It_ asks for a TGT for you, using your IP address, and sends it to you in the DHCPOFFER packet, along with a user-to-user ticket that you can decrypt with the TGT once you've decrypted it with your password (Ken groks exactly how this works - I don't). > Hats off to you > if you can make this work without changing the state machine :) Ken actually came up with the idea, so if it works, it's to him that you should take your hat off! :') _MelloN_ From dhcp-v4@bucknell.edu Thu Jul 22 14:25: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 OAA01805 for ; Thu, 22 Jul 1999 14:25: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 MAA30722; Thu, 22 Jul 1999 12:52:57 -0400 (EDT) Date: Thu, 22 Jul 1999 12:52:57 -0400 (EDT) Message-Id: <199907221610.MAA05202@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: Kerberos for DHCP authentication X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > 1. In the KRB_AS_REQ, I assume that there will be no > pre-auth data, correct? Hm. Assuming that the client knows it's going to potentially authenticate with Kerberos, it could send a pre-authenticator in the DHCPDISCOVER packet. It would be impossible to use the DHCP server key selection mechanism if a client might need to authenticate in more than one realm, though. I will let Ken address questions 2, 3 and 4, assuming he has time (I haven't talked to him in a while!). I think you have it right, though. > 5. Is it possible to support mutual authentication? For > example, does the DHCP Server return an authenticator in > the DHCK ACK? The DHCP server is supposed to authenticate every packet it sends, actually. It's only the client that gets to forgo authenticating the DHCPDISCOVER - everything else should be signed. > This is pretty cool. Hat's off to you, Ken! Yup. I was pretty impressed when he described it to me! :') _MelloN_ From dhcp-v4@bucknell.edu Thu Jul 22 14:26: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 OAA01866 for ; Thu, 22 Jul 1999 14:26: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 MAA03827; Thu, 22 Jul 1999 12:49:54 -0400 (EDT) Date: Thu, 22 Jul 1999 12:49:54 -0400 (EDT) Message-Id: <00ed01bed45e$66163ba0$2a8939cc@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: Kerberos for DHCP authentication 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 >Ah! Still not a problem. The DHCP server knows what your IP address >will be. _It_ asks for a TGT for you, using your IP address, and >sends it to you in the DHCPOFFER packet, along with a user-to-user >ticket that you can decrypt with the TGT once you've decrypted it with >your password (Ken groks exactly how this works - I don't). Questions: 1. In the KRB_AS_REQ, I assume that there will be no pre-auth data, correct? Fitting in pre-auth would be nice since you could then prevent a bogus user from obtaining a ticket/session key package that they can then attempt to crack by brute force (since it's encrypted in a key derived from the user's password). Also, you could then support public key authentication via PKINIT. 2. The addresses field will be set to the the client address, and the FORWARDABLE flag will be set, no? The resulting TGT will have the FORWARDED flag set, correct? 3. The DHCP server will receive the KRB_AS_REP and then forward this along in the DHCP Offer. The enclosed TGT will have the addresses field set to the client address, no? 4. To obtain a user-user ticket, the DHCP server will need to include the client's TGT as well as it's own in a KRB_AS_REQ. This message will have the ENC-TKT-IN-SKEY flag set, and will include the client's TGT in the additional-tickets field. In order for the DHCP server to obtain the client's TGT this and an authenticator are included in the DHCP REQUEST, no? 5. Is it possible to support mutual authentication? For example, does the DHCP Server return an authenticator in the DHCK ACK? >Ken actually came up with the idea, so if it works, it's to him that >you should take your hat off! :') This is pretty cool. Hat's off to you, Ken! From dhcp-v4@bucknell.edu Thu Jul 22 14:33: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 OAA02114 for ; Thu, 22 Jul 1999 14:33: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 NAA19481; Thu, 22 Jul 1999 13:49:25 -0400 (EDT) Date: Thu, 22 Jul 1999 13:49:25 -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: RE: RE: Another question on draft-ietf-dhc-authentication-11.txt 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 > From: "Bernard Aboba" > To: , > > >I presented a generalization of the Droms/Arbaugh authentication > >draft in Oslo (draft-gupta-dhcp-auth-00.txt) which supports > >public-key based authentication. It also describes how to support > >roaming -- there are similarities here with your draft titled > >"Certificate based Roaming" (in roamops). > > Yes, I think that the approaches are similar. The issue > with securing a DHCP message (or Mobile IP registration for > that matter) with an authentication option is that to > support centralized authentication management (required > by most enterprises and ISPs) you need to not only > encapsulate the message for validation, but also > need to send along the proposed response for signing. > This is more than a little awkward. In contrast, including > a credential that is verifiable without such proxying > (such as a Kerberos ticket or public-key signature) > is cleaner. I agree. I have been closely involved with an implementation of Mobile IP that interfaces to a traditional (secret-key style) AAA infrastructure and the interface gets quite awkward because a big chunk of the message (the part that is covered by the MAC) needs to be passed to the verifier as well (along with the MAC). A public-key approach is much cleaner, IMHO. What is the current status of the certificate-based roaming proposal in roamops? The use of public-keys offers several advantages such as non-repudiation (which can go a long way towards addressing inter-ISP fraud) but given the large installed base of RADIUS-style servers, the switch could take a while. Is this what you've been hearing from the ISPs? > >Could you please review the generalization and post > >your feedback on whether or not that > >approach is suitable for the scenarios you have in mind. > > I will read the draft in detail and comment on it. Thanks. I look forward to your feedback. vipul From dhcp-v4@bucknell.edu Fri Jul 23 04:14: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 EAA26691 for ; Fri, 23 Jul 1999 04:14: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 EAA29568; Fri, 23 Jul 1999 04:14:09 -0400 (EDT) Date: Fri, 23 Jul 1999 04:14:09 -0400 (EDT) Message-Id: <011601bed4e3$0e36f520$2a8939cc@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: RE: Another question on draft-ietf-dhc-authentication-11.txt 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 > What is the current status of the certificate-based roaming > proposal in roamops? The use of public-keys offers several > advantages such as non-repudiation (which can go a long way > towards addressing inter-ISP fraud) but given the large > installed base of RADIUS-style servers, the switch could > take a while. Is this what you've been hearing from the ISPs? The current status is that the draft is progressing and appears to address most security concerns. As a result, I would like to see the approach applied to other areas, including DHCP and Mobile IP. There are a few elements needed to make this scenario work: 1. PKI support on clients (user cert). 2. PKI support on servers (DHCP or RADIUS server machine cert) 3. Protocol support on clients and servers (e.g. authenticated DHCP w/public key option, or EAP support). Element #2 is typically not an issue; lots of people have gotten certificates for servers nowadays, from Verisign or elsewhere, and most ISPs are comfortable with this. Element #3 is typically provided by a vendor, and is under ISP control and typically represents an incremental upgrade, so this is usually not an issue. The big issue is #1. I was at a conference recently where the question was asked "if your company has ever piloted PKI, raise your hand." Around half the hands went up. Then the speaker asked "How many of you are ready to roll this out within 12 months?" and only around half of the original people raised their hand. >From this I garner that PKI rollouts are quite formidable, even for the largest enterprise customers. That doesn't mean that they won't eventually happen, or that it's not worthwhile to keep working on this. It just means that you have to offer both the PKI and a non-PKI alternative. I would note that the Kerberos authentication method that Ted and Ken have described would also appear to work for cross-realm authentication and so can enable roaming in the non-PKI case. Here's how I think this would work: a. After receiving the DHCP DISCOVER, the DHCP server uses its TGT in order to formulate a KRB_AP_REQ in order to obtain a cross-realm TGT. b. The DHCP server then requests a forwardable TGT from the home realm KDC, using the pre-auth data sent by the user in the DHCP DISCOVER and the IP address that it will include in the DHCP Offer. It passes the KRB_AP_REP back to the user in the DHCP OFFER. c. The user then decrypts the KRB_AP_REP and sends the TGT and an authenticator in the DHCP Request. d. The DHCP server uses this TGT along with its own cross-realm TGT in order to obtain a user-user ticket for the home realm, which it sends back to the user in the DHCP ACK. From dhcp-v4@bucknell.edu Fri Jul 23 17:06: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 RAA12444 for ; Fri, 23 Jul 1999 17:06:23 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA05799; Fri, 23 Jul 1999 17:05:46 -0400 (EDT) Date: Fri, 23 Jul 1999 17:05:46 -0400 (EDT) Message-Id: <01C843625423D211AC3F00A0C969E890032B0B8A@orsmsx35.jf.intel.com> Errors-To: droms@bucknell.edu Reply-To: myron.hattig@intel.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Hattig, Myron" To: Multiple recipients of list Subject: chaddr len = 0 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 Ted, I'm told you're the person to ask about the best solution for chaddr on 1394 networks. This relates to the "DHCP extensions for 1394" discussion that took place at the Oslo IETF meeting last week. The options discussed were to have len = 0 or have len = 8 then use the EUI-64 ID as the value. We discussed using the 1394 16-bit node id but that is a bad idea. 1394 node ids are the source and destination values in 1394 packets. Unfortunately 1394 node IDs change when a 1394 device is added or removed from the bus. This discounts node IDs as a candidate for the chaddr. The EUI-64 is a globally unique number associated with each link/phy 1394 interface (there is not one EUI-64 per port, just one EUI-64 per the link/phy chipset). The EUI-64 is not a link layer packet source or destination addrs. Thus the normal function of EUI-64 is not equal to the normal function of a chaddr value (at least my understanding of a chaddr). Looking at the function provided by chaddr and the numbers available from 1394, it seems chaddr for 1394 should be NULL with a length of zero. Some say a chaddr of len 0 will break many DHCP implementations. The first question is: Will many implementations break with a chaddr len = 0? If yes, then is it reasonable to expect people to fix their implementations to support chaddr len = 0? Is it a better option for 1394 devices to put the EUI-64 in the chaddr field? Will some implementations use this as a dst/src MAC address inappropriately? Thanks, -myron > -----Original Message----- > From: Ted Lemon [mailto:mellon@isc.org] > Sent: Thursday, July 15, 1999 6:09 AM > To: Multiple recipients of list > Subject: Re: UUID client ID > > > > > It seems that the global 802 MAC address and EUI-64 are also useful > > for the authentication. > > Do you mean as a global identifier, or as actual authentication? > They're probably useful as a global identifier, although 48 bits is > kind of small nowadays for a global identifier and will come to seem > even smaller as time goes by. > > _MelloN_ > From dhcp-v4@bucknell.edu Fri Jul 23 18:29: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 SAA12856 for ; Fri, 23 Jul 1999 18:29: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 SAA03658; Fri, 23 Jul 1999 18:29:40 -0400 (EDT) Date: Fri, 23 Jul 1999 18:29:40 -0400 (EDT) Message-Id: <21839C593E75D211BF7800805FCCD0264B08F6@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: chaddr len = 0 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; X-Mailer: Internet Mail Service (5.5.2448.0) Mime-Version: 1.0 Myron-- I won't pretend to be an authority on other servers than the one I nurture very carefully for our high-reliability environment, but in general, I don't much like the idea of zero length chaddr's. Having said that, I do understand the difficulty in transferring a mechanism designed for a different medium to the IEEE-1394 environment, and don't want to be too arbitrary about what packets my server will accept. We go far beyond the validation built into the ISC server -- we cross-check every single BOOTP packet header field and discard any packet that does not completely conform to published layouts. Note that this is quite the opposite of the old programmer's maxim, "Be liberal in what you accept, but conservative in what you offer." The major difference in philosophies comes from our business requirement to provide nearly 100% availability of all operations support systems. We routinely reject vendor equipment as unsuitable for our environment because it does not conform to these policies. I suggest that a chaddr length of zero, while it wouldn't pass our current packet filters, might not be a devastating thing to accept if there were some way to clearly and unambiguously identify the sender as an IEEE-1394 interface. If there is a unique hardware type octet that identifies an IEEE-1394 interface, that would work well for me. But if the only way to distinguish an IEEE-1394 interface is to infer it from a missing chaddr, I would tell you to go back to the drawing board and start over.... How could I tell a broken client from a firewire client in that case? In your note you mentioned that the node ID changes as devices are added or dropped from a firewire interface, rendering it unusable for identifying the source or destination of a packet. However, you didn't really explain enough about the EUI to know if it is an appropriate substitute. So, how does one uniquely identify the source and destination of data packets on a firewire interface? The answer to that question, it seems to me, is the answer to the question "what to use in place of chaddr?" As the current version of the DHC RFC uses the hardware address as the final determinant of client identity (it MUST be present if client-identifier is not), how could a server do anything but discard a received packet having a null chaddr and no client-identifier? Also, what is the hardware type octet for IEEE-1394? Does such a concept exist? Is there some way to absolutely identify a firewire interface that would serve the same purpose? [I realize that Kenji covered this some time ago on the mailing list, but I want to be very certain that we have the same understanding, so, I ask again....] Finally, one has to consider who/what would have to change to have a null chaddr. You probably cannot change client behavior because there are too many clients, which cannot be expected to change just because of a new option. That leaves DHCP servers. If there is an unambiguous way to determine the source and destination address of a packet, then the servers will change to accommodate it -- but not if there isn't! --Barr > From: Hattig, Myron[SMTP:myron.hattig@intel.com] > Sent: Friday, July 23, 1999 2:07 PM > To: Multiple recipients of list > Subject: chaddr len = 0 > > Ted, > > I'm told you're the person to ask about the best solution for chaddr on > 1394 networks. This relates to the "DHCP extensions for 1394" discussion > that took place at the Oslo IETF meeting last week. The options discussed > were to have len = 0 or have len = 8 then use the EUI-64 ID as the value. > > We discussed using the 1394 16-bit node id but that is a bad idea. 1394 > node ids are the source and destination values in 1394 packets. > Unfortunately 1394 node IDs change when a 1394 device is added or > removed from the bus. This discounts node IDs as a candidate for the > chaddr. > > The EUI-64 is a globally unique number associated with each link/phy > 1394 interface (there is not one EUI-64 per port, just one EUI-64 per > the link/phy chipset). The EUI-64 is not a link layer packet source or > destination addrs. Thus the normal function of EUI-64 is not equal to > the normal function of a chaddr value (at least my understanding of > a chaddr). > > Looking at the function provided by chaddr and the numbers available > from 1394, it seems chaddr for 1394 should be NULL with a length of > zero. Some say a chaddr of len 0 will break many DHCP implementations. > > The first question is: Will many implementations break with a chaddr > len = 0? > If yes, then is it reasonable to expect people to fix their > implementations > to support chaddr len = 0? > Is it a better option for 1394 devices to put the EUI-64 in the chaddr > field? Will some implementations use this as a dst/src MAC address > inappropriately? > > From dhcp-v4@bucknell.edu Sat Jul 24 15:05: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 PAA07809 for ; Sat, 24 Jul 1999 15:05: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 PAA15811; Sat, 24 Jul 1999 15:04:48 -0400 (EDT) Date: Sat, 24 Jul 1999 15:04:48 -0400 (EDT) Message-Id: <199907241831.DAA07567@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: chaddr len = 0 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 >I suggest that a chaddr length of zero, while it wouldn't pass our current >packet filters, might not be a devastating thing to accept if there were >some way to clearly and unambiguously identify the sender as an IEEE-1394 >interface. If there is a unique hardware type octet that identifies an >IEEE-1394 interface, that would work well for me. 'htype' for IEEE1394 node is 24. http://www.isi.edu/in-notes/iana/assignments/arp-parameters So, it will not be a problem. >As the current >version of the DHC RFC uses the hardware address as the final determinant of >client identity (it MUST be present if client-identifier is not), how could >a server do anything but discard a received packet having a null chaddr and >no client-identifier? Our draft proposes as follows, : 'client identifier' option MUST be used in DHCP messages from the : client to the server due to the lack of the 'chaddr'. If chaddr is null and there is no client-ID, it is an illegal packet. I think such packet should be discarded. >Also, what is the hardware type octet for IEEE-1394? Does such a concept >exist? Is there some way to absolutely identify a firewire interface that >would serve the same purpose? 'htype' for IEEE1394 node is 24. Best Regards, Kenji Fujisawa From dhcp-v4@bucknell.edu Sun Jul 25 23:39: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 XAA07870 for ; Sun, 25 Jul 1999 23:39: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 XAA01826; Sun, 25 Jul 1999 23:38:42 -0400 (EDT) Date: Sun, 25 Jul 1999 23:38:42 -0400 (EDT) Message-Id: <199907260259.WAA06504@mail.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: dhcp-impl@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-impl@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: Who know the real implemantion of DHCP Client on Java Platform X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="iso-8859-1" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA07870 Message forwarded from hezhongshu@hotmail.com: Dear friends,     Who know the real implemantion of DHCP Client on Java Platform?     I have tried the JDHCP client examples from JDHCP project Page.But the code is only ok when my computer has IP address.I think the DHCP is used to get the IP address,so this is one problem.     I want to get a real implemention of JDHCP client.This is very important for me.     Who can help me?     Please help me! sincerely Hezhongshu  From dhcp-v4@bucknell.edu Mon Jul 26 07:33: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 HAA25305 for ; Mon, 26 Jul 1999 07:33: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 HAA21585; Mon, 26 Jul 1999 07:32:25 -0400 (EDT) Date: Mon, 26 Jul 1999 07:32:25 -0400 (EDT) Message-Id: <199907261130.HAA27796@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: Kerberos for DHCP authentication 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 KENH@GINGER.CMF.NRL.NAVY.MIL follows. ----------------------------------------------------------------------------- I hope y'all will forgive me for not answering these messages until now; I must have caught a nasty bug coming back from the Oslo IETF, and I was out all this past week from work. Now, setting the dial on the Wayback machine .... Ted, we talked about this at the Orlando IETF, right? IIRC, you wanted to do Kerberos for DHCP, but you didn't want to add new round-trips to the protocol. I came up with this user-to-user based authentication scheme. >>Ah! Still not a problem. The DHCP server knows what your IP address >>will be. _It_ asks for a TGT for you, using your IP address, and >>sends it to you in the DHCPOFFER packet, along with a user-to-user >>ticket that you can decrypt with the TGT once you've decrypted it with >>your password (Ken groks exactly how this works - I don't). Just as an explanation: - The idea in U2U authentication is that two people who only have TGTs can authenticate. Basically, one of the parties agrees to send the encrypted part of their TGT to the the other party, who bundles them both up and sends them to the KDC as a TGS_REQ, with ENC-TKT-IN-SKEY set. You get back a standard TGS_REP, _except_ that the "server" ticket is encrypted with the session key from the "additional" ticket (normally it would be encrypted with the principal's key, which in the case of a user would be their password, which means that they would have to enter it again, which is generally frowned upon). - My idea (as I remember) was that the DHCP server could do the client's AS_REQ for them, take the encrypted part and bundle it up as the "additional" ticket and do a TGS_REQ to the KDC; the TGS_REP could be used for authentication between the DHCP server and client. (Yes, I'm being terse; sorry Ted :-) ). >1. In the KRB_AS_REQ, I assume that there will be no >pre-auth data, correct? Pretty much so, unfortunately. You would need the client's key to do any preauth at this point (since the DHCP server is doing it for you at this time ...). Generally preauth involves a couple of round-trips (hey, you need preauth! okay, here it is). I suppose if the client _knew_ the preauth needed, it could send it in the initial DHCP request. >2. The addresses field will be set to the >the client address, and the FORWARDABLE flag will be >set, no? The resulting TGT will have the FORWARDED flag set, >correct? Well, it's not actually required for this to work. >3. The DHCP server will receive the KRB_AS_REP and >then forward this along in the DHCP Offer. The enclosed >TGT will have the addresses field set to the client address, no? Right. >4. To obtain a user-user ticket, the DHCP server will need to >include the client's TGT as well as it's own in a KRB_AS_REQ. >This message will have the ENC-TKT-IN-SKEY flag set, and will >include the client's TGT in the additional-tickets field. Well, it's actually a TGS_REQ. And now you see the dark secret to this protocol. The DHCP server will have to maintain a current TGT for this to work. Not rocket science, but it will be a small bit of work. >In order for the DHCP server to obtain the client's >TGT this and an authenticator are included in the >DHCP REQUEST, no? Just the TGT; you don't need an authenticator for U2U (at this point, at least, and you don't know enough to generate an authenticator). >5. Is it possible to support mutual authentication? For >example, does the DHCP Server return an authenticator in >the DHCK ACK? I was thinking that at this point, you would send an AP_REQ, which would of course include an authenticator. Hmmm, okay, more is coming back to me now. I was thinking that it would look something like: Client Server ------------------------------------------------------------ DHCPDICOVER -------------------> Includes client principal and other information for client AS_REQ Makes AS_REQ on behalf of client Does TGS_REQ for U2U packet <------------------------------ DHCPOFFER Includes AS_REP from client principal Includes AP_REQ using U2U TGS_REP info Client decrypted AS_REP Client validates AP_REQ (using session key from AS_REP) DHCPREQUEST -------------------> Authenticated, using now-shared session key (probably use AP_REP). AP_REP is validated, mutual authentication is complete. <------------------------------ DHCPACK Authenticated maybe with KRB_SAFE. Does that make sense? --Ken From dhcp-v4@bucknell.edu Mon Jul 26 09:14:59 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03781 for ; Mon, 26 Jul 1999 09:14:58 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA32474; Mon, 26 Jul 1999 09:14:57 -0400 (EDT) Date: Mon, 26 Jul 1999 09:14:57 -0400 (EDT) Message-Id: 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: Who know the real implemantion of DHCP Client on Java Platform X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id JAA03781 > Message forwarded from hezhongshu@hotmail.com: > > Dear friends, >     Who know the real implemantion of DHCP Client on Java Platform? >     I have tried the JDHCP client examples from JDHCP project Page.But the > code > is only ok when my computer has IP address.I think the DHCP is used to get > the IP address,so this is one problem. >     I want to get a real implemention of JDHCP client.This is very important > for me. >     Who can help me? >     Please help me! > sincerely > Hezhongshu  > Hezhongshu , A DHCP implementation on the Java platform would only be possible with additional (non JDK) interfaces, since it is not possible to do host parameter reconfiguration or open raw sockets with the base API. A DHCP client implementation would have to have platform specific (native) code. There is no reason in principal that this couldn't be done, but it wouldn't be 'pure.' Erik From dhcp-v4@bucknell.edu Mon Jul 26 11:42: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 LAA14086 for ; Mon, 26 Jul 1999 11:42:37 -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 LAA27060; Mon, 26 Jul 1999 11:42:21 -0400 (EDT) Date: Mon, 26 Jul 1999 11:42:21 -0400 (EDT) Message-Id: <199907261520.LAA24932@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: chaddr len = 0 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > The first question is: Will many implementations break with a chaddr > len = 0? I don't really know. The ISC server will not behave optimally in this situation, although I think it will work. You would have to ask Microsoft, Cisco, Sun, and all the other DHCP server vendors how their servers would operate. > If yes, then is it reasonable to expect people to fix their implementations > to support chaddr len = 0? I think it's reasonable to ask. Whether or not they will do it, I don't know. While you're asking them the first question, you can put the second to them if they answer no to the first... :') We at the ISC are very definitely willing to make the changes required to the server to make this work well. Of course, you haven't asked the question, "will vendor's DHCP servers work at all with firewire, as they are." This is a question worth asking. I don't have any equipment with which to try this, myself, so I don't know. > Is it a better option for 1394 devices to put the EUI-64 in the chaddr > field? I don't think it is. If you don't have a valid link-layer address to put in chaddr, I think it makes perfect sense to put nothing there, and I think it makes no sense at all to put something there that will not work as a link-layer address. > Will some implementations use this as a dst/src MAC address > inappropriately? Possibly. I don't know. What does firewire use as a link-layer address itself? Are all packets broadcast, and the IP destination address used as a discriminator? _MelloN_ From dhcp-v4@bucknell.edu Mon Jul 26 12:45: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 MAA16282 for ; Mon, 26 Jul 1999 12:45: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 MAA32081; Mon, 26 Jul 1999 12:45:36 -0400 (EDT) Date: Mon, 26 Jul 1999 12:45:36 -0400 (EDT) Message-Id: <01C843625423D211AC3F00A0C969E890032B0B95@orsmsx35.jf.intel.com> Errors-To: droms@bucknell.edu Reply-To: myron.hattig@intel.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Hattig, Myron" To: Multiple recipients of list Subject: RE: chaddr len = 0 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 don't think it is. If you don't have a valid link-layer address to > put in chaddr, I think it makes perfect sense to put nothing there, > and I think it makes no sense at all to put something there that will > not work as a link-layer address. Thanks, that is the answer that makes the most sense to me. > What does firewire use as a link-layer address itself? Are all > packets broadcast, and the IP destination address used as a > discriminator? 1394 uses a 16 bit node id. 10 bits identify the bus. 6 bits identify the node. The node id is ephemeral. It changes any time there is a bus reset. A bus reset occurs when a device is plugged into the bus or removed from the bus. Also, the software on a host can force a bus reset for error conditions or in some awful cases as a part of the initialization of a protocol or application. These comments and my simple-minded understanding of chaddr lead me to think the value of chaddr for 1394 nodes should be null. Maybe a less controversial way to say this is "don't use chaddr to identify a client". Then in addition say "only use client id". According to the rules described to me, servers only look at chaddr if client id is not used, thus this rule should work. Before flaming me for this comment, realize I'm not a DHCP expert. -myron From dhcp-v4@bucknell.edu Mon Jul 26 12:47: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 MAA16309 for ; Mon, 26 Jul 1999 12:47: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 MAA27426; Mon, 26 Jul 1999 12:47:07 -0400 (EDT) Date: Mon, 26 Jul 1999 12:47:07 -0400 (EDT) Message-Id: <199907261622.MAA25214@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: chaddr len = 0 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > These comments and my simple-minded understanding of chaddr lead me to > think the value of chaddr for 1394 nodes should be null. Maybe a less > controversial way to say this is "don't use chaddr to identify a client". Right. > Then in addition say "only use client id". According to the rules > described to me, servers only look at chaddr if client id is not > used, thus this rule should work. Before flaming me for this > comment, realize I'm not a DHCP expert. This sounds fine. One observation that I would have, though, is that if it's possible for IP to use the ephemeral link-layer address, it should also be possible for DHCP to use it - just not as an identifier. Whether or not this is important, I don't know - it'd be neater and cleaner to eliminate the broadcasts, but I'm not sure how much difference it would make in practice. The DHCP protocol already says the DHCP server is supposed to prefer the client identifier to the hardware address as an identifier, so as long as you require that all firewire DHCP clients send a DHCP client identifier, it would be legitimate to include the ephemeral id in chaddr and use it to unicast responses. _MelloN_ From dhcp-v4@bucknell.edu Mon Jul 26 13:39: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 NAA17360 for ; Mon, 26 Jul 1999 13:39:46 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA18261; Mon, 26 Jul 1999 13:39:37 -0400 (EDT) Date: Mon, 26 Jul 1999 13:39:37 -0400 (EDT) Message-Id: <01C843625423D211AC3F00A0C969E890032B0B99@orsmsx35.jf.intel.com> Errors-To: droms@bucknell.edu Reply-To: myron.hattig@intel.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Hattig, Myron" To: Multiple recipients of list Subject: RE: chaddr len = 0 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 > it would be legitimate to include the ephemeral id in > chaddr and use it to unicast responses. The problem is if the node ID changes after the host sends a chaddr to the server, then the server may be unicasting back to the wrong host. This may occur because values for the 6 bit phy portion of the 16 bit node id are always contiguous from 0 to the number of 1394 devices on the bus. Since there is no guarantee that a host retains the value it previously had before the bus reset, the DHCP server could be unicasting back to the wrong host. If DHCP servers only use chaddr for unicast responses or as a client identifiers, then it sounds like 1394 nodes should never use chaddr. And, client id should be the only client identifier. Well, I've convinced myself at least. ;-) -myron From dhcp-v4@bucknell.edu Mon Jul 26 13:40: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 NAA17398 for ; Mon, 26 Jul 1999 13:40:34 -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 NAA04432; Mon, 26 Jul 1999 13:40:34 -0400 (EDT) Date: Mon, 26 Jul 1999 13:40:34 -0400 (EDT) Message-Id: <199907261720.NAA25399@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: chaddr len = 0 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > The problem is if the node ID changes after the > host sends a chaddr to the server, then the server > may be unicasting back to the wrong host. So how does TCP/IP over firewire deal with this problem? _MelloN_ From dhcp-v4@bucknell.edu Mon Jul 26 13:41: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 NAA17422 for ; Mon, 26 Jul 1999 13:40:58 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA12023; Mon, 26 Jul 1999 13:40:56 -0400 (EDT) Date: Mon, 26 Jul 1999 13:40:56 -0400 (EDT) Message-Id: <01C843625423D211AC3F00A0C969E890032B0B9B@orsmsx35.jf.intel.com> Errors-To: droms@bucknell.edu Reply-To: myron.hattig@INTEL.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Hattig, Myron" To: Multiple recipients of list Subject: RE: chaddr len = 0 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 > > The problem is if the node ID changes after the > > host sends a chaddr to the server, then the server > > may be unicasting back to the wrong host. > > So how does TCP/IP over firewire deal with this problem? Flush ARP cache after bus reset. Flush queued send/rcv packets after bus rest. Bus resets are not so common that a large part of the bandwidth is consumed with ARP, but they are common enough (specially during initialization; as when DHCP will most likely be used) that node IDs should not be used as persistent values. -myron From dhcp-v4@bucknell.edu Mon Jul 26 15:42: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 PAA20503 for ; Mon, 26 Jul 1999 15: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 PAA04152; Mon, 26 Jul 1999 15:42:36 -0400 (EDT) Date: Mon, 26 Jul 1999 15:42:36 -0400 (EDT) Message-Id: <199907261849.OAA25574@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: chaddr len = 0 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Bus resets are not so common that a large part of the > bandwidth is consumed with ARP, but they are common > enough (specially during initialization; as when DHCP > will most likely be used) that node IDs should not > be used as persistent values. Hm. I guess. The thing is that DHCP already has a process for dealing with lossage of this sort - we retry. So if a bus reset occurred after a DHCPDISCOVER or DHCPREQUEST was sent but before the response came back, the retry would take care of it. Whether this is better than just broadcasting, I don't know - I don't see a clear advantage to either method, really. _MelloN_ From dhcp-v4@bucknell.edu Mon Jul 26 17:47: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 RAA22656 for ; Mon, 26 Jul 1999 17:47: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 RAA18523; Mon, 26 Jul 1999 17:47:43 -0400 (EDT) Date: Mon, 26 Jul 1999 17:47:43 -0400 (EDT) Message-Id: <199907262013.QAA15865@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: Mailing list changes 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 In preparation for combining the several DHCPv4 and DHCPv6 mailing lists into two lists, I've disable SUBSCRIBE and UNSUBSCRIBE requests to the dhcp-dns, dhcp-bake, dhcp-impl, dhcp-serve and dhcp-v6impl mailing lists. In the next day or two, I will merge the subscription lists for those mailing lists into the dhcp-v4 and dhcp-v6 mailing lists. I'll let you know when the changes to the mailing lists are complete... - Ralph From dhcp-v4@bucknell.edu Mon Jul 26 21:19: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 VAA26623 for ; Mon, 26 Jul 1999 21:19: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 VAA20815; Mon, 26 Jul 1999 21:19:33 -0400 (EDT) Date: Mon, 26 Jul 1999 21:19:33 -0400 (EDT) Message-Id: <199907270100.JAA10902@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: chaddr len = 0 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 >> Bus resets are not so common that a large part of the >> bandwidth is consumed with ARP, but they are common >> enough (specially during initialization; as when DHCP >> will most likely be used) that node IDs should not >> be used as persistent values. > >Hm. I guess. The thing is that DHCP already has a process for >dealing with lossage of this sort - we retry. So if a bus reset >occurred after a DHCPDISCOVER or DHCPREQUEST was sent but before the >response came back, the retry would take care of it. Whether this is >better than just broadcasting, I don't know - I don't see a clear >advantage to either method, really. There is another issue related 1394 nodeID. As I wrote before, : 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 To solve this problem, in the case of ARP over 1394, we have chosen to use nodeID IN THE 1394 HEADER. There is no nodeID in the ARP payload. But for DHCP, DHCP relay can not send link header information to the DHCP server, and vice versa. This is another reason to use broadcast reply for DHCP/1394. Best Regards, Kenji Fujisawa From dhcp-v4@bucknell.edu Tue Jul 27 11:28: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 LAA11596 for ; Tue, 27 Jul 1999 11:28: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 LAA15639; Tue, 27 Jul 1999 11:27:27 -0400 (EDT) Date: Tue, 27 Jul 1999 11:27:27 -0400 (EDT) Message-Id: <01C843625423D211AC3F00A0C969E890032B0BAB@orsmsx35.jf.intel.com> Errors-To: droms@bucknell.edu Reply-To: myron.hattig@intel.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Hattig, Myron" To: Multiple recipients of list Subject: RE: chaddr len = 0 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 Ted wrote: >>Hm. I guess. The thing is that DHCP already has a process for >>dealing with lossage of this sort - we retry. So if a bus reset >>occurred after a DHCPDISCOVER or DHCPREQUEST was sent but before the >>response came back, the retry would take care of it. Whether this is >>better than just broadcasting, I don't know - I don't see a clear >>advantage to either method, really. Kenji wrote: > This is another reason to use broadcast reply for DHCP/1394. Based on what I've heard so far, I agree with Kenji - use DHCP broadcast. There are too many corner cases with unicasting via 1394 node id. -myron From dhcp-v4@bucknell.edu Tue Jul 27 13:14: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 NAA15272 for ; Tue, 27 Jul 1999 13:14: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 NAA25850; Tue, 27 Jul 1999 13:14:20 -0400 (EDT) Date: Tue, 27 Jul 1999 13:14:20 -0400 (EDT) Message-Id: <199907271552.LAA28456@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: chaddr len = 0 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Based on what I've heard so far, I agree with Kenji - use DHCP broadcast. > There are too many corner cases with unicasting via 1394 node id. Okay, you all have talked me into it... :') _MelloN_ From dhcp-v4@bucknell.edu Tue Jul 27 15:21: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 PAA18538 for ; Tue, 27 Jul 1999 15:21:53 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA04924; Tue, 27 Jul 1999 15:18:08 -0400 (EDT) Date: Tue, 27 Jul 1999 15:18:08 -0400 (EDT) Message-Id: <199907271835.OAA03852@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: Testing merged mailing 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 I've merged the various DHCPv4-related mailing lists into the primary mailing list, dhcp-v4@bucknell.edu. This message is a test of the merged subscription list. I elminated as many duplicate subscriptions as I could find. If you receive multiple copies of this message, it's likely that you are subscribed more than once under different e-mail addresses. Please try to determine which addresses are duplciates, and unsubscribe any unwanted addresses. If you run into trobule (as a last resort), drop me a note and I'll try to fix up any problems. - Ralph Droms From dhcp-v4@bucknell.edu Wed Jul 28 08:11: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 IAA06394 for ; Wed, 28 Jul 1999 08:11: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 IAA15932; Wed, 28 Jul 1999 08:07:08 -0400 (EDT) Date: Wed, 28 Jul 1999 08:07:08 -0400 (EDT) Message-Id: <199907281149.HAA03958@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: *DRAFT* of minutes from Oslo WG meeting X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Here is a draft of the minutes from the Oslo WG meeting. I've included both the DHCPv4 and DHCPv6 meeting minutes. Please respond with comments by this Friday, 7/30. - Ralph ===== The DHC working group met twice in Oslo. The first meeting was used for discussion of DHCPv4 issues. Thanks to Stuart Cheshire for taking notes for these minutes. Here is a summary of discussion items and resolutions: * DHCP authentication, Droms (for Arbaugh): Droms reviewed most recent draft. WG asked for revision: describe authentication for DHCPRELEASE, develop PKI example (Olafur Gudmundsson?), other minor fixes (to be submitted by WG). After revision is submitted, new draft will be submitted for WG last call. * DHCP authentication, Gupta: reviewed recent draft proposing "protocol 2" for Droms/Arbaugh authentication. Gupta proposal is a generalization of the Droms/Arbaugh mechanism that supports public keys and roaming; new features include: - Support for PK authentication - Replay counter field replaced with replay-detection field - MAC field replaced with authenticator field which may contain PK signatures as well as shared-key MAC In response to question about merging Droms/Arbaugh and Gupta protocols, WG consensus is to leave as two separate protocols. Droms/Arbaugh will review Gupta proposal to determine if modifications to packet format are warranted to accommodate Gupta "replay detection method" field. * Name service search order, Smith: reviewed recent draft proposing new option for specifying name service search order; e.g., NIS+, NIS, DNS. WG reacted favorably and asked for final draft that will be submitted for WG last call. * DHCP-DNS interaction, Stapp: reviewed changes in recent draft: added optional use of DNS encoding for FQDN, clarified administrators' options in deployment, tightened and clarified language, revise key RR protocol. Narten raised issue of obtaining key RR number; he and Stapp will obtain number and then go to last call within a month. * DHCP failover protocol, Volz: reveiwed changes in most recent draft; most significant is exclusive use of TCP. Kinnear will schedule teleconferences for: TCP, load balancing, security over next month to finish draft before Washington IETF. * LDAP schema for DHCP, Volz: reported on most recent revision to LDAP schema draft. Volz noted that the schema has several shortcomings that a policy-oriented schema might eliminate. Yet, a policy-oriented schema would be rather difficult to map to current servers. He sees three alternatives for moving forward: 1) continue with current direction; 2) move to more policy-based model; 3) scale back to record only lease information and not configuration information. Discussion to continue on mailing list. * DHCP over IEEE 1394, Fujisawa: reviewed recent draft. Fujisawa explained key architectural issue that affects use of DHCP: node IDs can change at any time; e.g., whenever new device is plugged into bus. Thus, node ID cannot be used for client's hardware address and for client identification. WG discussed use of EUI-64, UUID as client identifier and client hardware address for DHCP. Issues will be taken to mailing list for further discussion. * Futures panel, Droms (for Carney): reviewed recent draft report from futures panel. No comment from WG; will report to Carney and determine if draft needs further revision before WG last call. * WG administrative details, Droms: - WG agreed to collapse all DHCP mailing lists into two lists: dhcp-v4 and dhcp-v6 - No support for user class option; will confirm with message to mailing list and then remove from WG charter - Bill Westerfield agreed take over server selection option - Mark Stapp agreed to complete option code recovery process The second WG meeting was used for discussion of recent developments in DHCPv6 process: * Mike Carney has agreed to become an author of the documents. He will have control of the documents' sources. * Mike, Jim and Charlie plan to have a revision to the documents complete by the Washington IETF. * The WG agreed on the following plan for completion of the documents: - Develop list of issues to resolve; obtain WG consensus that list is as complete and appropriate as possible - Develop solutions to issues from list; obtain WG consensus that solutions are correct - Revise document based on solutions - Obtain WG consensus that solutions are captured in revisions to specification - Revise document for WG last call - WG last call * The WG developed an expanded list of goals and delivery target dates; - List of issues: 8/15/99 - Solutions to issues: 10/ 1/99 - Revised draft: 11/10/99 (Washington IETF) - Consensus on solutions - Revised draft: 3/ 1/00 (Australia IETF) - WG last call * The WG developed the following list of issue areas and developed issues in each area. The areas are: - Current technical issues * Undiscussed issues from Minnesota WG meeting (NOTE: this list of leftover issues will be added to the minutes before submission to the IETF. - RD) * Unresolved issues from WG last call * Releasing resources: too many alternatives? * (Section 6) Is the mandate for implementation strategy too strong? Why is XID transaction cache described in such detail? * Which messages are not idempotent (and why not)? * How does a client request addresses from multiple prefixes? * Does the RECONFIGURE mechanism scale w.r.t ACK implosion? New RECONFIGURE reduces messages from 2N to N, but N may still be large. * In case of a RECONFIGURE failure, loosen text to specify "notify administrator" (rather than "log to error log"). * (Section 6.3.2) Clarify that 'C' bit semantics are to release all resources, reallocate only those requested in message. * (Section 6.4) What does client do with response; add MUST/SHOULD. - DHCPv4 features to carry forward/misfeatures to avoid/missing features to add * Extensibility framework: accommodate future extensions without requiring recoding/redeployment of clients * Vendor identifier/vnedor-encapsulated options * "Echo option" - client retains and echoes option value from server * Explicit "change server" mechanism * Client version option - DHCPv4 current work to review * Agent options * Failover protocol: any features in base DHCPv6 spec that would make inter-server protocol easier to write? * DHCP-DNS interaction - DHCPv6 new features * What must client do to support interaction with applications? * Consistency across client implementations: - List of client-supported options - Client can explicitly reject options as unsupported/unrequested - Alternative actions: what to do if option unrecognized, unrequested, ... - Requested values: client gives range of desired values * Model of "resources" and client-server management; what's the "right" model? - What is a "resource"? - What is "releasable"? * How does renubmering work; e.g., through RECONFIGURE? - Document structure * Organization - unclear when reading; information duplicated, not in same part of document, contradictory. Mike Carney to add protocol overview * Additional discussion needed about why complicated actions are mandated and how they were arrived at. WG to send input to authors about parts of the spec that require additional discussion. * Consider merging two documents into one. From dhcp-v4@bucknell.edu Thu Jul 29 10:22: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 KAA22015 for ; Thu, 29 Jul 1999 10:22: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 KAA20308; Thu, 29 Jul 1999 10:18:18 -0400 (EDT) Date: Thu, 29 Jul 1999 10:18:18 -0400 (EDT) Message-Id: <5104D4DBC598D211B5FE0000F8FE7EB202AB40B8@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: *DRAFT* of minutes from Oslo WG meeting X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="ISO-8859-1" Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) - No support for user class option; will confirm with message to mailing list and then remove from WG charter Ralph, I am interested in using the User Class option. I intend to write a draft describing in which context I'd like to use the User Class Option. Then I could take over the User Class option draft itself. Jerome Jerome Privat BT Labs From dhcp-v4@bucknell.edu Thu Jul 29 11:20: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 LAA23507 for ; Thu, 29 Jul 1999 11:20: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 LAA14250; Thu, 29 Jul 1999 11:16:06 -0400 (EDT) Date: Thu, 29 Jul 1999 11:16:06 -0400 (EDT) Message-Id: <199907291438.KAA06174@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* of minutes from Oslo WG meeting X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > - No support for user class option; will confirm with message to > mailing list and then remove from WG charter Indeed, I'd like to see the user class option too - I think it's a good idea. I'm surprised that there was consensus that it wasn't needed. How was the WG meeting attended? _MelloN_ From dhcp-v4@bucknell.edu Thu Jul 29 13:07: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 NAA26158 for ; Thu, 29 Jul 1999 13:07:46 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA24563; Thu, 29 Jul 1999 13:03:51 -0400 (EDT) Date: Thu, 29 Jul 1999 13:03:51 -0400 (EDT) Message-Id: <199907291533.LAA06405@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* of minutes from Oslo WG meeting X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Microsoft supports the user class option in both Windows 98 and the upcoming > Windows 2000. We've found it to be useful for a number of applications. > We, too, would like to see this be adopted by the WG. Wow, really? I have to check this out - how does it work? Is it in the initial Win98 distribution, or the update? Thanks! _MelloN_ From dhcp-v4@bucknell.edu Thu Jul 29 13:56: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 NAA28191 for ; Thu, 29 Jul 1999 13:56: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 NAA14128; Thu, 29 Jul 1999 13:52:08 -0400 (EDT) Date: Thu, 29 Jul 1999 13:52:08 -0400 (EDT) Message-Id: <005301bed9ea$599934e0$fe8ac8c6@agrabil-nt.quadritek.com> Errors-To: droms@bucknell.edu Reply-To: agrabil@quadritek.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: agrabil@quadritek.com (Greg Rabil) To: Multiple recipients of list Subject: RE: *DRAFT* of minutes from Oslo WG meeting X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit I've not seen it in Win98, but Windows 2000 Release Candidate 1 definitely supports User Class. It is configured using the command-line 'ipconfig' utility. Not very secure, though. For example, what's to stop a user from defining himself as a desktop system (as opposed to a laptop) and get long leases, if that is what some admin had configured the server to do (i.e. give long leases to user class "desktop" and short leases to user class "laptop"). Greg > -----Original Message----- > From: dhcp-v4@bucknell.edu [mailto:dhcp-v4@bucknell.edu]On Behalf Of Ted > Lemon > Sent: Thursday, July 29, 1999 1:05 PM > To: Multiple recipients of list > Subject: Re: *DRAFT* of minutes from Oslo WG meeting > > > > > Microsoft supports the user class option in both Windows 98 and > the upcoming > > Windows 2000. We've found it to be useful for a number of applications. > > We, too, would like to see this be adopted by the WG. > > Wow, really? I have to check this out - how does it work? Is it in > the initial Win98 distribution, or the update? > > Thanks! > > _MelloN_ > From dhcp-v4@bucknell.edu Thu Jul 29 14:46: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 OAA00128 for ; Thu, 29 Jul 1999 14:46: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 OAA26038; Thu, 29 Jul 1999 14:39:32 -0400 (EDT) Date: Thu, 29 Jul 1999 14:39:32 -0400 (EDT) Message-Id: <852567BD.0063D0BA.00@D51MTA10.pok.ibm.com> Errors-To: droms@bucknell.edu Reply-To: hoyoung@us.ibm.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: hoyoung@us.ibm.com To: Multiple recipients of list Subject: RE: *DRAFT* of minutes from Oslo WG meeting X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 See http://technet.microsoft.com/cdonline/Content/Complete/boes/bo/win2ksrv/technote/dhcpnt5.htm for details on DHCP for windows2000 Hannah From dhcp-v4@bucknell.edu Thu Jul 29 15:49: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 PAA01762 for ; Thu, 29 Jul 1999 15:49:18 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA17105; Thu, 29 Jul 1999 15:43:50 -0400 (EDT) Date: Thu, 29 Jul 1999 15:43:50 -0400 (EDT) Message-Id: <199907291914.PAA07130@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* of minutes from Oslo WG meeting X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Typically, I would imagine you'd want to use this option to have the server > give a particular set of options or a particular address, etc. Similar to > many typical uses of the vendor class option. I'm not sure I know any > better way for a client to identify it's user class, but just wanted to > point out how this is done in Win2000. Yup. Thanks! _MelloN_ From dhcp-v4@bucknell.edu Thu Jul 29 15:50: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 PAA01829 for ; Thu, 29 Jul 1999 15:50: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 PAA21462; Thu, 29 Jul 1999 15:41:58 -0400 (EDT) Date: Thu, 29 Jul 1999 15:41:58 -0400 (EDT) Message-Id: <000401bed9f6$2d5b1a40$fe8ac8c6@agrabil-nt.quadritek.com> Errors-To: droms@bucknell.edu Reply-To: agrabil@quadritek.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: agrabil@quadritek.com (Greg Rabil) To: Multiple recipients of list Subject: RE: *DRAFT* of minutes from Oslo WG meeting X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit > > Not very secure, though. For example, what's to stop a user from > > defining himself as a desktop system (as opposed to a laptop) and > > get long leases, if that is what some admin had configured the > > server to do (i.e. give long leases to user class "desktop" and > > short leases to user class "laptop"). > > Nothing whatever. If you want to use the client-supplied user class > for authorization, you are barking up the wrong tree. Using it to > differentiate between clients so as to make the network run more > smoothly, on the other hand, is a *good* idea. > I wasn't attempting to use user-class for any type of authorization. Just trying to point out some possible issues with allowing the end user to control his/her user class. BTW, I also agree that the intention of this option is a good idea, and, in general, I favor the option. > In the instance you cite, the reason why you want to have shorter > leases for laptops is so that they renew their leases more often, and > thus if they are disconnected from one subnet and moved to another, > they will quickly re-establish IP connectivity. Also, you get to > reclaim their lease sooner. On a well-maintained, DHCP-administered > network, there really is no advantage to having a longer lease - I > can't imagine why a user would even notice. > Again, I was just siting an example. Actually, this example is directly from the Microsoft Whitepaper which describes their reasons for supporting the user-class option. Typically, I would imagine you'd want to use this option to have the server give a particular set of options or a particular address, etc. Similar to many typical uses of the vendor class option. I'm not sure I know any better way for a client to identify it's user class, but just wanted to point out how this is done in Win2000. > _MelloN_ > From dhcp-v4@bucknell.edu Thu Jul 29 15:50: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 PAA01842 for ; Thu, 29 Jul 1999 15:50: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 PAA22939; Thu, 29 Jul 1999 15:39:44 -0400 (EDT) Date: Thu, 29 Jul 1999 15:39:44 -0400 (EDT) Message-Id: <199907291841.OAA06971@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* of minutes from Oslo WG meeting X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Not very secure, though. For example, what's to stop a user from > defining himself as a desktop system (as opposed to a laptop) and > get long leases, if that is what some admin had configured the > server to do (i.e. give long leases to user class "desktop" and > short leases to user class "laptop"). Nothing whatever. If you want to use the client-supplied user class for authorization, you are barking up the wrong tree. Using it to differentiate between clients so as to make the network run more smoothly, on the other hand, is a *good* idea. In the instance you cite, the reason why you want to have shorter leases for laptops is so that they renew their leases more often, and thus if they are disconnected from one subnet and moved to another, they will quickly re-establish IP connectivity. Also, you get to reclaim their lease sooner. On a well-maintained, DHCP-administered network, there really is no advantage to having a longer lease - I can't imagine why a user would even notice. _MelloN_ From dhcp-v4@bucknell.edu Thu Jul 29 16: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 QAA03125 for ; Thu, 29 Jul 1999 16:50: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 QAA29514; Thu, 29 Jul 1999 16:46:47 -0400 (EDT) Date: Thu, 29 Jul 1999 16:46:47 -0400 (EDT) Message-Id: <199907292020.QAA07388@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: Short vs Long leases [Was *DRAFT* of minutes from Oslo WG meeting] X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > There is certainly a case for shorter leases in the instance of a > transient users vs desktop users, and the ability to differentiate them > could be useful. Definitely. So are you saying that the absence of an enforcable authorization scheme is a problem in your mind, or do you feel that the user-class option as proposed is a workable solution to this problem for a reasonably large set of cases? _MelloN_ From dhcp-v4@bucknell.edu Thu Jul 29 18:01: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 SAA05081 for ; Thu, 29 Jul 1999 18:01:34 -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 RAA24534; Thu, 29 Jul 1999 17:58:41 -0400 (EDT) Date: Thu, 29 Jul 1999 17:58:41 -0400 (EDT) Message-Id: <199907292153.SAA29181@jupiter.accesscable.net> Errors-To: droms@bucknell.edu Reply-To: darth.vader@accesscable.net Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Hx Man To: Multiple recipients of list Subject: RE: *DRAFT* of minutes from Oslo WG meeting X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 unsubscribe Mike Lutwick At 02:41 PM 7/29/99 -0400, you wrote: >See >http://technet.microsoft.com/cdonline/Content/Complete/boes/bo/win2ksrv/tec hnote/dhcpnt5.htm > >for details on DHCP for windows2000 > >Hannah > From dhcp-v4@bucknell.edu Fri Jul 30 10:14: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 KAA03363 for ; Fri, 30 Jul 1999 10:14: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 KAA10857; Fri, 30 Jul 1999 10:08:26 -0400 (EDT) Date: Fri, 30 Jul 1999 10:08:26 -0400 (EDT) Message-Id: <199907301324.JAA21006@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: Short vs Long leases [Was *DRAFT* of minutes from Oslo WG 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 GRIMKIRK@HOME.COM follows. ------------------------------------------------------------------ Ted Lemon wrote: > Nothing whatever. If you want to use the client-supplied user class > for authorization, you are barking up the wrong tree. Using it to > differentiate between clients so as to make the network run more > smoothly, on the other hand, is a *good* idea. Agreed. > In the instance you cite, the reason why you want to have shorter > leases for laptops is so that they renew their leases more often, and > thus if they are disconnected from one subnet and moved to another, > they will quickly re-establish IP connectivity. Also, you get to > reclaim their lease sooner. On a well-maintained, DHCP-administered > network, there really is no advantage to having a longer lease - I > can't imagine why a user would even notice. In a fairly large enterprise, shorter leases can (and most likely will) cause a great deal of churning on the network, especially if they are symptomatically synchronized (everyone coming in at 8am), resulting in relatively unnecessary traffic and the potential for *some* congestion (when processed in volume). Imagine the traffic patterns generated by lease request/renewals in a company with 5000 nodes (all in the same time zone) between 7am and 9am on a Monday morning. There is certainly a case for shorter leases in the instance of a transient users vs desktop users, and the ability to differentiate them could be useful. I think I missed the posting (if there was one) of the "DRAFT of minutes from Oslo WG meeting", so I cannot comment upon any given proposal of such a facility. Nevertheless, just food for thought. -- )|( (o o) ------------------------------ooO-(_)-Ooo------------------------------ Michael Schneider Network Engineer grimkirk@home.com McKessonHBOC / Evanston Hospital 847/570-5173 -------------------------------oo0---0oo------------------------------- From dhcp-v4@bucknell.edu Fri Jul 30 10:23: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 KAA03574 for ; Fri, 30 Jul 1999 10:23: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 KAA32596; Fri, 30 Jul 1999 10:20:30 -0400 (EDT) Date: Fri, 30 Jul 1999 10:20:30 -0400 (EDT) Message-Id: <199907301325.JAA09343@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* of minutes from Oslo WG meeting X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 message sent to dhcp-v4@bucknell.edu by YEGU@EXCHANGE.MICROSOFT.COM follows. ---------------------------------------------------------------------------- Microsoft supports the user class option in both Windows 98 and the upcoming Windows 2000. We've found it to be useful for a number of applications. We, too, would like to see this be adopted by the WG. Thanks! Ye -----Original Message----- From: Ted Lemon [mailto:mellon@isc.org] Sent: Thursday, July 29, 1999 8:16 AM To: Multiple recipients of list Subject: Re: *DRAFT* of minutes from Oslo WG meeting > - No support for user class option; will confirm with message to > mailing list and then remove from WG charter Indeed, I'd like to see the user class option too - I think it's a good idea. I'm surprised that there was consensus that it wasn't needed. How was the WG meeting attended? _MelloN_ From dhcp-v4@bucknell.edu Fri Jul 30 10:24: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 KAA03638 for ; Fri, 30 Jul 1999 10:24:23 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA16914; Fri, 30 Jul 1999 10:22:10 -0400 (EDT) Date: Fri, 30 Jul 1999 10:22:10 -0400 (EDT) Message-Id: <199907301325.JAA04076@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: Help, DHCP Server on WinNT!!! 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 GINTASK@ELSIS.COM follows. ------------------------------------------------------------------ Hi, I have a problem. In short: 1 DHCP (MS WinNT) server for LAN (local subnet), one router to other LAN's, 3 3com hubs and servers are connected to 3com switch. Clients can't obtain IP configuration from DHCP server. In DHCP administrator window I can see only offered adreses (there is no computer names) for a new clients, theris no intact for old valid leases . Leases are set for 3 days, but these new leases always are expired. Clients (Win9X, WinNT) are claiming: "DHCP error. Can't obtain IP address". So, I enabled the second DHCP server (for new address poll ), it was on the same situation. IMO, It looks like something intercepts an DHCPOFFER. Till today (about 1 year) was no problem. Can You give me some suggestions? Regards Gintautas Kepalas Network Administrator ELSIS tel: +3707 310488 mob: +37089 20454 From dhcp-v4@bucknell.edu Fri Jul 30 11:14: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 LAA04629 for ; Fri, 30 Jul 1999 11:14: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 LAA13526; Fri, 30 Jul 1999 11:10:47 -0400 (EDT) Date: Fri, 30 Jul 1999 11:10:47 -0400 (EDT) Message-Id: <63D30D6E10CFD11190A90000F805FE86016F31B9@lespaul.process.com> Errors-To: droms@bucknell.edu Reply-To: Gonczi@process.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Steve Gonczi To: Multiple recipients of list Subject: RE: Help, DHCP Server on WinNT!!! 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.0.1460.8) Mime-Version: 1.0 Are the clients on the same segment where your server is, or is there a router between them? If the router sits in between, someone may have messed up your bootp relay setup. If things were working fine for a year, and not working now, you must look for something that has recently changed. If I had to troubleshoot this, I would want to see packet traffic to/from your server. sG -----Original Message----- From: dhcp-v4@bucknell.edu [mailto:dhcp-v4@bucknell.edu] Sent: Friday, July 30, 1999 10:22 AM To: Multiple recipients of list Subject: Help, DHCP Server on WinNT!!! message sent to dhcp-v4@bucknell.edu by GINTASK@ELSIS.COM follows. ------------------------------------------------------------------ Hi, I have a problem. In short: 1 DHCP (MS WinNT) server for LAN (local subnet), one router to other LAN's, 3 3com hubs and servers are connected to 3com switch. Clients can't obtain IP configuration from DHCP server. In DHCP administrator window I can see only offered adreses (there is no computer names) for a new clients, theris no intact for old valid leases . Leases are set for 3 days, but these new leases always are expired. Clients (Win9X, WinNT) are claiming: "DHCP error. Can't obtain IP address". So, I enabled the second DHCP server (for new address poll ), it was on the same situation. IMO, It looks like something intercepts an DHCPOFFER. Till today (about 1 year) was no problem. Can You give me some suggestions? Regards Gintautas Kepalas Network Administrator ELSIS tel: +3707 310488 mob: +37089 20454 From dhcp-v4@bucknell.edu Fri Jul 30 12:03: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 MAA05828 for ; Fri, 30 Jul 1999 12:03: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 LAA08537; Fri, 30 Jul 1999 11:59:23 -0400 (EDT) Date: Fri, 30 Jul 1999 11:59:23 -0400 (EDT) Message-Id: <37A1C340.6691E4DD@ansc.nar.irs.gov> Errors-To: droms@bucknell.edu Reply-To: jmorin@ansc.nar.irs.gov Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Jay Morin To: Multiple recipients of list Subject: Re: Help, DHCP Server on WinNT!!! X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.61 [en] (WinNT; I) Content-Transfer-Encoding: 7bit Check for a DHCP RELAY on the router. The discover/offer maybe getting dropped there. "by way of Ralph Droms " wrote: > message sent to dhcp-v4@bucknell.edu by GINTASK@ELSIS.COM follows. > ------------------------------------------------------------------ > Hi, > > I have a problem. In short: > > 1 DHCP (MS WinNT) server for LAN (local subnet), one router to other LAN's, > 3 3com hubs and servers are connected to 3com switch. Clients can't obtain > IP configuration from DHCP server. In DHCP administrator window I can see > only offered adreses (there is no computer names) for a new clients, theris > no intact for old valid leases . Leases are set for 3 days, but these new > leases always are expired. Clients (Win9X, WinNT) are claiming: "DHCP error. > Can't obtain IP address". So, I enabled the second DHCP server (for new > address poll ), it was on the same situation. IMO, It looks like something > intercepts an DHCPOFFER. > Till today (about 1 year) was no problem. > Can You give me some suggestions? > > Regards > Gintautas Kepalas > Network Administrator > ELSIS > tel: +3707 310488 > mob: +37089 20454 -- Jay Morin LAN Administrator Andover Service Center (978)474-5678 [Phone] (978)474-9699 [FAX] Mailto:jmorin@ansc.nar.irs.gov From dhcp-v4@bucknell.edu Fri Jul 30 12:03: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 MAA05845 for ; Fri, 30 Jul 1999 12:03: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 MAA15894; Fri, 30 Jul 1999 12:02:01 -0400 (EDT) Date: Fri, 30 Jul 1999 12:02:01 -0400 (EDT) Message-Id: <199907301529.LAA09931@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: Help, DHCP Server on WinNT!!! X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Two things. First, there is now a mailing list for asking questions like this: dhcp-interest@isc.org. This mailing list is technically for discussion of the protocol, not for asking for help with existing applications. Your question is kind of both, so I am not saying that it's inappropriate here - just letting you know about the other mailing list. As to your question, if things were working for a long time and then suddenly stopped, my first instinct would be to assume that a new DHCP server that is not configured correctly has been added to your network without your knowledge. Adding a third server didn't help you because the second, unknown server is still out there poisoning your network. This is just a guess, of course - I may be completely wrong. To find out, I would suggest that you start up a packet sniffer to look for DHCP packets, and then start a client and have it request an address. Look for two things: how does the protocol go (what packets are exchanged) and who sent them? If, for example, you see DHCPNAK packets coming from some unknown IP address, that's your rogue server. If this doesn't help you, please follow up with whatever you have learned on the dhcp-interest mailing list, and we'll try to help you solve this problem. To subscribe, send mail to dhcp-interest-request@isc.org with "subscribe" in the subject line. Best of luck! _MelloN_ From dhcp-v4@bucknell.edu Fri Jul 30 12:05: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 MAA05873 for ; Fri, 30 Jul 1999 12:05: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 MAA11579; Fri, 30 Jul 1999 12:03:47 -0400 (EDT) Date: Fri, 30 Jul 1999 12:03:47 -0400 (EDT) Message-Id: <852567BE.00562FDA.00@D51MTA10.pok.ibm.com> Errors-To: droms@bucknell.edu Reply-To: hoyoung@us.ibm.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: hoyoung@us.ibm.com To: Multiple recipients of list Subject: unknown options... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 All, I have an interesting problem here and hope someone can give some suggestions. DHCP server is running on an AIX box with bos.net.tcp.server code 4.3.2. WinNT clients gets some warning msg in the event viewer. It says: DHCP received an unknown option 45. DHCP received an unknown option5; DHCP received an unknown option 12; DHCP received an unknown option 28. Funny thing is that I don't even have option 12 configured in the server config file. Microsoft doesn't support option 45 (NBDD), but shouldn't it simply ignore it? As for option 28 and 5, I can't think why winNT doesn't like it. BTW, the warning msgs don't seem to stop clients from getting an IP. Any suggestions? would it eventually cause problems? thanks Hannah Oyoung From dhcp-v4@bucknell.edu Fri Jul 30 13:20: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 NAA07009 for ; Fri, 30 Jul 1999 13:20: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 NAA18121; Fri, 30 Jul 1999 13:16:24 -0400 (EDT) Date: Fri, 30 Jul 1999 13:16:24 -0400 (EDT) Message-Id: <21839C593E75D211BF7800805FCCD0264B08FF@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: unknown options... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain X-Mailer: Internet Mail Service (5.5.2448.0) Mime-Version: 1.0 Hannah-- Microsoft clients complain when they receive an option that they did not request or is not in a brief list of acceptable options -- look in the Microsoft Knowledge Base for article Q121005, "DHCP Options Supported by Clients" for a complete list. Only options 1, 3, 6, 15, 44, 46, 47, 51, 53, 58, and 59 are supported. The dialogue box that is displayed when other options are received is a bit annoying, but ultimately harmless, as the Microsoft clients simply ignore any options besides the ones they specifically accept. --Barr > From: hoyoung@us.ibm.com[SMTP:hoyoung@us.ibm.com] > Sent: Friday, July 30, 1999 9:03 AM > To: Multiple recipients of list > Subject: unknown options... > > DHCP server is running on an AIX box with bos.net.tcp.server code 4.3.2. > WinNT > clients gets some warning msg in the event viewer. It says: DHCP received > an > unknown option 45. DHCP received an unknown option5; DHCP received an > unknown option 12; DHCP received an unknown option 28. Funny thing is > that I don't even have option 12 configured in the server config file. > Microsoft doesn't support option 45 (NBDD), but shouldn't it simply ignore > it? As for option 28 and 5, I can't think why winNT doesn't like it. > > From dhcp-v4@bucknell.edu Fri Jul 30 17:24: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 RAA10085 for ; Fri, 30 Jul 1999 17:24: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 RAA32529; Fri, 30 Jul 1999 17:20:13 -0400 (EDT) Date: Fri, 30 Jul 1999 17:20:13 -0400 (EDT) Message-Id: <852567BE.00736D46.00@D51MTA10.pok.ibm.com> Errors-To: droms@bucknell.edu Reply-To: hoyoung@us.ibm.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: hoyoung@us.ibm.com To: Multiple recipients of list Subject: RE: unknown options... X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Barr, Thanks. This does explain why the MS clients complaint about the options. However, it doesn't explain why they even bother reporting option 12 since I don't even have option 12 configured in the server. Also, I had another DHCP server running on 4.2 code with the same options configured prior to the current server, the MS clients only complained about option 45. Since I put the new server to production, I started to see not only option 45, but 5, 12, 28...Note, nothing has changed on the MS clients. Any more suggestions? Thanks Hannah Hannah-- Microsoft clients complain when they receive an option that they did not request or is not in a brief list of acceptable options -- look in the Microsoft Knowledge Base for article Q121005, "DHCP Options Supported by Clients" for a complete list. Only options 1, 3, 6, 15, 44, 46, 47, 51, 53, 58, and 59 are supported. The dialogue box that is displayed when other options are received is a bit annoying, but ultimately harmless, as the Microsoft clients simply ignore any options besides the ones they specifically accept. --Barr > From: hoyoung@us.ibm.com[SMTP:hoyoung@us.ibm.com] > Sent: Friday, July 30, 1999 9:03 AM > To: Multiple recipients of list > Subject: unknown options... > > DHCP server is running on an AIX box with bos.net.tcp.server code 4.3.2. > WinNT > clients gets some warning msg in the event viewer. It says: DHCP received > an > unknown option 45. DHCP received an unknown option5; DHCP received an > unknown option 12; DHCP received an unknown option 28. Funny thing is > that I don't even have option 12 configured in the server config file. > Microsoft doesn't support option 45 (NBDD), but shouldn't it simply ignore > it? As for option 28 and 5, I can't think why winNT doesn't like it. > > From dhcp-v4@bucknell.edu Fri Jul 30 18:20: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 SAA10574 for ; Fri, 30 Jul 1999 18:20: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 SAA14876; Fri, 30 Jul 1999 18:13:12 -0400 (EDT) Date: Fri, 30 Jul 1999 18:13:12 -0400 (EDT) Message-Id: <37A22351.C5EE8536@austin.ibm.com> Errors-To: droms@bucknell.edu Reply-To: dbabbitt@austin.ibm.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: David Babbitt To: Multiple recipients of list Subject: Re: unknown options... 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] (X11; U; AIX 4.3) Content-Transfer-Encoding: 7bit AIX 4.3.1+ will send back the hostname that is sent to it. You can prevent this by placing "option 12 deny" in the subnet from which the client is getting its address or in the global area outside of all subnets. To quote Ted: Two things. First, there is now a mailing list for asking questions like this: dhcp-interest@isc.org. This mailing list is technically for discussion of the protocol, not for asking for help with existing applications. ... If this doesn't help you, please follow up with whatever you have learned on the dhcp-interest mailing list, and we'll try to help you solve this problem. To subscribe, send mail to dhcp-interest-request@isc.org with "subscribe" in the subject line. Thanks. Dave -- David Babbitt AIX TCP/IP Development IBM Austin