From dhcp-v4@bucknell.edu Fri Oct 1 04:11:18 1999 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10652 for ; Fri, 1 Oct 1999 04:11: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 EAA27535; Fri, 1 Oct 1999 04:10:48 -0400 (EDT) Date: Fri, 1 Oct 1999 04:10:48 -0400 (EDT) Message-Id: <5104D4DBC598D211B5FE0000F8FE7EB2E6BC01@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: I-D ACTION:draft-privat-dhc-doublephase-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 Thanks for your comments. See my answers below. > I'm a bit confused as to why we would want to make a change as drastic as > this to the clients, much more time intensive than a server change (i.e., > I prefer the proxy method much more). [Privat,J,Jerome] I also prefer the proxy option as it does not require any client changes and makes it easier to preserve the atomicity of the transaction. All the answers I got in private emails also agree with that. > I think DHCP server A proxies to DHCP server B to get the options > between DHCPDISCOVER & DHCPOFFER using LDAP or some other generic > mechanism is a better approach. While it is sometimes difficult to insert > an extra processing step between discover & offer due to time constraints, > it would not require massive client changes. [Privat,J,Jerome] In the proxy option, the draft proposes to use DHCP to do the communication between the 2 DHCP servers [in a similar way as we would use a AAA protocol to do proxying between AAA servers]. Another possibility, as you mention, would be to have server_1 do an ODBC or LDAP query to server_2. Has anyboby a strong view on which of these two options is the best? > > In section 5, also, the client is quite broken if something more than just > the IP address, netmask and default gateway are not given. You do specify > the specific partitions to be outside the scope of the document; perhaps a > warning indicating broken clients would be appropriate or a more complete > fallback set of options? What I'm getting at is some method of informing > the user that their configuration is incomplete and should not expect full > functionality. (A special DNS server with a * RR that points to a default > "your client is broken" website is a possibility, but perhaps beyond the > scope of this document.) [Privat,J,Jerome] In normal operation, server_1 will be able to retrieve information from server_2 and will therefore return a complete configuration to the client. But you are right there may some conditions in which this is not possible. In this case, server_1 could in some way notify the client that its configuration is incomplete. Or server_1 could return a local set of options. This would depend on agreement between the two administrations. Thanks, Jerome > Just some ideas that may help us all to better understand and use this > effectively. > > -Nathan Lane > Senior Network Engineer > Wal-Mart Stores, Inc. > (501) 277-5786 > > > -----Original Message----- > > From: Thomas Narten [SMTP:narten@raleigh.ibm.com] > > Sent: Wednesday, September 29, 1999 9:41 AM > > To: Multiple recipients of list > > Subject: FWD: I-D ACTION:draft-privat-dhc-doublephase-01.txt > > > > Comments? Seems like a protocol change as much as a new option. The > > option specifies that the client should also send additional DHCP > > packets to a second server. > > > > ------- Forwarded Message > > > > From: Internet-Drafts@ietf.org > > To: IETF-Announce: ; > > Date: Wed, 29 Sep 1999 06:56:14 -0400 > > Subject: I-D ACTION:draft-privat-dhc-doublephase-01.txt > > Reply-to: Internet-Drafts@ietf.org > > > > --NextPart > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Double Phase DHCP Configuration > > Author(s) : J. Privat > > Filename : draft-privat-dhc-doublephase-01.txt > > Pages : 4 > > Date : 28-Sep-99 > > > > From dhcp-v6@bucknell.edu Mon Oct 4 18:38:05 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09749 for ; Mon, 4 Oct 1999 18:38:04 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id SAA12645; Mon, 4 Oct 1999 18:32:27 -0400 (EDT) Date: Mon, 4 Oct 1999 18:32:27 -0400 (EDT) Message-Id: <21839C593E75D211BF7800805FCCD026EAADA5@msgsrv03.srv.PacBell.COM> Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v6@bucknell.edu Sender: dhcp-v6@bucknell.edu Precedence: bulk From: "HIBBS, BARR (PB)" To: Multiple recipients of list Subject: RE: WG meetings in DC X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion list for DHCPv6 internet protocol. Content-Type: text/plain X-Mailer: Internet Mail Service (5.5.2448.0) Mime-Version: 1.0 Ralph-- I'd like 5 minutes or so to briefly discuss the latest changes to the server MIB and to request that we either advance the draft or delete it, and 10-15 minutes to discuss the soon-to-be-submitted draft on client behavior. I should have the MIB draft updated and to you this week, the client behavior draft next week. --Barr From dhcp-v4@bucknell.edu Tue Oct 5 11:37: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 LAA05591 for ; Tue, 5 Oct 1999 11:37: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 LAA14458; Tue, 5 Oct 1999 11:35:26 -0400 (EDT) Date: Tue, 5 Oct 1999 11:35:26 -0400 (EDT) Message-Id: <4.2.0.58.19991005103609.01494ae0@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: failover conference call 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.2.0.58 Just in case there is anyone who missed the first two announcements of several conference calls to discuss the current failover draft, the first of these calls is today at 12pm EDT. Presently over 15 people are part of these calls, having responded to one of my two invitations to participate. If for some reason you missed those announcements and would like to be a part of today's call, please contact me and I'll send you the necessary connection information (and possibly increase the number of ports on the conference call). There will be another call on Thursday of this week, also at 12pm EDT, and likely another after that (not yet firmly scheduled.) Cheers -- Kim From dhcp-v4@bucknell.edu Tue Oct 5 17:13: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 RAA12962 for ; Tue, 5 Oct 1999 17:13:20 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA32629; Tue, 5 Oct 1999 17:12:11 -0400 (EDT) Date: Tue, 5 Oct 1999 17:12:11 -0400 (EDT) Message-Id: <4.2.0.58.19991005163218.0156c2d0@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: Minutes of today's Failover conference call 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.2.0.58 Today we held the first of two (or possibly three) conference calls on the current failover draft. The attendees list is below, as are the minutes of the meeting. The next call is 12pm, Thurs Oct 7, 1999. If you are interested in participating, please let me know and I'll send you contact information. The agenda for that call is: conflict resolution, initialization, and state transitions. Thanks to all of you who participated in today's meeting, it was unusually productive! ------------------------------------------- Minutes of 10/5/99 Failover draft conference call/meeting: There were three primary agenda items covered in today's failover conference call, Implementation using TCP, Loadbalancing, and Security. Below you will find a brief summary of the minutes of this meeting. Implementation using TCP ------------------------ Kim Kinnear started off with a bit of history about where the protocol had been in the past, with the first definition using UDP, but that at the meeting in Feb. 1999, there was a move to implement it using TCP. He then described the general approach to the implementation (available in the current failover draft, and also discussed in a separate document already sent to this list on July 7, 1999, and available from Kim (kkinnear@cisco.com)) The long and the short of the discussion was that the current approach, using a single TCP connection for both failover functions (i.e., bulk data transfer and to determine partner server connectivity) was essentially ratified. Several people expressed their belief that this was a good approach, and there were no dissenting opinions heard. There was some discussion that restarting a server using the TCP listen port might take something like 2 minutes before it could successfully open the TCP port again, and that the draft should indicate that if a server couldn't open the listen port immediately it should keep trying. Bernie Volz brought up a an issue with the times, and was concerned that the time drift between two servers could cause a problem if the connection was up for a very long time, since the time was only sent during connection setup. It was pointed out that the time is also sent on contact messages, but that isn't a help because on a busy server a contact message may well never be sent. We realized that there are two problems here, small scale time drift, and large scale time resets. Both are issues. In order to satisfy the need to track both, we decided (after considerable discussion) to send the time in every packet and to add a fixed 4 byte field with the time to the packet header. Then a receiving server can determine small scale time drift from large scale time resets, and can do something reasonable in each case. Load Balancing -------------- Kim introduced load balancing, and Steve Gonczi discussed the particular algorithm. Ultimately Rob Stevens said that load balancing could be used between separate servers, not just between failover pairs. After considerable discussion of the ramifications of multiple non-failover servers doing load balancing, and multiple pairs of failover servers doing load balancing between the pairs and among the primary and secondary within a pair, we decided that it made sense to remove the load balancing features from the failover draft and make it a separate draft. The failover draft will discuss how failover servers use the failover protocol to configure the load balancing between primary and secondary servers, but the details of the algorithm and its use in non-failover contexts (including BOOTP relay implementations) will be discussed in this separate draft. Steve Gonczi offered to spearhead the new draft, with Ted Lemon and Rob Stevens reviewing it and added content. Kim asked to be kept in the loop in order to properly update the failover draft. Steve said that he'd have something by the next IETF deadline (or earlier, since this will be an first draft, so to speak). Security -------- Bernie discussed the TLS capabilities that he added to the draft in the -04 version. Ted suggested that he would like to have a way to do just a simple digest using a simple shared secret, and Mark Stapp pointed out that was already in the draft. After discussions with Thomas Narten about the how to approach the security issues, and Thomas' suggestion that we look at the SASL approach to negotiate security issues, we agreed on the following plan: 1. The draft would require implementation of a message digest which will use some shared secret approach for the cipher (exact details TBD by Bernie, looking at the DHCP authentication draft for guidelines). No user of the protocol would be required to use this approach, but every server implementation would be required to have it. This will (it is hoped) pass muster since there is only a pair of server on which this shared secret will have to be configured. 2. Ted said that he'd investigate the SASL security negotiation drafts, and see how we'd adapt them to the failover draft. The approach would be that we might well require SASL to negotiate the message digest and cipher. If we use SASL, we would certainly use it to negotiate the TLS kind of encryption security which most agreed wasn't all that necessary, but also agreed that there would certainly be people that would want it. ------------------------ All in all, it was a very productive meeting -- and it even ended early! Thanks to all of the participants: Burcak Beser 3Com PDT Burcak_Beser@mw.3com.com> Ann Demirtjis Microsoft PDT annd@Exchange.Microsoft.com Ralph Droms Bucknell U. EDT droms@bucknell.com David Erdmann Nortel Networks EDT derdmann@nortelnetworks.com Steve Gonczi Process Software EDT gonzci@process.com Richard Jones Checkpoint Software PDT richardj@metaip.checkpoint.com Kim Kinnear Cisco Systems EDT kkinnear@cisco.com Diana Lane Wal-Mart Stores CDT dblane@wal-mart.com Ted Lemon Internet Engines EDT mellon@isc.org Thomas Narten IBM/IETF area dir EDT narten@raleigh.ibm.com Greg Rabil Lucent Technologies EDT agrabil@quadritek.com Mark Stapp Cisco Systems EDT mjs@cisco.com Rob Stevens Join Systems PDT robs@join.com Bernie Volz Process Software EDT volz@process.com From dhcp-v4@bucknell.edu Tue Oct 5 17:49: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 RAA13220 for ; Tue, 5 Oct 1999 17:49: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 RAA09068; Tue, 5 Oct 1999 17:48:45 -0400 (EDT) Date: Tue, 5 Oct 1999 17:48:45 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: derdmann@nortelnetworks.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "David Erdmann" To: Multiple recipients of list Subject: ddns and failover protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Hi, I have a concern that relates to both the DHCP-FAILOVER (draft-ietf-dhc-failover-04.txt) draft and the DHCP-DNS (draft-ietf-dhc-dhcp-dns-10.txt) draft. Consider that you have a DHCP server whose objective is to make sure that a DNS server has all of the FQDN->IPaddr information about clients that it has given addresses to. This is done through the DDNS defined in DHCP-DNS. Assume that the DNS server is down for the moment. The DHCP server should be trying to update the DNS server indefinitely. If the DHCP server restarts for some reason, I would expect it to continue trying to update the DNS server with the information that has not yet been updated to the DNS server. Has anyone considered the implications to the DHCP-FAILOVER draft? From a network reliability point of view I could envision the Primary passing whether it has updated the DNS server to the backup, and the backup trying to do any incomplete DDNS updates. Should the FAILOVER draft specifically be addressing issues like this, or should it be the DHCP-DNS draft that should address this? -Dave ---------------------------------- Dave Erdmann Nortel Networks, NetID Group mailto:derdmann@nortelnetworks.com From dhcp-v4@bucknell.edu Tue Oct 5 20:35: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 UAA14396 for ; Tue, 5 Oct 1999 20:35: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 UAA13202; Tue, 5 Oct 1999 20:34:53 -0400 (EDT) Date: Tue, 5 Oct 1999 20:34:53 -0400 (EDT) Message-Id: <4.2.0.58.19991005180138.00a73920@mail.join.com> Errors-To: droms@bucknell.edu Reply-To: robs@join.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Rob Stevens To: Multiple recipients of list Subject: Re: ddns and 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"; format=flowed Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 At 05:48 PM 10/5/99 -0400, David Erdmann wrote: >Hi, > >I have a concern that relates to both the DHCP-FAILOVER >(draft-ietf-dhc-failover-04.txt) draft and the DHCP-DNS >(draft-ietf-dhc-dhcp-dns-10.txt) draft. > >Consider that you have a DHCP server whose objective is to make sure >that a DNS server has all of the FQDN->IPaddr information about clients >that it has given addresses to. This is done through the DDNS defined >in DHCP-DNS. > >Assume that the DNS server is down for the moment. The DHCP server >should be trying to update the DNS server indefinitely. If the DHCP server >restarts for some reason, I would expect it to continue trying to update the >DNS server with the information that has not yet been updated to the DNS >server. > >Has anyone considered the implications to the DHCP-FAILOVER draft? From a >network reliability point of view I could envision the Primary passing >whether >it has updated the DNS server to the backup, and the backup trying to do >any incomplete DDNS updates. > >Should the FAILOVER draft specifically be addressing issues like this, >or should it be the DHCP-DNS draft that should address this? David I don't have any answer, but I too was wondering about this (or something very like it anyway) and I had it on my short list of things for the ad-hoc failover discussions that we are having. It didn't seem to fall into any of the major topics, and I was going to suggest a "Miscellany" to round out the discussion on Thursday. (perhaps I should have suggested it today - it's the first time I can remember that one of these groups finished early, and without my feeling completely effete). Kim, could you add this to Thursday's agenda: a miscellaneous topics roundup? Rob From dhcp-v4@bucknell.edu Tue Oct 5 23:29:38 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17462 for ; Tue, 5 Oct 1999 23:29: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 XAA13455; Tue, 5 Oct 1999 23:28:46 -0400 (EDT) Date: Tue, 5 Oct 1999 23:28:46 -0400 (EDT) Message-Id: <009DF310.782BE50F.16@process.com> Errors-To: droms@bucknell.edu Reply-To: volz@process.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Bernie Volz To: Multiple recipients of list Subject: RE: ddns and failover protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 David: This does sound like a useful issue to discuss. And, since Mark Stapp is authoring the document and partipating, we can resolve where to document this and what to do. I believe, but I could be corrected, that binding updates should be done as DDNS occurs to make sure that both servers are aware of the state of the DDNS requests. See section 6.2.7 and 7.1.1 of the 04 draft. Clearer language around exactly what each partner should do with DDNS and updating the FQDN information seems required. As Rob suggested, this is a good topic for either the end of the 2nd (if time) or 3rd conference call. - Bernie Volz From: "David Erdmann" Subject: ddns and failover protocol Hi, I have a concern that relates to both the DHCP-FAILOVER (draft-ietf-dhc-failover-04.txt) draft and the DHCP-DNS (draft-ietf-dhc-dhcp-dns-10.txt) draft. Consider that you have a DHCP server whose objective is to make sure that a DNS server has all of the FQDN->IPaddr information about clients that it has given addresses to. This is done through the DDNS defined in DHCP-DNS. Assume that the DNS server is down for the moment. The DHCP server should be trying to update the DNS server indefinitely. If the DHCP server restarts for some reason, I would expect it to continue trying to update the DNS server with the information that has not yet been updated to the DNS server. Has anyone considered the implications to the DHCP-FAILOVER draft? From a network reliability point of view I could envision the Primary passing whether it has updated the DNS server to the backup, and the backup trying to do any incomplete DDNS updates. Should the FAILOVER draft specifically be addressing issues like this, or should it be the DHCP-DNS draft that should address this? -Dave ---------------------------------- Dave Erdmann Nortel Networks, NetID Group mailto:derdmann@nortelnetworks.com From dhcp-v4@bucknell.edu Wed Oct 6 10:01: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 KAA08105 for ; Wed, 6 Oct 1999 10:01: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 JAA05940; Wed, 6 Oct 1999 09:58:42 -0400 (EDT) Date: Wed, 6 Oct 1999 09:58:42 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: derdmann@nortelnetworks.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "David Erdmann" To: Multiple recipients of list Subject: RE: ddns and failover protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Hi Diana, Thanks for commenting on my posting. :) I have commented inline: > > Has anyone considered the implications to the DHCP-FAILOVER > draft? From a > > network reliability point of view I could envision the Primary passing > > whether > > it has updated the DNS server to the backup, and the backup trying to do > > any incomplete DDNS updates. > > > > Should the FAILOVER draft specifically be addressing issues like this, > > or should it be the DHCP-DNS draft that should address this? > > > > -Dave > While it is important for the DHCP server's dynamic updates to be > processed, > it is possible for those updates to stack up to the point where > they become > more of a problem than if they had simply been dropped in the first place. > Consider the case of a fairly lengthy outage with many clients hitting the > backup server (RENEWs, a storm of DISCOVERs, etc.) Add to that volume of > requests to be processed the backlog of DNS updates and it may be that the > backup becomes so busy updating DNS that it, too, falls behind on serving > clients. At some point, a certain percentage of the incomplete > DNS updates > may become outdated as the IP addresses involved are assigned to > new clients. There should be some exponential back-off for trying DDNS updates. If people have DDNS turned on, then I can only assume that they are interested in the DNS server getting updated. I don't think that it is safe to assume that we can just drop DNS updates. I do agree however that we should consider the performance implications. When you assign an address to a new client you should be cancelling the previous DNS update, and trying to update the new address. > I think the idea of preserving some of the DNS updates yet to be > performed is > good, but perhaps they should be dropped either after a certain > period of time > (at what point should they become "stale?") or when server load reaches a > certain percent of "maximum capacity." If DHCP is the only way of updating DNS servers I would be wary of expiring DNS updates (of course after the lease expires we should stop). As for server load reaching a certain maximum, I agree that it would be a good idea for a server to not do too many simultaneous updates, and queue the updates...I don't think that we should be dropping the updates altogether. > IP addresses for existing clients > will tend to remain constant, so DNS records pertaining to those > clients will > be unnecessary. Perhaps the backup should only update records for those > clients that start out at DISCOVER, not for those RENEWing > existing leases. Perhaps a refinement of this idea would be to only do a DNS update if the DHCP server is handing out a new address. Thus if we already know that this client has a specific IP and we hand out the same IP again to the same client, we do not have to update DNS. > > Diana Lane > Wal-Mart Stores > dblane@wal-mart.com -Dave ---------------------------------- Dave Erdmann Nortel Networks, NetID Group mailto:derdmann@nortelnetworks.com From dhcp-v4@bucknell.edu Wed Oct 6 10:34: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 KAA09451 for ; Wed, 6 Oct 1999 10:34: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 KAA13592; Wed, 6 Oct 1999 10:34:03 -0400 (EDT) Date: Wed, 6 Oct 1999 10:34:03 -0400 (EDT) Message-Id: <2D97764EC014D311BFD5006094A3E712027A962E@honts326.homeoffice.wal-mart.com> Errors-To: droms@bucknell.edu Reply-To: dblane@wal-mart.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Diana Lane To: Multiple recipients of list Subject: FW: Re: ddns and failover protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; X-Mailer: Internet Mail Service (5.5.2650.21) Mime-Version: 1.0 I sent this out last night but I don't believe it made it to the list. Please forgive me if this is a duplicate. Thanks! Diana Lane IP Research & Development Wal-Mart Stores, Inc. 501/277-3177 Be gentle to all, and stern with yourself. - Teresa of Avila ------- Forwarded Message Return-Path: diana@daneel.textiles.org Delivery-Date: Tue Oct 5 17:35:49 1999 >From diana Tue Oct 5 17:35:49 1999 Received: from daneel.textiles.org (IDENT:diana@localhost [127.0.0.1]) by daneel.textiles.org (8.9.1/8.9.1) with ESMTP id RAA18622; Tue, 5 Oct 1999 17:35:43 -0500 Message-Id: <199910052235.RAA18622@daneel.textiles.org > To: derdmann@nortelnetworks.com cc: Multiple recipients of list >, diana Subject: Re: ddns and failover protocol In-Reply-To: Message from "David Erdmann" > of "Tue, 05 Oct 1999 17:48:45 EDT." > Date: Tue, 05 Oct 1999 17:35:36 -0500 From: Diana Lane > > Hi, > > I have a concern that relates to both the DHCP-FAILOVER > (draft-ietf-dhc-failover-04.txt) draft and the DHCP-DNS > (draft-ietf-dhc-dhcp-dns-10.txt) draft. > > Consider that you have a DHCP server whose objective is to make sure > that a DNS server has all of the FQDN->IPaddr information about clients > that it has given addresses to. This is done through the DDNS defined > in DHCP-DNS. > > Assume that the DNS server is down for the moment. The DHCP server > should be trying to update the DNS server indefinitely. If the DHCP server > restarts for some reason, I would expect it to continue trying to update the > DNS server with the information that has not yet been updated to the DNS > server. > > Has anyone considered the implications to the DHCP-FAILOVER draft? From a > network reliability point of view I could envision the Primary passing > whether > it has updated the DNS server to the backup, and the backup trying to do > any incomplete DDNS updates. > > Should the FAILOVER draft specifically be addressing issues like this, > or should it be the DHCP-DNS draft that should address this? > > -Dave > ---------------------------------- > Dave Erdmann > Nortel Networks, NetID Group > mailto:derdmann@nortelnetworks.com While it is important for the DHCP server's dynamic updates to be processed, it is possible for those updates to stack up to the point where they become more of a problem than if they had simply been dropped in the first place. Consider the case of a fairly lengthy outage with many clients hitting the backup server (RENEWs, a storm of DISCOVERs, etc.) Add to that volume of requests to be processed the backlog of DNS updates and it may be that the backup becomes so busy updating DNS that it, too, falls behind on serving clients. At some point, a certain percentage of the incomplete DNS updates may become outdated as the IP addresses involved are assigned to new clients. I think the idea of preserving some of the DNS updates yet to be performed is good, but perhaps they should be dropped either after a certain period of time (at what point should they become "stale?") or when server load reaches a certain percent of "maximum capacity." IP addresses for existing clients wi! ll tend to remain constant, so DNS records pertaining to those clients will be unnecessary. Perhaps the backup should only update records for those clients that start out at DISCOVER, not for those RENEWing existing leases. I also felt that the conference call today was productive. It was certainly different from the majority of large conference calls I have encountered! Diana Lane Wal-Mart Stores dblane@wal-mart.com ------- End of Forwarded Message From dhcp-v4@bucknell.edu Wed Oct 6 10:36: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 KAA09538 for ; Wed, 6 Oct 1999 10:36:21 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA03218; Wed, 6 Oct 1999 10:35:55 -0400 (EDT) Date: Wed, 6 Oct 1999 10:35:55 -0400 (EDT) Message-Id: <199910061404.KAA08870@grosse.manhattan.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: ddns and failover protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 A DNS update that doesn't actually cause a change doesn't increment the zone serial number or cause a write to disk, so it's relatively cheap. It still may be worthwhile to try to optimize out unnecessary updates, but maybe it's not as crucial as one might think. _MelloN_ From dhcp-v4@bucknell.edu Wed Oct 6 12:23:48 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13046 for ; Wed, 6 Oct 1999 12:23: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 MAA31617; Wed, 6 Oct 1999 12:22:18 -0400 (EDT) Date: Wed, 6 Oct 1999 12:22:18 -0400 (EDT) Message-Id: <4.2.0.58.19991006115127.014a0490@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: ddns and 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.2.0.58 David, I agree with Bernie, we do need to discuss this. Let's see if we can work it into Thursday's talk, else we'll have to discuss it in the 3rd conference call. My approach in the draft was to try to pass this information in the client-fqdn option between the two server, which would send both the name and the DNS update status between the two systems, but I think I wasn't too clear about this, as with many things. However, there may be a better way to handle DNS naming data transmission between servers. One thing that I feel strongly about is that either server should be able to update DNS either as part of the initial lease, or if the name changes later or the client releases the name. Cheers -- Kim At 11:29 PM 10/5/99 -0400, Bernie Volz wrote: >David: > >This does sound like a useful issue to discuss. And, since Mark Stapp >is authoring the document and partipating, we can resolve where to >document this and what to do. > >I believe, but I could be corrected, that binding updates should be >done as DDNS occurs to make sure that both servers are aware of the >state of the DDNS requests. See section 6.2.7 and 7.1.1 of the 04 >draft. I agree. >Clearer language around exactly what each partner should do with DDNS >and updating the FQDN information seems required. > >As Rob suggested, this is a good topic for either the end of the 2nd >(if time) or 3rd conference call. > >- Bernie Volz > >From: "David Erdmann" >Subject: ddns and failover protocol > >Hi, > >I have a concern that relates to both the DHCP-FAILOVER >(draft-ietf-dhc-failover-04.txt) draft and the DHCP-DNS >(draft-ietf-dhc-dhcp-dns-10.txt) draft. > >Consider that you have a DHCP server whose objective is to make sure >that a DNS server has all of the FQDN->IPaddr information about clients >that it has given addresses to. This is done through the DDNS defined >in DHCP-DNS. > >Assume that the DNS server is down for the moment. The DHCP server >should be trying to update the DNS server indefinitely. If the DHCP server >restarts for some reason, I would expect it to continue trying to update the >DNS server with the information that has not yet been updated to the DNS >server. > >Has anyone considered the implications to the DHCP-FAILOVER draft? From a >network reliability point of view I could envision the Primary passing >whether >it has updated the DNS server to the backup, and the backup trying to do >any incomplete DDNS updates. > >Should the FAILOVER draft specifically be addressing issues like this, >or should it be the DHCP-DNS draft that should address this? > >-Dave >---------------------------------- >Dave Erdmann >Nortel Networks, NetID Group >mailto:derdmann@nortelnetworks.com From dhcp-v4@bucknell.edu Wed Oct 6 15:53: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 PAA18430 for ; Wed, 6 Oct 1999 15:53: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 PAA31818; Wed, 6 Oct 1999 15:50:52 -0400 (EDT) Date: Wed, 6 Oct 1999 15:50:52 -0400 (EDT) Message-Id: <4.2.0.58.19991006110954.00c2d540@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: mjs@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Mark Stapp To: Multiple recipients of list Subject: Re: ddns and 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"; format=flowed Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 David, Yes, I agree that it's worth addressing ddns at some point in our discussions. Thanks for bringing this up, David: it sounds as if several of us have had this on our minds. Can I propose a couple of guidelines as a starting point? 1) The server which *grants* a new lease initiates a dns update. This server obeys its administrator on matters such as resolving conflicts, and determining whether to allow a client to perform its own A RR update. The leasing server indicates to its partner that it has or will initiate an update, and which records it will attempt to add, as part of the BNDUPD. When the dns update is completed, the leasing server indicates to its partner whether the update was successful in another BNDUPD. It also conveys the domain name that it used: this might be different from the domain-name that it originally attempted to use, if the server was configured to resolve domain-name conflicts by modifying the hostname. 2) The server which makes a lease *available* initiates a dns update to remove any dns records which may have been added on the client's behalf. I believe that the 'client-fqdn' option (6.2.7 of the -04 draft) can convey the info. that's necessary; I can propose a set of flags values to indicate the types of records involved and the status of the update. These two lease state transitions have special properties which make them the natural points at which to perform dns updates. This is a conservative list: there are some cases where one server may have initiated but not completed some dns update, and where the other server could 'finish' the update. I'm reluctant to build this case into the failover protocol draft, though, given the lack of field experience that we (collectively) have. -- Mark At 05:48 PM 10/5/1999 -0400, David Erdmann wrote: >Hi, > >I have a concern that relates to both the DHCP-FAILOVER >(draft-ietf-dhc-failover-04.txt) draft and the DHCP-DNS >(draft-ietf-dhc-dhcp-dns-10.txt) draft. > >Consider that you have a DHCP server whose objective is to make sure >that a DNS server has all of the FQDN->IPaddr information about clients >that it has given addresses to. This is done through the DDNS defined >in DHCP-DNS. > >Assume that the DNS server is down for the moment. The DHCP server >should be trying to update the DNS server indefinitely. If the DHCP server >restarts for some reason, I would expect it to continue trying to update the >DNS server with the information that has not yet been updated to the DNS >server. > >Has anyone considered the implications to the DHCP-FAILOVER draft? From a >network reliability point of view I could envision the Primary passing >whether >it has updated the DNS server to the backup, and the backup trying to do >any incomplete DDNS updates. > >Should the FAILOVER draft specifically be addressing issues like this, >or should it be the DHCP-DNS draft that should address this? > >-Dave >---------------------------------- >Dave Erdmann >Nortel Networks, NetID Group >mailto:derdmann@nortelnetworks.com From dhcp-v4@bucknell.edu Wed Oct 6 19:58: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 TAA22639 for ; Wed, 6 Oct 1999 19:58: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 TAA10684; Wed, 6 Oct 1999 19:57:31 -0400 (EDT) Date: Wed, 6 Oct 1999 19:57:31 -0400 (EDT) Message-Id: <37FBDF10.C549F6F9@metaip.checkpoint.com> Errors-To: droms@bucknell.edu Reply-To: RichardJ@metaip.checkpoint.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Richard Jones To: Multiple recipients of list Subject: RE: I-D ACTION:draft-privat-dhc-doublephase-01.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.6 [en] (WinNT; U) Content-Transfer-Encoding: 7bit >Date: Fri, 1 Oct 1999 08:59:00 +0100 >From: jerome.privat@bt.com >To: ndlane@wal-mart.com, dhcp-v4@bucknell.edu Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB2E6BC01@mbtlipnt02.btlabs.bt.co.uk> > > I also prefer the proxy option as it does not require any client >changes and makes it easier to preserve > the atomicity of the transaction. All the answers I got in private >emails also agree with that. Count me as another vote for not requiring client behavior changes whenever possible (except where they already violate the protocol!). >> I think DHCP server A proxies to DHCP server B to get the options >> between DHCPDISCOVER & DHCPOFFER using LDAP or some other generic >> mechanism is a better approach. While it is sometimes difficult to insert >> an extra processing step between discover & offer due to time constraints, >> it would not require massive client changes. The draft has the first server sending a DHCPINFORM message to the second one. Not a problem, except that the second server is expected to use the subnet that the request came in on (or the giaddr field in the packet) to determine the set of configuration parameters that should be returned. In this case, the first server would have to pretend to be a relay agent and create a request packet that will be interpreted properly. Doable, certainly, but it seems like on a heavily used network it could mean a noticeable amount of overhead. The 'user-class' option might take care of this when it gets more solid, but there could still be some troublesome ambiguity concerning the origin of the request. > [Privat,J,Jerome] > In the proxy option, the draft proposes to use DHCP to do the >communication between the 2 DHCP servers > [in a similar way as we would use a AAA protocol to do proxying >between AAA servers]. Another possibility, > as you mention, would be to have server_1 do an ODBC or LDAP query >to server_2. Has anyboby a strong view on which > of these two options is the best? I think a protocol should be restricted to defining the behavior of service providers and consumers, and keep implementation requirements to a minimum (or at least at the 'suggestion' level). In this draft, that means doing a DHCPINFORM is a good way to go, because there's no specification of how the servers handle their own information - in fact, the two could each do it differently with no conflict. In the example in section 6, it appears that server 1 needs to be configured with at least enough knowledge spanning service providers that it can decide from a user class which 'server 2' to get more configuration info from. This means that there is by definition some serious cooperation between the admins of the various servers; why not centralize all of the configuration data? >> >> In section 5, also, the client is quite broken if something more than just >> the IP address, netmask and default gateway are not given. You do specify >> the specific partitions to be outside the scope of the document; perhaps a >> warning indicating broken clients would be appropriate or a more complete >> fallback set of options? What I'm getting at is some method of informing >> the user that their configuration is incomplete and should not expect full >> functionality. (A special DNS server with a * RR that points to a default >> "your client is broken" website is a possibility, but perhaps beyond the >> scope of this document.) > [Privat,J,Jerome] In normal operation, server_1 will be able to >retrieve information from server_2 and will therefore return > a complete configuration to the client. But you are right there may >some conditions in which this is not possible. In this > case, server_1 could in some way notify the client that its >configuration is incomplete. Or server_1 could return a local > set of options. This would depend on agreement between the two >administrations. > > Thanks, > Jerome RFC 2131 already talks about the problem of incomplete parameters coming back to a client - it has always been a potential problem, if due to nothing more than mis- or incomplete server configuration. It seems to me that all of the functionality that this draft tries to specify can be implemented within the current reach of the protocol - are any changes or additions really necessary? Regards, Richard From dhcp-v4@bucknell.edu Wed Oct 6 21:49: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 VAA24307 for ; Wed, 6 Oct 1999 21:49:00 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id VAA20666; Wed, 6 Oct 1999 21:48:11 -0400 (EDT) Date: Wed, 6 Oct 1999 21:48:11 -0400 (EDT) Message-Id: <37FBF7D1.C3F6557A@ire-ma.com> Errors-To: droms@bucknell.edu Reply-To: bkavsan@ire-ma.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Bronislav Kavsan To: Multiple recipients of list Subject: Need help X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.61 [en] (WinNT; I) Content-Transfer-Encoding: 7bit I would appreciate any help on information for DHCP API for Windows NT/95. Here is my problem: - My Windows-based software receives IP Addresses of DNS and WINS servers using "out-of-DHCP-bound" so-called mode-config extension of IKE (Internet Key Exchange) protocol. - I need to communcate these IP Addresses to the DHCP Client on my local machine, so these IP Addresses of Name Servers will be used for the duration of the secure session with the gateway, which supplied me with these addresses. I need information describing API to the DHCP Client on Windows - there are lots of functions listed in dhcpsapi.dll, but I couldn't find any documentation describing their use. Appreciate your help! Slava Kavsan From dhcp-v4@bucknell.edu Thu Oct 7 07:32: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 HAA10904 for ; Thu, 7 Oct 1999 07:32:20 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id HAA30106; Thu, 7 Oct 1999 07:31:12 -0400 (EDT) Date: Thu, 7 Oct 1999 07:31:12 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: Re: ddns and 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 message sent to dhcp-v4@bucknell.edu by DIANA@DANEEL.TEXTILES.ORG follows. -------------------------------------------------------------------------- > Hi, > > I have a concern that relates to both the DHCP-FAILOVER > (draft-ietf-dhc-failover-04.txt) draft and the DHCP-DNS > (draft-ietf-dhc-dhcp-dns-10.txt) draft. > > Consider that you have a DHCP server whose objective is to make sure > that a DNS server has all of the FQDN->IPaddr information about clients > that it has given addresses to. This is done through the DDNS defined > in DHCP-DNS. > > Assume that the DNS server is down for the moment. The DHCP server > should be trying to update the DNS server indefinitely. If the DHCP server > restarts for some reason, I would expect it to continue trying to update the > DNS server with the information that has not yet been updated to the DNS > server. > > Has anyone considered the implications to the DHCP-FAILOVER draft? From a > network reliability point of view I could envision the Primary passing > whether > it has updated the DNS server to the backup, and the backup trying to do > any incomplete DDNS updates. > > Should the FAILOVER draft specifically be addressing issues like this, > or should it be the DHCP-DNS draft that should address this? > > -Dave > ---------------------------------- > Dave Erdmann > Nortel Networks, NetID Group > mailto:derdmann@nortelnetworks.com While it is important for the DHCP server's dynamic updates to be processed, it is possible for those updates to stack up to the point where they become more of a problem than if they had simply been dropped in the first place. Consider the case of a fairly lengthy outage with many clients hitting the backup server (RENEWs, a storm of DISCOVERs, etc.) Add to that volume of requests to be processed the backlog of DNS updates and it may be that the backup becomes so busy updating DNS that it, too, falls behind on serving clients. At some point, a certain percentage of the incomplete DNS updates may become outdated as the IP addresses involved are assigned to new clients. I think the idea of preserving some of the DNS updates yet to be performed is good, but perhaps they should be dropped either after a certain period of time (at what point should they become "stale?") or when server load reaches a certain percent of "maximum capacity." IP addresses for existing clients will tend to remain constant, so DNS records pertaining to those clients will be unnecessary. Perhaps the backup should only update records for those clients that start out at DISCOVER, not for those RENEWing existing leases. I also felt that the conference call today was productive. It was certainly different from the majority of large conference calls I have encountered! Diana Lane Wal-Mart Stores dblane@wal-mart.com From dhcp-v4@bucknell.edu Thu Oct 7 08:14: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 IAA13004 for ; Thu, 7 Oct 1999 08:14: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 HAA31196; Thu, 7 Oct 1999 07:22:03 -0400 (EDT) Date: Thu, 7 Oct 1999 07:22:03 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: DHCP and Internet Access 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 JHERBERT@WILCO-INT.COM follows. ----------------------------------------------------------------------- Hi - I am currently setting up a DHCP server for what will be around 500 clients. Circa 100 of which are considered "trusted clients" and have been granted Internet Access via their IP address thru the firewall. What I need to know is this - Is it possible to configure a Solstice Firewall to grant access to the Internet via recognising a trusted machine name, or does it need to operate via the IP address? If we cannot change the firewall, is there anyway we can reserve a bank of IPs on the DHCP server to allocate to certain machine names? Thanks James Herbert Internal Systems Wilco International Ltd ---------------------------------------------------------------------------- ---- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the materialfrom any computer. ---------------------------------------------------------------------------- ---- From dhcp-v4@bucknell.edu Thu Oct 7 08:22:57 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13363 for ; Thu, 7 Oct 1999 08:22: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 HAA09335; Thu, 7 Oct 1999 07:27:45 -0400 (EDT) Date: Thu, 7 Oct 1999 07:27:45 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: RE: I-D ACTION:draft-privat-dhc-doublephase-01.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 message sent to dhcp-v4@bucknell.edu by RICHARDJ@METAIP.CHECKPOINT.COM follows. ---------------------------------------------------------------------------- --- >Date: Fri, 1 Oct 1999 08:59:00 +0100 >From: jerome.privat@bt.com >To: ndlane@wal-mart.com, dhcp-v4@bucknell.edu Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB2E6BC01@mbtlipnt02.btlabs.bt.co.uk> > > I also prefer the proxy option as it does not require any client >changes and makes it easier to preserve > the atomicity of the transaction. All the answers I got in private >emails also agree with that. Count me as another vote for not requiring client behavior changes whenever possible (except where they already violate the protocol!). >> I think DHCP server A proxies to DHCP server B to get the options >> between DHCPDISCOVER & DHCPOFFER using LDAP or some other generic >> mechanism is a better approach. While it is sometimes difficult to insert >> an extra processing step between discover & offer due to time constraints, >> it would not require massive client changes. The draft has the first server sending a DHCPINFORM message to the second one. Not a problem, except that the second server is expected to use the subnet that the request came in on (or the giaddr field in the packet) to determine the set of configuration parameters that should be returned. In this case, the first server would have to pretend to be a relay agent and create a request packet that will be interpreted properly. Doable, certainly, but it seems like on a heavily used network it could mean a noticeable amount of overhead. > [Privat,J,Jerome] > In the proxy option, the draft proposes to use DHCP to do the >communication between the 2 DHCP servers > [in a similar way as we would use a AAA protocol to do proxying >between AAA servers]. Another possibility, > as you mention, would be to have server_1 do an ODBC or LDAP query >to server_2. Has anyboby a strong view on which > of these two options is the best? I think a protocol should be restricted to defining the behavior of service providers and consumers, and keep implementation requirements to a minimum (or at least at the 'suggestion' level). In this draft, that means doing a DHCPINFORM is a good way to go, because there's no specification of how the servers handle their own information - in fact, the two could each do it differently with no conflict. In the example in section 6, it appears that server 1 needs to be configured with at least enough knowledge spanning service providers that it can decide from a user class which 'server 2' to get more configuration info from. This means that there is by definition some serious cooperation between the admins of the various servers; why not centralize all of the configuration data? >> >> In section 5, also, the client is quite broken if something more than just >> the IP address, netmask and default gateway are not given. You do specify >> the specific partitions to be outside the scope of the document; perhaps a >> warning indicating broken clients would be appropriate or a more complete >> fallback set of options? What I'm getting at is some method of informing >> the user that their configuration is incomplete and should not expect full >> functionality. (A special DNS server with a * RR that points to a default >> "your client is broken" website is a possibility, but perhaps beyond the >> scope of this document.) > [Privat,J,Jerome] In normal operation, server_1 will be able to >retrieve information from server_2 and will therefore return > a complete configuration to the client. But you are right there may >some conditions in which this is not possible. In this > case, server_1 could in some way notify the client that its >configuration is incomplete. Or server_1 could return a local > set of options. This would depend on agreement between the two >administrations. > > Thanks, > Jerome RFC 2131 already talks about the problem of incomplete parameters coming back to a client - it has always been a potential problem, if nothing more than due to mis- or incomplete server configuration. It seems to me that all of the functionality that this draft tries to specify can be implemented within the current reach of the protocol - are any changes or additions really necessary? Regards, Richard From dhcp-v4@bucknell.edu Thu Oct 7 08:24: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 IAA13387 for ; Thu, 7 Oct 1999 08:24: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 HAA22152; Thu, 7 Oct 1999 07:33:41 -0400 (EDT) Date: Thu, 7 Oct 1999 07:33:41 -0400 (EDT) Message-Id: <199910071056.GAA20814@uplink.net> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: FW: IETF letter re DHCP agent options. X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 message sent to dhcp-v4@bucknell.edu by LZZ007@EMAIL.MOT.COM follows. --------------------------------------------------------------------- Ralph, It was a fair amount of work, but I finally got Motorola corporate to agree to a royaltee-free status IF we ever get a patent on DHCP agent options. The attached letter is on the IETF Intellectual Rights page. With the RFC 2026 boilerplate in the -07 draft, this should satisfy the IESG's concerns with advancing DHCP relay agent options -07 to RFC. Right, Tom? Ralph, is another WG last call required, or is this enough? Thanx, -mike -----Original Message----- From: Dailey Kirk-AKD001 [mailto:Kirk.Dailey@motorola.com] Sent: Saturday, September 25, 1999 4:58 AM To: scoya@ietf.org Cc: Michael W. Patrick Subject: RE: IETF letter re DHCP agent options. To: Mr. Steve Coya, Internet Engineering Task Force scoya@ietf.org Re: Motorola Patent Application for DHCP Relay Agent Options This is to inform the IETF that in the event that Motorola is granted a patent or patents essential to the implementation of the internet draft , Motorola agrees to grant a royalty-free license to all parties implementing the draft, subject to reciprocity of the licensed party. This grant immediately cancels to any party asserting rights against Motorola for a method or methods described in the draft. Inquiries are directed to Mr. Kirk Dailey, Kirk.Daily@motorola.com. Please post this on the IETF Intellectual Properties Rights Page. Regards, Kirk Dailey From dhcp-v4@bucknell.edu Thu Oct 7 08:32: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 IAA13630 for ; Thu, 7 Oct 1999 08:32: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 HAA23831; Thu, 7 Oct 1999 07:05:11 -0400 (EDT) Date: Thu, 7 Oct 1999 07:05:11 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: FW: IETF letter re DHCP agent options. X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 message sent to dhcp-v4@bucknell.edu by LZZ007@EMAIL.MOT.COM follows. --------------------------------------------------------------------- Ralph, It was a fair amount of work, but I finally got Motorola corporate to agree to a royaltee-free status IF we ever get a patent on DHCP agent options. The attached letter is on the IETF Intellectual Rights page. With the RFC 2026 boilerplate in the -07 draft, this should satisfy the IESG's concerns with advancing DHCP relay agent options -07 to RFC. Right, Tom? Ralph, is another WG last call required, or is this enough? Thanx, -mike -----Original Message----- From: Dailey Kirk-AKD001 [mailto:Kirk.Dailey@motorola.com] Sent: Saturday, September 25, 1999 4:58 AM To: scoya@ietf.org Cc: Michael W. Patrick Subject: RE: IETF letter re DHCP agent options. To: Mr. Steve Coya, Internet Engineering Task Force scoya@ietf.org Re: Motorola Patent Application for DHCP Relay Agent Options This is to inform the IETF that in the event that Motorola is granted a patent or patents essential to the implementation of the internet draft , Motorola agrees to grant a royalty-free license to all parties implementing the draft, subject to reciprocity of the licensed party. This grant immediately cancels to any party asserting rights against Motorola for a method or methods described in the draft. Inquiries are directed to Mr. Kirk Dailey, Kirk.Daily@motorola.com. Please post this on the IETF Intellectual Properties Rights Page. Regards, Kirk Dailey From dhcp-v4@bucknell.edu Thu Oct 7 11:43: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 LAA19285 for ; Thu, 7 Oct 1999 11:43: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 LAA13180; Thu, 7 Oct 1999 11:41:57 -0400 (EDT) Date: Thu, 7 Oct 1999 11:41:57 -0400 (EDT) Message-Id: <37FCB8F3.FE3686AD@metaip.checkpoint.com> Errors-To: droms@bucknell.edu Reply-To: RichardJ@metaip.checkpoint.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Richard Jones To: Multiple recipients of list Subject: Re: I-D ACTION:draft-privat-dhc-doublephase-01.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.6 [en] (WinNT; U) Content-Transfer-Encoding: 7bit Thank you, Ralph! I'm currently having some problems with the list server, having been subscribed long before under a different email address. I've repeated the unsubscribe/subscribe ritual this morning, and will see if that helps... If not, may I contact you again for assistance? Regards, Richard "by way of Ralph Droms " wrote: > message sent to dhcp-v4@bucknell.edu by RICHARDJ@METAIP.CHECKPOINT.COM > follows. > ---------------------------------------------------------------------------- > --- > >Date: Fri, 1 Oct 1999 08:59:00 +0100 > >From: jerome.privat@bt.com > >To: ndlane@wal-mart.com, dhcp-v4@bucknell.edu > >Message-ID: > <5104D4DBC598D211B5FE0000F8FE7EB2E6BC01@mbtlipnt02.btlabs.bt.co.uk> > > > > I also prefer the proxy option as it does not require any client > >changes and makes it easier to preserve > > the atomicity of the transaction. All the answers I got in private > >emails also agree with that. > > Count me as another vote for not requiring client behavior changes whenever > possible (except where they already violate the protocol!). > > >> I think DHCP server A proxies to DHCP server B to get the options > >> between DHCPDISCOVER & DHCPOFFER using LDAP or some other generic > >> mechanism is a better approach. While it is sometimes difficult to insert > >> an extra processing step between discover & offer due to time constraints, > >> it would not require massive client changes. > > The draft has the first server sending a DHCPINFORM message to the second one. > Not a problem, except that the second server is expected to use the subnet > that > the request came in on (or the giaddr field in the packet) to determine the > set > of configuration parameters that should be returned. In this case, the first > server > would have to pretend to be a relay agent and create a request packet that > will be > > interpreted properly. Doable, certainly, but it seems like on a heavily used > network it could mean a noticeable amount of overhead. > > > [Privat,J,Jerome] > > In the proxy option, the draft proposes to use DHCP to do the > >communication between the 2 DHCP servers > > [in a similar way as we would use a AAA protocol to do proxying > >between AAA servers]. Another possibility, > > as you mention, would be to have server_1 do an ODBC or LDAP query > >to server_2. Has anyboby a strong view on which > > of these two options is the best? > > I think a protocol should be restricted to defining the behavior of service > providers > and consumers, and keep implementation requirements to a minimum (or at least > at the 'suggestion' level). In this draft, that means doing a DHCPINFORM is a > good way to go, because there's no specification of how the servers handle > their > own information - in fact, the two could each do it differently with no > conflict. > > In the example in section 6, it appears that server 1 needs to be > configured with > at least enough knowledge spanning service providers that it can decide from a > user class which 'server 2' to get more configuration info from. This means > that > there is by definition some serious cooperation between the admins of the > various servers; why not centralize all of the configuration data? > > >> > >> In section 5, also, the client is quite broken if something more than just > >> the IP address, netmask and default gateway are not given. You do specify > >> the specific partitions to be outside the scope of the document; perhaps a > > >> warning indicating broken clients would be appropriate or a more complete > >> fallback set of options? What I'm getting at is some method of informing > >> the user that their configuration is incomplete and should not expect full > >> functionality. (A special DNS server with a * RR that points to a default > >> "your client is broken" website is a possibility, but perhaps beyond the > >> scope of this document.) > > [Privat,J,Jerome] In normal operation, server_1 will be able to > >retrieve information from server_2 and will therefore return > > a complete configuration to the client. But you are right there may > >some conditions in which this is not possible. In this > > case, server_1 could in some way notify the client that its > >configuration is incomplete. Or server_1 could return a local > > set of options. This would depend on agreement between the two > >administrations. > > > > Thanks, > > Jerome > > RFC 2131 already talks about the problem of incomplete parameters coming > back to a client - it has always been a potential problem, if nothing more > than > due > to mis- or incomplete server configuration. It seems to me that all of the > functionality > that this draft tries to specify can be implemented within the current > reach of > the > protocol - are any changes or additions really necessary? > > Regards, > Richard From dhcp-v4@bucknell.edu Thu Oct 7 15:19: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 PAA24328 for ; Thu, 7 Oct 1999 15:19: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 PAA03213; Thu, 7 Oct 1999 15:15:17 -0400 (EDT) Date: Thu, 7 Oct 1999 15:15:17 -0400 (EDT) Message-Id: <37FCEF8B.4A933C57@saintmarys.edu> Errors-To: droms@bucknell.edu Reply-To: mhegedus@saintmarys.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Mary Ellen Hegedus To: Multiple recipients of list Subject: Re: DHCP and Internet Access 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.06 [en] (Win95; I) Content-Transfer-Encoding: 7bit How do I get out of this service??? I was put here by mistake and want to unsubscribe. Mary Ellen Hegedus by way of Ralph Droms wrote: > message sent to dhcp-v4@bucknell.edu by JHERBERT@WILCO-INT.COM follows. > ----------------------------------------------------------------------- > Hi - > > I am currently setting up a DHCP server for what will be around 500 clients. > Circa 100 of which are considered "trusted clients" and have been granted > Internet Access via their IP address thru the firewall. > > What I need to know is this - Is it possible to configure a Solstice > Firewall to grant access to the Internet via recognising a trusted machine > name, or does it need to operate via the IP address? If we cannot change the > firewall, is there anyway we can reserve a bank of IPs on the DHCP server to > allocate to certain machine names? > > Thanks > > James Herbert > Internal Systems > Wilco International Ltd > > ---------------------------------------------------------------------------- > ---- > The information transmitted is intended only for the person or entity to > which > it is addressed and may contain confidential and/or privileged material. > Any review, retransmission, dissemination or other use of, or taking of any > action in reliance upon, this information by persons or entities other than > the intended recipient is prohibited. > If you received this in error, please contact the sender and delete the > materialfrom any computer. > ---------------------------------------------------------------------------- > ---- From dhcp-v4@bucknell.edu Thu Oct 7 16:53: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 QAA25318 for ; Thu, 7 Oct 1999 16:53: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 QAA20973; Thu, 7 Oct 1999 16:51:06 -0400 (EDT) Date: Thu, 7 Oct 1999 16:51:06 -0400 (EDT) Message-Id: <63D30D6E10CFD11190A90000F805FE8601CE6F53@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: IETF letter re DHCP agent options. X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain X-Mailer: Internet Mail Service (5.0.1460.8) Mime-Version: 1.0 It would be most helpful to spell out what is meant by : "subject to reciprocity of the licensed party" What does Motorola expect the licensed party to do / not do as per the above? -----Original Message----- From: dhcp-v4@bucknell.edu [mailto:dhcp-v4@bucknell.edu] Sent: Thursday, October 07, 1999 7:35 AM To: Multiple recipients of list Subject: FW: IETF letter re DHCP agent options. message sent to dhcp-v4@bucknell.edu by LZZ007@EMAIL.MOT.COM follows. --------------------------------------------------------------------- Ralph, It was a fair amount of work, but I finally got Motorola corporate to agree to a royaltee-free status IF we ever get a patent on DHCP agent options. The attached letter is on the IETF Intellectual Rights page. With the RFC 2026 boilerplate in the -07 draft, this should satisfy the IESG's concerns with advancing DHCP relay agent options -07 to RFC. Right, Tom? Ralph, is another WG last call required, or is this enough? Thanx, -mike -----Original Message----- From: Dailey Kirk-AKD001 [mailto:Kirk.Dailey@motorola.com] Sent: Saturday, September 25, 1999 4:58 AM To: scoya@ietf.org Cc: Michael W. Patrick Subject: RE: IETF letter re DHCP agent options. To: Mr. Steve Coya, Internet Engineering Task Force scoya@ietf.org Re: Motorola Patent Application for DHCP Relay Agent Options This is to inform the IETF that in the event that Motorola is granted a patent or patents essential to the implementation of the internet draft , Motorola agrees to grant a royalty-free license to all parties implementing the draft, subject to reciprocity of the licensed party. This grant immediately cancels to any party asserting rights against Motorola for a method or methods described in the draft. Inquiries are directed to Mr. Kirk Dailey, Kirk.Daily@motorola.com. Please post this on the IETF Intellectual Properties Rights Page. Regards, Kirk Dailey From dhcp-v4@bucknell.edu Thu Oct 7 18:16:18 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26284 for ; Thu, 7 Oct 1999 18:16: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 SAA09115; Thu, 7 Oct 1999 18:15:05 -0400 (EDT) Date: Thu, 7 Oct 1999 18:15:05 -0400 (EDT) Message-Id: <37FD0B52.DD75EA89@metaip.checkpoint.com> Errors-To: droms@bucknell.edu Reply-To: richardj@metaip.checkpoint.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Richard Jones To: Multiple recipients of list Subject: (no subject) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.6 [en] (WinNT; U) Content-Transfer-Encoding: 7bit get dhcp-v4 log9607 get dhcp-v4 log9612 From dhcp-v4@bucknell.edu Thu Oct 7 18:19:46 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26318 for ; Thu, 7 Oct 1999 18:19: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 SAA11482; Thu, 7 Oct 1999 18:19:12 -0400 (EDT) Date: Thu, 7 Oct 1999 18:19:12 -0400 (EDT) Message-Id: <199910072123.RAA13529@grosse.manhattan.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: IETF letter re DHCP agent options. X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 I'm not a lawyer, but it looks pretty clearly like if you claim some kind of IP protection of your own on the technique covered by the patent and are asserting that right against Motorola (i.e., suing them, or demanding that they assign their rights to you) that you would then relinquish your right to use the technique covered in the draft. This seems reasonable to me - if you want to use the technique, you should agree not to claim the exclusive right to use it for yourself. _MelloN_ From dhcp-v6@bucknell.edu Fri Oct 8 09:44: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 JAA20502 for ; Fri, 8 Oct 1999 09:44: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 JAA22102; Fri, 8 Oct 1999 09:39:40 -0400 (EDT) Date: Fri, 8 Oct 1999 09:39:40 -0400 (EDT) Message-Id: <199910081329.JAA08376@mail.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v6@bucknell.edu Sender: dhcp-v6@bucknell.edu Precedence: bulk From: Internet-Drafts@ietf.org (by way of Ralph Droms ) To: Multiple recipients of list Subject: I-D ACTION:draft-aboba-zeroconf-multi-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion list for DHCPv6 internet protocol. Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 FYI... - Ralph ===== A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Auto-Addressing in Multi-segment Networks Author(s) : B. Aboba Filename : draft-aboba-zeroconf-multi-00.txt Pages : 8 Date : 07-Oct-99 Today, with the rapid rise of home networking, there is an increasing need for simplified mechanisms for IPv4 address allocation within multi- segment networks connected by a single router. This issue can arise, for example, in the case of a home network supporting 802.11 wireless as well as Ethernet. In multi-segment small networks connected by a single router, it may be desirable to provide for consistent IPv4 addressing in the case where the small network has not been assigned a routable IPv4 address prefix. This draft describes how this problem may be solved through implementation of a mini-DHCP server within the router. The router may either be disconnected from the Internet, in which case the hosts on the multiple segments will only be able to reach other, or the router may offer Internet connectivity via Network Address Translation (NAT), or another suitable mechanism, such as RSIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-aboba-zeroconf-multi-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-aboba-zeroconf-multi-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-aboba-zeroconf-multi-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19991007081652.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-aboba-zeroconf-multi-00.txt From dhcp-v4@bucknell.edu Fri Oct 8 09:45: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 JAA20551 for ; Fri, 8 Oct 1999 09:45: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 JAA05925; Fri, 8 Oct 1999 09:44:29 -0400 (EDT) Date: Fri, 8 Oct 1999 09:44:29 -0400 (EDT) Message-Id: <199910081329.JAA08376@mail.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: Internet-Drafts@ietf.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Internet-Drafts@ietf.org (by way of Ralph Droms ) To: Multiple recipients of list Subject: I-D ACTION:draft-aboba-zeroconf-multi-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 FYI... - Ralph ===== A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Auto-Addressing in Multi-segment Networks Author(s) : B. Aboba Filename : draft-aboba-zeroconf-multi-00.txt Pages : 8 Date : 07-Oct-99 Today, with the rapid rise of home networking, there is an increasing need for simplified mechanisms for IPv4 address allocation within multi- segment networks connected by a single router. This issue can arise, for example, in the case of a home network supporting 802.11 wireless as well as Ethernet. In multi-segment small networks connected by a single router, it may be desirable to provide for consistent IPv4 addressing in the case where the small network has not been assigned a routable IPv4 address prefix. This draft describes how this problem may be solved through implementation of a mini-DHCP server within the router. The router may either be disconnected from the Internet, in which case the hosts on the multiple segments will only be able to reach other, or the router may offer Internet connectivity via Network Address Translation (NAT), or another suitable mechanism, such as RSIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-aboba-zeroconf-multi-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-aboba-zeroconf-multi-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-aboba-zeroconf-multi-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19991007081652.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-aboba-zeroconf-multi-00.txt From dhcp-v4@bucknell.edu Fri Oct 8 12:57: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 MAA26115 for ; Fri, 8 Oct 1999 12:57: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 MAA20937; Fri, 8 Oct 1999 12:56:54 -0400 (EDT) Date: Fri, 8 Oct 1999 12:56:54 -0400 (EDT) Message-Id: <4.2.0.58.19991008121634.014b4e60@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: Minutes of 2nd Failover conference call 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.2.0.58 Yesterday, we held the second of three conference calls concerning the current failover protocol draft: The third (and last of this series) will be held Thursday, Oct 14, from 12-3pm EDT. Please contact me if you are interested in attending. Yesterday's meeting was well attended, and we made a lot of progress (again)! Thanks to all of you who attended this call. The roster of attendees is at the end of this mail. Cheers -- Kim ------------------------------------------------- Minutes from the 10/7/99 Failover conference call. We had good attendance again at the conference call held on Thursday, Oct 10, 1999. The agenda was: conflict resolution, initialization, and state transitions. We covered those issues, as well as covering some additional issues. IP Address Question ------------------- While we were waiting for people to arrive at the meeting, Andre Kostur asked a question in email and Kim tried to answer it. The question was: what about a server which determines the addresses it can give out based on a particular client's identity? The answer is that the failover protocol tries to stay away from these issues. The plan is that each server in the failover pair is configured identically, and so that based on the IP address, the receiving server knows into which bucket (pool, scope) an address falls. The sending server and receiving server are supposed to agree, so that the protocol doesn't have to know about this. Likewise, the primary server will send to the secondary server the correct number of addresses in each "sub-pool" or whatever, and the secondary server will know about each sub-pool and will put the newly available addresses in the sub-pool. Conflict Resolution ------------------- Kim Kinnear started off with a general discussion of where conflict resolution is handled within the protocol. He pointed out that it isn't only when a server is in POTENTIAL-CONFLICT state, but rather whenever a server receives a BNDUPD it needs to determine if it is willing to accept that information from the other server. Thus, conflict resolution is an ongoing, real-time operation. The two kinds of conflict resolution mentioned by Kim are: 1. Where one IP address is leased to one client on one server and a different client on another server. 2. Where one client has one IP address leased on one server, and that same client has a different IP addresses leased on the other server. Steve Gonczi added two more: 3. One server shows an IP address as free, and the other server shows it as leased. 4. One server has a different expiration time than the other server. Kim responded that #3 and #4 were, at least in his opinion, not conflicts but just normal parts of the way the protocol works. Kim then pointed out that there are a number of times that are sent in a BNDUPD: lease-expiration-time potential-expiration-time client-last-transaction-time and a larger set that must be saved in the stable storage on each machine: lease-expiration-time -- time given to client sent-potential-expiration-time -- latest time sent to partner acked-potential-expiration-time -- latest time acked by partner received-potential-expiration-time -- latest time received from and acked to partner A server can offer/ack to a DHCP client a time that is no longer than the MCLT beyond the max( received-potential-expiration-time, acked-potential-expiration-time). When a server goes into PARTNER-DOWN state, it must wait the MCLT beyond the max( lease-expiration-time, sent-potential-expiration-time, acked-potential-expiration-time, received-potential-expiration-time ) for each IP address. The reason for this is so that in the simple case, where the primary updates the secondary and then fails, the secondary can extend the client's lease using the received-potential-expiration-time, (which will be long), instead of just the acked-potential-expiration-time, which will in general be zero since the secondary has never updated the primary at all at this point. The pragmatic difference here is that if we allow the secondary to use only the acked-potential-expiration-time, it will only extend the lease by the MCLT, but it we allow it to use the received-potential-expiration time (i.e., a time that it has acked to the partner), then it can give out a full lease renewal, which could make a *big* difference in secondary server load. The consequences of allowing this optimization -- i.e., the secondary can use a time that it has acked to the primary as well as a time that the primary has acked to the secondary when making a lease, then when we enter PARTNER-DOWN state, we must wait not only for times that the partner has acked to us and times that we have acked to the partner, but also times that we have sent to the partner (whether they were acked or not, since the ACK could have been lost). Kim agreed to specify what to do on NAK (send and receive), whether it should cause an update or what. Several people reminded Kim to be careful about NAK storms. Kim agreed to tie the reject-reason codes into the draft, with references both ways. While there was considerable discussion about conflict resolution, the upshot of the discussion was that Kim would try to make it clearer in the next draft, and people would try to read it and make sense of it. Someone proposed a simple conflict resolution strategy -- if the state in the incoming BNDUPD is different than the one you have, take it. Kim said that such a strategy didn't work in practice. Kim expressed a longing for a simple, one paragraph statement of the conflict resolution strategy, but stated that he had tried several, and they kept developing special state-specific cases (as in, current state = x, BNDUPD state = y, then do z). Initialization -------------- Bernie Volz suggested that we explain the STARTUP state in section 5 as well as in section 9, and state the general approach of waiting to determine if we can talk to the other server before launching off and serving DHCP clients, and Kim agreed. Bernie had some other small changes to make to the STARTUP state. State Transitions ----------------- We talked about what the states of a lease mean, and someone pointed out that the FREE state was misdocumented. Kim agreed to fix it, and also to include a state transition diagram for the failover canonical lease states. The goal for the lease states in the failover draft is for them to be general enough to model any vendor's server. As for the failover endpoint states, Diana Lane brought up a concern that two servers in the POTENTIAL-CONFLICT state are unresponsive to DHCP clients, and if that took a while, it would be a problem. Kim pointed out that since the resolution process was automatic, it in general wouldn't be too long. She asked what happens if communications is interrupted during this resolution process, and Kim said that the primary server would go into PARTNER-DOWN state and the secondary would remain unresponsive in POTENTIAL-CONFLICT state. She was (rightly) concerned about the case where the primary server crashing was the reason that communications was interrupted. Steve suggested that we move the servers into COMMUNICIATIONS-INTERRUPTED state in this situation, and Bernie and Kim said that you can't do that, since when they talk again they will move back to NORMAL state. Bernie said that we needed a new state, and Kim agreed to put on in, and it won't be called "POTENTIAL-CONFLICT-COMMUNICATIONS-INTERRUPTED". We talked about conflict resolution, and how long it would take, and due in considerable part to Richard Jones and Ralph Droms' approach, we ended up defining three kinds of conflict resolution: 1. "deal-with-it", automatic, conflict resolution, which is what is currently specified in the draft. 2. "put-it-off" conflict resolution, where a lease that has a significant conflict is ABANDONED and left for a human to work out later. 3. "interactive" conflict resolution, where a human is presented with the conflicts and instructs the servers as to how to resolve them. The draft will be extended to support all three styles of conflict resolution, with only #1 being a MUST. That is to say, all servers MUST be able to support a #1 style conflict resolution regime, but they MAY also supply a #2 or #3 style as well. Kim agreed to mention in the draft that if in PARTNER-DOWN state you use up your own IP addresses prior to using the partner's, you stand a better chance of not having conflicts. Miscellaneous ------------- 1. Steve brought up an issue he had with expired or freed IP addresses becoming owned by the primary and having to be reallocated to the secondary. He said that if we didn't allow a server to renew a lease about which it had no information, then we could restructure the way we handle newly freed IP addresses so they wouldn't have to cycle through the primary. Kim said that one reason that we had the ability to renew any IP address as long as it was available, even if we hadn't any direct information about that client, was so that if a server crashes after leasing an IP address to a client and before the BNDUPD, that client could still get an renewal from the other server. Steve said that was a marginal case, and couldn't affect more than 2 or 3 clients in the event of a crash, but that the optimization that he wanted to do would affect lots of clients. Bernie pointed out that the ability to renew a lease for a client a server has not heard of is key to other parts of the protocol, for instance in the situation where a server crashes, the other makes a bunch of leases, and then it crashes and the first server comes back up. This will work today, and any client that got a lease from either server will be able to get a renewal. Steve said that he withdrew his request in the light of these difficulties. ------------- Bernie brought up some of the issues that he had mailed out. Here they are in his words (from his mail) with the resolution added in indented text: ---------- 2. MCLT Time. We should give some guidelines as to how to set it and perhaps even suggest default(s). What's the impact of a short time vs a long time. Agreed, it will go in the draft. 3. Switch to PARTNER-DOWN. The text in Section 5.2.1 (Control of Lease Time) needs to be enhanced. The key point when switching to PARTNER-DOWN mode is that the you need to apply the MCLT time to anything that happened before entering PARTNER-DOWN. You need not apply MCLT to anything that happens after entering PARTNER-DOWN. Agreed, Kim will augment section 5 with the key points of PARTNER-DOWN state. 4. I think a section on Startup issues should be included (in section 5). For example, I would expect that a server coming up would take some time to attempt to communicate with the peer before proceeding with possibly old state information it had. And, there may be cases (such as after loss of storage), where a server should just wait until the partner is available before starting. Kim pointed out the STARTUP state explanation in section 9, and agreed to add information to section 5 as well. 5. XIDs. There are packets that have no acknowledgement (such as the STATE packets). Should these have an XID? What XID should be used (next number or 0 or ?). We could just say use whatever you want, just don't expect it to be ACKed. Kim said he would clarify the draft. 6. GRACE Binding Status and grace expiration time. I'm still not 100% clear on these with respect to failover, especially what happens when a server doesn't have these states (perhaps one server of the pair has them and the other doesn't). We either must require these states or provide details on what a server that doesn't have them does when it receives BNDUPDs with these states (and what a server that has them does if the peer doesn't use these states). Kim pointed out that section 7.1.2 has information as to what to do if you don't implement one of these states, but that he would explain it all in text associated with a state transition diagram for the failover canonical lease states. 7. 7.3.2 (Receiving the UPDREQ message). We need to clarify what happens to NEW BNDUPDs that happen during the UPDREQ (UPDREQALL) process, such as if new client leases are honored. Should they be covered by the UPDDONE or not? If they are, it may be impossible to send the UPDDONE if clients are leasing fast enough so I would think they should NOT be included. Kim said that he agreed with Bernie that they should *not* be tracked as part of the UPDDONE processing, and that he would ensure that the draft said this clearly. 8. Connection close and severe errors. I think a section on this topic might be useful. Send error if possible, but close connection if not. Kim agreed to add some way to send an error message on the close of a connection. 9. A TCP issue ... 7.9.1 states that "The tSend timer SHOULD be approximately 20 percent of the time in the receiver-timer option". I do think that this might be a bit low. Especially if you want the servers to detect the other being down within a minute - this basically means you need to send every 12 seconds on the connection. I'd think something like 50% should be sufficient. That gives the network half the time-out time to deliver the packet and causes a send only every 30 seconds. I also think that this high rate of activity should be documented clearly; you won't want to run the Failover protocol over a ISDN or X.25 line unless you're really willing to pay for it. I'm also wondering whether one could think of having an "idle" state. When a server detects that things have been basically idle for a while (how long is implementation specific), it sends a new message to the peer telling it "Hey, we're not doing anything useful so lets close the connection down for now. When you (or I) have something useful to send, we'll first attempt to reopen the connection." Reason for this is that many office sites will probably be doing nothing more than exchanging CONTACT messages from 8PM to 7AM (this depends on lease times, etc). During this period you might otherwise be sending thousands of CONTACT messages in each direction. Of course, this would require both servers to enter COMMUNICATIONS- INTERRUPTED state such that they can give out leases. When a lease is given out, the communication would be restarted and hence all would resume normal processing. Also, a check every so often should be done to avoid triggering PARTNER-DOWN mode. The changes to the server logic are basically: a) Detect idle case (such as CONTACT messages in a row), send idle notification, set idle flag, close connection. b) Don't restart connection if idle flag set. c) Clear idle flag whenever an event happens that requires communication (to assure connection is reestablished) or after n% of PARTNER-DOWN time has elapsed. We talked at length about this issue, and while at least some of the people on the call understood exactly what this would be useful for, and that it would be useful in some situations, nobody besides Bernie felt that it would be useful enough to warrant the extra complexity that would be required in both specification as well as implementation. Kim agreed to mention it as an "open issue", though since agreeing to do so, he's not sure even that is a good idea, since it received a pretty firm and complete "no" vote from everyone who said anything at the meeting besides Bernie. Kim will discuss this with Bernie and resolve it. ------------- end of Bernie's items ------------------------ The attendees at this meeting were: Ralph Droms Bucknell U. EDT droms@bucknell.com David Erdmann Nortel Networks EDT derdmann@nortelnetworks.com Steve Gonczi Process Software EDT gonzci@process.com Richard Jones Checkpoint Software PDT richardj@metaip.checkpoint.com Kim Kinnear Cisco Systems EDT kkinnear@cisco.com Andre Kostur Incognito PDT andre@incognito.com Diana Lane Wal-Mart Stores CDT dblane@wal-mart.com Ted Lemon Internet Engines EDT mellon@isc.org Thomas Narten IBM/IETF area dir EDT narten@raleigh.ibm.com Greg Rabil Lucent Technologies EDT agrabil@quadritek.com Mark Stapp Cisco Systems EDT mjs@cisco.com Rob Stevens Join Systems PDT robs@join.com Bernie Volz Process Software EDT volz@process.com From dhcp-v6@bucknell.edu Fri Oct 8 15:40: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 PAA29506 for ; Fri, 8 Oct 1999 15:40:03 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA03870; Fri, 8 Oct 1999 15:37:18 -0400 (EDT) Date: Fri, 8 Oct 1999 15:37:18 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v6@bucknell.edu Sender: dhcp-v6@bucknell.edu Precedence: bulk From: Mike Carney - SNT Internet Engineering To: Multiple recipients of list Subject: Responses from authors on DHCPv6 issues list, part 1 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion list for DHCPv6 internet protocol. Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Mime-Version: 1.0 Comments welcome. bound/mwc/perkins 10/08/99 List of DHCPv6 Issues with responses, part 1 of 2 ================================================= DHCPv4 disadvantages to avoid: ============================== * Lack of mechanism for defining server priority. Response: DHCPv6 provides this functionality through the use of the "preference" field in the advertise message. * BOOTP heritage. DHCP suffers alot from overloading the BOOTP packet format simply to leverage BOOTP relay agent functionality. Response: Simply not an issue for DHCPv6. * Current option format too restrictive. Not enough options, value lengths too small. Alleviating this problem in DHCPv4 made difficult due to BOOTP heritage. Response: DHCPv6 extensions avoid this problem by specifying a 16bit unsigned type field followed by a 16 bit unsigned length field, permitting 64k extensions, with a maximum length of 64k-2 in length. * Uses broadcast. Response: IPv6 doesn't have broadcast. * Overloading single Packet type for multiple purposes. DHCPREQUEST's use in INIT, INIT-REBOOT, and RENEW/REBIND has been a source of major confusion for implementors. We should avoid overloading packet types as much as possible. Response: We hear you. We'll separate the two forms of the reconfigure message into different message types. * Confusion about interaction between vendor class id and encapsulated vendor option. Verbiage in original RFC 1541 appears to have been deleted in RFC 2131. Response: The platform specific Information section of the extensions document describes in detail the use of the exncapsulated platform-specific extension and its relationship with the platform class identifier. DHCPv4 advantages, DHCPv4-based questions ========================================= * Does not require service on every link; service can be remote from client's link Response: DHCPv6 has a notion of a relay agent, thus DHCPv6 has this feature. * Has specified an optional server to server synchronization protocol. Response: We do not consider a server to server protocol as part of the base DHCPv6 specification; however, we will work with the DHCPv4 server to server people to ensure that the DHCPv6 protocol does not have any elements that would prevent a separate specification of a server to server protocol from being written. * DHCPv4 / DNS interaction finally reaching maturity. How well defined is this in DHCPv6? Response: Very well-defined. DNS integration as always been a goal of DHCPv6 from the start. * Is what has been learned during the DHCP authentication draft development useful in the discussion in the v6 extensions draft? Response: DHCPv6 defines a Client-Server authentication extension in the extensions draft. It is the same authentication mechanism that is used by Mobile IP. DHCPv6 draft issues =================== * Document organization makes protocol unclear. Information is duplicated, some info contradictory. Response: The authors have committed to reorganize this document to make it clearer, as well as provide an introductory section showing the interaction between client and server. We also will have a state transition diagram to help the reader become oriented properly when reading the material. * RECONFIGURE / renumbering semantics unclear. Response: We'll clarify these points. Note also that we will be defining a new message to avoid overloading the RECONFIGURE message. * Do we still need the added complication of the ability to request multiple addresses, in the light of http 1.1? (this support is seen as a source of major complication in the current draft) Response: The authors feel that this functionality is fundamental to IPv6, thus it needs to stay in the specification. We will endeavor to clarify the description as much as possible. * What about the new media becoming available? How well will DHCPV6 work in these environments? Example: IEEE 1394, USB, CDN. What about traditional environments? ATM, FDDI. Are there any issues with multicast in these environments? What about PPP? Response: Unlike DHCPv4, DHCPv6 doesn't depend on any "special" IP level magic to do its job. Thus, DHCPv6 should work on any media that supports IPv6/multicast. * Lack of a DHCPv4 -> DHCPv6 section describing the differences between the protocols (useful for DHCPv4 folks thinking about implementing DHCPv6). Response: Um, we got that - appendix C. * Seems like there are too many alternatives for releasing resources. Response: Yes, this point needs work. We need to unify the release feature somewhat, or provide a section on releasing which goes into details on how it's done for each of the legal message types. * (Section 6) Is the mandate for implementation strategy too strong? Why is XID transaction cache described in such detail? Response: We need to clarify this some. We didn't intend to mandate the implementation strategy, but rather state that if an implementor chooses to implement a XID transaction cache, then this is how it should work. * Which messages are not idempotent (and why not?) Response: We believe they all are idempotent. Clarification from the DHC WG requested please. * In case of a RECONFIGURE failure, loosen text to specify "notify administrator" (rather than "log to error log"). Response: Ok. * Section 6.3.2: Clarify that 'C' bit semantics are to release all resources, reallocate only those requested in message. Response: Ok. * Section 6.4: What does client do with response? Add MUST/SHOULD. Response: Should be in 5.6; will add text. * RFC 2119 terminology misused. Response: Will review our use of this terminology. * retransmission backoff not always exponential, and is sometimes too short. Response: Will investigate - we'll ensure drafts correct on this point. * Error codes not sequential, and there is no discussion of how error codes are allocated (IANA?) Response: The error codes are organized in logical groups. We'll add text describing what these groups are. * Some extensions require association with server that sent the message (releasable resources?) There is no way to signal this to the client in a way that avoids having to rev the client when new such extensions are deployed. Would be much better to flag such options with a bit that would allow clients to function appropriately w/o change. Response: Releasable resources must be requested by the client, and in order for the client to request them, the client must therefore understand that the extension it is requesting is releasable, and thus take care to release it when that resource is no longer needed. * prefix-size description unclear. Response: We'll add text to explain that the prefix-size is set by relay to inform server what network link the client is on (prefix-size of client's link). * Impact that receiving an IP address with 0 lifetime as denial of service attack not handled. Need to look at addrconf solution to this problem. Response: We'll add a reference to the autoconf solution. From dhcp-v4@bucknell.edu Mon Oct 11 06:39: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 GAA26222 for ; Mon, 11 Oct 1999 06:39: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 GAA27733; Mon, 11 Oct 1999 06:36:57 -0400 (EDT) Date: Mon, 11 Oct 1999 06:36:57 -0400 (EDT) Message-Id: <000a01bf13e4$4f040d00$3b65650a@uis.edu> Errors-To: droms@bucknell.edu Reply-To: permpibo@eagle.uis.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Kan Permpiboon" To: Multiple recipients of list Subject: benefits and problems X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook Express 5.00.2314.1300 Content-Type: multipart/alternative; Mime-Version: 1.0 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01BF13A9.A272DA60 Content-Type: text/plain; charset="windows-874" Content-Transfer-Encoding: quoted-printable I'm new here. Could anyone tell me what benefits and problems dynamic = addressing (DHCP) provide?=20 Thanks=20 :) ------=_NextPart_000_0007_01BF13A9.A272DA60 Content-Type: text/html; charset="windows-874" Content-Transfer-Encoding: quoted-printable
I'm new here. Could anyone tell me what = benefits=20 and problems dynamic addressing (DHCP) provide?
Thanks
:)
------=_NextPart_000_0007_01BF13A9.A272DA60-- ------- From dhcp-v6@bucknell.edu Mon Oct 11 12:41:49 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08707 for ; Mon, 11 Oct 1999 12:41:48 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA02012; Mon, 11 Oct 1999 12:38:06 -0400 (EDT) Date: Mon, 11 Oct 1999 12:38:06 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v6@bucknell.edu Sender: dhcp-v6@bucknell.edu Precedence: bulk From: Mike Carney - SNT Internet Engineering To: Multiple recipients of list Subject: Connectathon '00 Announcement X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion list for DHCPv6 internet protocol. Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Mime-Version: 1.0 Hi Folks, Connectathon testing for DHCP will be held in March on the 6th through the 8th (that's monday through wednesday). If you'd be interested in volunteering as DHCP technology coordinator for this connectathon, please let Audrey and me know. I've been doing this for 4 years, and I'd like to give someone else an opportunity to lead the testing. Connectathon is vendor-neutral, so any implementor is welcome to volunteer. If you have items you'd like to see tested for this session (such as DHCPv6 or server-to-server) send them along! Here's the official announcement: Plans for Connectathon 2000 are already under way! The 14th annual Connectathon event, an interoperability testing event for engineers only, will be held March 2-9, 2000 in San Jose, California. Connectathon, sponsored by Sun Microsystems, Inc., hosts nearly 30 companies annually in an effort to test and debug source code which utilize the following technologies and protocols: NFS versions 2, 3 and 4 NFS over TCP WebNFS Lock Manager NIS/NIS+/DNS TI-RPC Kerberos Automounter IPv6 DHCP LDAP Gigabit Ethernet Based on demand, in addition we are considering to offer: NFS over IPv6 RPC over IPv6 Service Location Protocol IPsec Mobile IPv4 If you are interested in testing any of the above 5 protocols, please send a note to Cthon@Sun.COM and we'll gauge interest. Or if you have a suggestion for another technology, feel free to contact us as well. Testing continues 24 hours per day. Technology testing coordinators will organize testing procedures and test suite material. In addition, there will be seminars with speakers addressing various topics. The registration deadline is February 14, 2000. An Early Bird Discount on booth fees is available to those who register and pay by December 31, 1999. For registration information, please see our web site at http://www.connectathon.org. If you have any questions, please feel free to contact Audrey Van Belleghem at audrey@vanb.com or (408) 358-9598. We look forward to seeing you at the 14th annual Connectathon event! Audrey Van Belleghem Connectathon Manager Mike Carney SNT Internet Engineering Sun Microsystems, Inc. Mailstop UBUR02-212 One Network Drive Burlington, MA 01803 From dhcp-v4@bucknell.edu Mon Oct 11 12:46: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 MAA08860 for ; Mon, 11 Oct 1999 12:46: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 MAA12962; Mon, 11 Oct 1999 12:44:06 -0400 (EDT) Date: Mon, 11 Oct 1999 12:44:06 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: Michael.Carney@East.Sun.COM Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Mike Carney - SNT Internet Engineering To: Multiple recipients of list Subject: Connectathon '00 Announcement X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Mime-Version: 1.0 Hi Folks, Connectathon testing for DHCP will be held in March on the 6th through the 8th (that's monday through wednesday). If you'd be interested in volunteering as DHCP technology coordinator for this connectathon, please let Audrey and me know. I've been doing this for 4 years, and I'd like to give someone else an opportunity to lead the testing. Connectathon is vendor-neutral, so any implementor is welcome to volunteer. If you have items you'd like to see tested for this session (such as DHCPv6 or server-to-server) send them along! Here's the official announcement: Plans for Connectathon 2000 are already under way! The 14th annual Connectathon event, an interoperability testing event for engineers only, will be held March 2-9, 2000 in San Jose, California. Connectathon, sponsored by Sun Microsystems, Inc., hosts nearly 30 companies annually in an effort to test and debug source code which utilize the following technologies and protocols: NFS versions 2, 3 and 4 NFS over TCP WebNFS Lock Manager NIS/NIS+/DNS TI-RPC Kerberos Automounter IPv6 DHCP LDAP Gigabit Ethernet Based on demand, in addition we are considering to offer: NFS over IPv6 RPC over IPv6 Service Location Protocol IPsec Mobile IPv4 If you are interested in testing any of the above 5 protocols, please send a note to Cthon@Sun.COM and we'll gauge interest. Or if you have a suggestion for another technology, feel free to contact us as well. Testing continues 24 hours per day. Technology testing coordinators will organize testing procedures and test suite material. In addition, there will be seminars with speakers addressing various topics. The registration deadline is February 14, 2000. An Early Bird Discount on booth fees is available to those who register and pay by December 31, 1999. For registration information, please see our web site at http://www.connectathon.org. If you have any questions, please feel free to contact Audrey Van Belleghem at audrey@vanb.com or (408) 358-9598. We look forward to seeing you at the 14th annual Connectathon event! Audrey Van Belleghem Connectathon Manager Mike Carney SNT Internet Engineering Sun Microsystems, Inc. Mailstop UBUR02-212 One Network Drive Burlington, MA 01803 From dhcp-v4@bucknell.edu Tue Oct 12 08:07: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 IAA10855 for ; Tue, 12 Oct 1999 08:06:59 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA18544; Tue, 12 Oct 1999 08:06:20 -0400 (EDT) Date: Tue, 12 Oct 1999 08:06:20 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: Internet-Drafts@ietf.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Internet-Drafts@ietf.org (by way of Ralph Droms ) To: Multiple recipients of list Subject: I-D ACTION:draft-schrijvp-dhcpv4-reconfigure-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 FYI; we'll have a chance to discuss this draft at the WG meeting in DC... - Ralph ===== A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Dynamic host configuration : DHCP reconfigure extension Author(s) : P. De Schrijver, Y. T'Joens Filename : draft-schrijvp-dhcpv4-reconfigure-00.txt Pages : 5 Date : 08-Oct-99 This draft defines extensions to DHCP [DHCP] to allow dynamic reconfiguration of a single host with a new IP address. This is achieved by introducing a unicast DHCP FORCERENEW message which forces the client to the RENEW state. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schrijvp-dhcpv4-reconfigure-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-schrijvp-dhcpv4-reconfigure-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-schrijvp-dhcpv4-reconfigure-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19991008135911.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-schrijvp-dhcpv4-reconfigure-00.txt From dhcp-v4@bucknell.edu Tue Oct 12 13:27: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 NAA22279 for ; Tue, 12 Oct 1999 13:27:59 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA15475; Tue, 12 Oct 1999 13:24:22 -0400 (EDT) Date: Tue, 12 Oct 1999 13:24:22 -0400 (EDT) Message-Id: <63D30D6E10CFD11190A90000F805FE8601CE6F67@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: I-D ACTION:draft-schrijvp-dhcpv4-reconfigure-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain X-Mailer: Internet Mail Service (5.0.1460.8) Mime-Version: 1.0 Hello, IMHO, the new option is long overdue, cheers! Comments: 1) The specific implementation chosen could be a bit simplified: We could send an option to the client, which, upon receipt (if understood and accepted), causes it to go directly into INIT state. Why not? This is what we are ultimately trying to accomplish right? The DHCPDISCOVER serves as "ack" for the message. If we are concerned with the occasional need to give the client the same address, we can do that in response to a DHCPDISCOVER as well. Should the message work this way, it probably needs to be called FORCEINIT. 2) It would be also useful to introduce a new client option, to flag clients who are capable of receiving FORCE(WHATEVER-YOU-END-UP-CALLING-IT) messages. I would put it into the DHCPDISCOVER messages, and a compliant server should track/flag such clients. This is to avoid : a)Generating unnecessary traffic while we are trying to send this to a client who does not understand the option. b)Possibly crashing a poorly implemented client who does not understand the option. (The downside: we could crash a poorly implemented server, that does not understand the new client option. ;-) Good work! sG From dhcp-v4@bucknell.edu Wed Oct 13 10:11:43 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24783 for ; Wed, 13 Oct 1999 10:11:43 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA00816; Wed, 13 Oct 1999 10:10:32 -0400 (EDT) Date: Wed, 13 Oct 1999 10:10:32 -0400 (EDT) Message-Id: <19991013155108.A1180@rc.bel.alcatel.be> Errors-To: droms@bucknell.edu Reply-To: schrijvp@rc.bel.alcatel.be Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: De Schrijver Peter To: Multiple recipients of list Subject: Re: I-D ACTION:draft-schrijvp-dhcpv4-reconfigure-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Mutt 0.95.5i Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Hello, > Hello, > > IMHO, the new option is long overdue, cheers! > > Comments: > > 1) The specific implementation chosen could be a bit simplified: > We could send an option to the client, which, upon receipt (if understood > and accepted), causes it to go directly into INIT state. > > Why not? This is what we are ultimately trying to accomplish right? The > DHCPDISCOVER serves as "ack" for the message. > > If we are concerned with the occasional need to give the client the same > address, we can do that in response to a DHCPDISCOVER as well. Should the > message work this way, it probably needs to be called FORCEINIT. > We thought on this approach, but decided to have the client explicitly contact the server, to have at least some protection against rogue RECONFIGURE messages. I realize an attacker could of course also spoof the server replies... > 2) It would be also useful to introduce a new client option, to flag clients > who are capable of receiving FORCE(WHATEVER-YOU-END-UP-CALLING-IT) messages. > I would put it into the DHCPDISCOVER messages, and a compliant server should > track/flag such clients. > > This is to avoid : > a)Generating unnecessary traffic while we are trying to send this to a > client who does not understand the option. > b)Possibly crashing a poorly implemented client who does not understand the > option. (The downside: we could crash a poorly implemented server, that does > not understand the new client option. ;-) > > That's indeed a good idea, also for possible future extensions. > Good work! Thanks. Cheers, Peter. From dhcp-v4@bucknell.edu Wed Oct 13 13: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 NAA01170 for ; Wed, 13 Oct 1999 13:50:43 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA31305; Wed, 13 Oct 1999 13:49:04 -0400 (EDT) Date: Wed, 13 Oct 1999 13:49:04 -0400 (EDT) Message-Id: <63D30D6E10CFD11190A90000F805FE8601CE6F6B@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: I-D ACTION:draft-schrijvp-dhcpv4-reconfigure-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain X-Mailer: Internet Mail Service (5.0.1460.8) Mime-Version: 1.0 >> 1) The specific implementation chosen could be a bit simplified: >> We could send an option to the client, which, upon receipt (if understood >> and accepted), causes it to go directly into INIT state. --snip-- >We thought on this approach, but decided to have the client explicitly contact >the server, to have at least some protection against rogue RECONFIGURE messages. >I realize an attacker could of course also spoof the server replies... Un-authenticated DHCP is not a secure protocol. It is arguable whether the extra bit of protection is worth the extra message traffic. IMHO it is not, others may disagree. There is no way around making both server and client modifications for this protocol. Given that, you could solve the rogue message problem via authenticated DHCP, and choose the simpler solution. sG From dhcp-v4@bucknell.edu Wed Oct 13 15:09:07 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02457 for ; Wed, 13 Oct 1999 15:09: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 PAA31699; Wed, 13 Oct 1999 15:07:33 -0400 (EDT) Date: Wed, 13 Oct 1999 15:07:33 -0400 (EDT) Message-Id: <3804CF33.A038F7B@metaip.checkpoint.com> Errors-To: droms@bucknell.edu Reply-To: richardj@metaip.checkpoint.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Richard Jones To: Multiple recipients of list Subject: Re: I-D ACTION:draft-schrijvp-dhcpv4-reconfigure-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.6 [en] (WinNT; U) Content-Transfer-Encoding: 7bit Like Steve, this draft looks like a good thing to me. It brings up a question I've wondered about, and would ask anyone with more experience in the dhc working group than me to comment on: What (if any) are the differences in implication between a change in the protocol that requires server implementors to alter server behavior, and a change that requires client implementors to alter client behavior? If there are differences, has this had an impact on the strategies for protocol changes (other than requiring graceful handling of elements that don't deal with the changes)? Regards, Richard De Schrijver Peter wrote: > We thought on this approach, but decided to have the client explicitly contact > the server, to have at least some protection against rogue RECONFIGURE messages. > I realize an attacker could of course also spoof the server replies... Steve Gonczi wrote: > > Un-authenticated DHCP is not a secure protocol. > It is arguable whether the extra bit of protection is worth the extra > message traffic. > IMHO it is not, others may disagree. > > There is no way around making both server and client modifications for > this protocol. > Given that, you could solve the rogue message problem via authenticated > DHCP, and choose the simpler solution. > > sG From dhcp-v4@bucknell.edu Wed Oct 13 15:10: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 PAA02493 for ; Wed, 13 Oct 1999 15:10: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 PAA07715; Wed, 13 Oct 1999 15:10:09 -0400 (EDT) Date: Wed, 13 Oct 1999 15:10:09 -0400 (EDT) Message-Id: <199910131851.OAA03201@grosse.manhattan.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: I-D ACTION:draft-schrijvp-dhcpv4-reconfigure-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 When you are thinking about this idea of a server-originating message that causes a client to reconfigure, please think carefully about how this affects the DHCP threat model. This change makes a big difference to the threat model. With current DHCP, the threats are: a rogue server can feed a client incorrect information, a rogue server can prevent a client from acquiring or renewing a lease, and a rogue client can in various ways cause a server that is doing dynamic address allocation to deplete its address pool, preventing legitimate clients from getting addresses from the server. This means that the opportunities to deny service to a client occur at relatively infrequent times in a normal configuration - when the client first powers on, and whenever it renews. Also, DoS attacks against servers don't have any amplification - you just have one attacker doing it, which is relatively easy to track down - the DoS packets the server sees are actually coming from the attacker. Now consider what happens if you add a server-sourced reconfiguration packet, without DHCP authentication. First of all, clients are _always_ vulnerable to attack, not just at certain points. If I want to hijack a client's TCP connection, I can send it a reconfigure message at a crucial time and *prevent* it from using its address. This means I can hijack its TCP connections and, by cleverly blocking its use of the DHCP protocol, prevent it from repudiating my continuation of its TCP streams, because it won't be able to use its IP address and probably won't even see the usurped stream coming back from the server. This changed window of opportunity has, IMHO, severe security implications. But let's forget about that for a moment. What if we just want to kill the DHCP server, so that we can do something nefarious without it noticing? What if we want to do this indirectly, in such a way that packets originating from our machine never hit the server? No problem. Sit around passively snooping DHCP traffic for a while, and get a list of all the clients. Then send out messages to every client, all at once, telling them to reconfigure. Instantly, the DHCP server is under extreme load, all of which is coming from *legitimate* clients! I would argue that this reconfigure message changes the DHCP threat model sufficiently that we should not just handwave about the security implications. If any draft like this is going to advance in the working group, I think it has to *require* that conforming clients and servers implement the DHCP authentication protocol or some similar protocol. The reconfigure message should also probably include a requirement that a client stack receiving and executing a reconfigure message should cleanly shut down all of its persistent connections (essentially, TCP connections) before reconfiguring. Comments? _MelloN_ From dhcp-v4@bucknell.edu Wed Oct 13 16:58:31 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04270 for ; Wed, 13 Oct 1999 16:58:31 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA01992; Wed, 13 Oct 1999 16:57:37 -0400 (EDT) Date: Wed, 13 Oct 1999 16:57:37 -0400 (EDT) Message-Id: <2D97764EC014D311BFD5006094A3E712027A9675@honts326.homeoffice.wal-mart.com> Errors-To: droms@bucknell.edu Reply-To: dblane@wal-mart.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Diana Lane To: Multiple recipients of list Subject: RE: ddns and failover protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; X-Mailer: Internet Mail Service (5.5.2650.21) Mime-Version: 1.0 -----Original Message----- From: David Erdmann [SMTP:derdmann@nortelnetworks.com] Sent: Wednesday, October 06, 1999 9:00 AM To: Multiple recipients of list Subject: RE: ddns and failover protocol Hi David, I have attempted to comment inline. I have absolutely no idea what Outlook is going to do with this message; so far I see about four different kinds of quoting mechanisms in this! So, please bear with me. I am better with plain old UNIX "mail!" > While it is important for the DHCP server's dynamic updates to be > processed, > it is possible for those updates to stack up to the point where > they become > more of a problem than if they had simply been dropped in the first place. > Consider the case of a fairly lengthy outage with many clients hitting the > backup server (RENEWs, a storm of DISCOVERs, etc.) Add to that volume of > requests to be processed the backlog of DNS updates and it may be that the > backup becomes so busy updating DNS that it, too, falls behind on serving > clients. At some point, a certain percentage of the incomplete > DNS updates > may become outdated as the IP addresses involved are assigned to > new clients. There should be some exponential back-off for trying DDNS updates. If people have DDNS turned on, then I can only assume that they are interested in the DNS server getting updated. I don't think that it is safe to assume that we can just drop DNS updates. I do agree however that we should consider the performance implications. When you assign an address to a new client you should be cancelling the previous DNS update, and trying to update the new address. > I think the idea of preserving some of the DNS updates yet to be > performed is > good, but perhaps they should be dropped either after a certain > period of time > (at what point should they become "stale?") or when server load reaches a * certain percent of "maximum capacity." * By "stale" I meant the following situation (seen with certain print servers...): * Client receives a lease * DHCP server is unable to update DNS server * Client is reconfigured and drops to DISCOVER * Client receives a new IP address (not sure if it sends a DHCPRELEASE before it DISCOVERs) * DHCP server queues a new set of updates for Client * ...etc. * First set of updates (still unsent) is "stale." If DHCP is the only way of updating DNS servers I would be wary of expiring DNS updates (of course after the lease expires we should stop). As for server load reaching a certain maximum, I agree that it would be a good idea for a server to not do too many simultaneous updates, and queue the updates...I don't think that we should be dropping the updates altogether. > IP addresses for existing clients > will tend to remain constant, so DNS records pertaining to those > clients will > be unnecessary. Perhaps the backup should only update records for those > clients that start out at DISCOVER, not for those RENEWing > existing leases. Perhaps a refinement of this idea would be to only do a DNS update if the DHCP server is handing out a new address. Thus if we already know that this client has a specific IP and we hand out the same IP again to the same client, we do not have to update DNS. Yes, I like that idea. That is more along the lines of what I was trying to express; sometimes I seem to have trouble conveying what I mean. I would not like to see updates dropped for clients who have changed their IP address or domain, but at the same time if the client has renewed its lease on the same IP address three times, there should not need to be three sets of DNS updates. > > Diana Lane > Wal-Mart Stores > dblane@wal-mart.com -Dave ---------------------------------- Dave Erdmann Nortel Networks, NetID Group mailto:derdmann@nortelnetworks.com From dhcp-v4@bucknell.edu Wed Oct 13 17:01:31 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04424 for ; Wed, 13 Oct 1999 17:01:31 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA00067; Wed, 13 Oct 1999 17:00:34 -0400 (EDT) Date: Wed, 13 Oct 1999 17:00:34 -0400 (EDT) Message-Id: <63D30D6E10CFD11190A90000F805FE8601CE6F6D@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: I-D ACTION:draft-schrijvp-dhcpv4-reconfigure-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain X-Mailer: Internet Mail Service (5.0.1460.8) Mime-Version: 1.0 >If any draft like this is going to advance in the >working group, I think it has to *require* that conforming clients and >servers implement the DHCP authentication protocol or some similar >protocol. >The reconfigure message should also probably include a >requirement that a client stack receiving and executing a reconfigure >message should cleanly shut down all of its persistent connections >(essentially, TCP connections) before reconfiguring. Yes, both of Ted's suggestions seem very reasonable. sG From dhcp-v4@bucknell.edu Wed Oct 13 18:37: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 SAA05554 for ; Wed, 13 Oct 1999 18:37: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 SAA30823; Wed, 13 Oct 1999 18:37:02 -0400 (EDT) Date: Wed, 13 Oct 1999 18:37:02 -0400 (EDT) Message-Id: <009DF92D.6B9B38E9.6@process.com> Errors-To: droms@bucknell.edu Reply-To: volz@process.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Bernie Volz To: Multiple recipients of list Subject: RE: I-D ACTION:draft-schrijvp-dhcpv4-reconfigure-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Ted/Steve: I agree that this opens up significant threats. There are some things that COULD be used to reduce the threat: - Only allow these message to originate from a unicast address. That way, you can't cause an entire subnet to reconfigure. You could even require that this comes from the server that assigned the address, but that does cause issues for the Failover protocol and may have other problems. Even with this restriction, the failover issue can be dealt with if you have both servers send the DHCPFOCE messages to all the clients of interest (since the address was assigned by one of these servers, it will happen). This does mean both servers in the pair need to be up, but that's likely OK. Yes, someone could always send a media-layer broadcast with a unicast address as the destination IP address so that isn't that much more secure. However, most socket implementations don't tell you the destination address, only the source on a recvfrom. So, this may have little value and not be possible to implement. (Perhaps most DHCP Clients don't use sockets?) - The Client is, in the draft, asked to enter RENEW. This has 3 results: - NAK from server; go to INIT. - ACK from server; continue using address. - No response; keep trying or wait until T1/T2 times This seems to me that it requires sending both a DHCPFORCE and then hijacking the server. Note also that the state change in the draft is like the T1 expires time. So,the client can continue to use the address until it gets a NAK. - To reduce the potential burden on the server, using unicast messages means that the server can control the client rate. But, to avoid the potential threat if DHCPFORCE was broadcast, have the clients wait a random interval (say up to 60 seconds?) before renewing. This reduces the burden on the server as it spreads out the load. - And, build an anti-spoofing algorithm into the client. If the client receives a DHCPFORCE and hears back from the server (either a NAK or ACK), prevent it from processing any further DHCPFORCEs for a period of time (say 5 minutes). This does mean you can't reconfigure more often than once every 5 minute, but is that really needed? Agreed that NONE of these eliminate the threat and the only solution is to use some kind of authentication (DHCP authentication per the draft). And, if authentication is used, some of the restrictions could be dropped (such as not allowing 2 DHCPFORCEs within a period of time). - Bernie Volz Process Software >>If any draft like this is going to advance in the >>working group, I think it has to *require* that conforming clients and >>servers implement the DHCP authentication protocol or some similar >>protocol. > >>The reconfigure message should also probably include a >>requirement that a client stack receiving and executing a reconfigure >>message should cleanly shut down all of its persistent connections >>(essentially, TCP connections) before reconfiguring. > >Yes, both of Ted's suggestions seem very reasonable. > >sG From dhcp-v4@bucknell.edu Thu Oct 14 09:32: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 JAA29877 for ; Thu, 14 Oct 1999 09:32:29 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA01433; Thu, 14 Oct 1999 09:31:32 -0400 (EDT) Date: Thu, 14 Oct 1999 09:31:32 -0400 (EDT) Message-Id: <199910141231.IAA05935@grosse.manhattan.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: I-D ACTION:draft-schrijvp-dhcpv4-reconfigure-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Only allow these message to originate from a unicast address. That > way, you can't cause an entire subnet to reconfigure. You mean don't allow a message to be sent to the broadcast address? Okay, but I can still send flood the net with reconfigure messages and create massive congestion. WRT validating the source address as being from the server, this is trivially forgeable, so it really makes no difference. > This seems to me that it requires sending both a DHCPFORCE and > then hijacking the server. Yes, but the timing is the difference. Before, you had to wait for the client to change state, and then attack. Now you can attack when it's convenient - for example, when you observe the client starting a session that would be profitable to compromise. > Note also that the state change in the draft is like the T1 expires > time. So,the client can continue to use the address until it gets a NAK. Right, but it's sensitive to a NAK after receiving the DHCPFORCE, whereas it was not sensitive to a NAK prior to receiving a DHCPFORCE, so the situation is indeed different with DHCPFORCE than without. > To reduce the potential burden on the server, using unicast messages > means that the server can control the client rate. No, it does not mean this. It is still possible for an attacker to cause all clients to reinitialize at once. > But, to avoid the potential threat if DHCPFORCE was broadcast, have > the clients wait a random interval (say up to 60 seconds?) before > renewing. This reduces the burden on the server as it spreads out > the load. This is a good idea, and will help if implemented. > And, build an anti-spoofing algorithm into the client. If the client > receives a DHCPFORCE and hears back from the server (either a NAK or > ACK), prevent it from processing any further DHCPFORCEs for a period of > time (say 5 minutes). This does mean you can't reconfigure more often > than once every 5 minute, but is that really needed? How does this help? > Agreed that NONE of these eliminate the threat and the only solution is > to use some kind of authentication (DHCP authentication per the draft). Right. I do not believe we should advance the draft if it does not *require* authentication. _MelloN_ From dhcp-v4@bucknell.edu Thu Oct 14 11:33: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 LAA04517 for ; Thu, 14 Oct 1999 11:33: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 LAA01531; Thu, 14 Oct 1999 11:31:28 -0400 (EDT) Date: Thu, 14 Oct 1999 11:31:28 -0400 (EDT) Message-Id: <4.2.0.58.19991014104350.015aac70@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: DHCP failover conference call re: Dynamic DNS and Failover 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.2.0.58 There will be a last failover conference call today at 12 (noon) EDT concerning failover and dynamic DNS. Let me know you are interested in attending. Cheers -- Kim From dhcp-v4@bucknell.edu Thu Oct 14 14:13: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 OAA09904 for ; Thu, 14 Oct 1999 14:13:17 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA21665; Thu, 14 Oct 1999 13:23:57 -0400 (EDT) Date: Thu, 14 Oct 1999 13:23:57 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: derdmann@nortelnetworks.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "David Erdmann" To: Multiple recipients of list Subject: ddns Key RR question X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Hi, I have a basic question about the ddns-update and the Key Resource Record. According to the draft "draft-ietf-dhc-dhcp-dns-10.txt" it mentions storing the client ID in a Key RR. Is the use of the Key RR a must for the A and PTR RRs? Or this a suggestino for cooperating DHCP servers? -Dave ---------------------------------- Dave Erdmann Nortel Networks, NetID Group mailto:derdmann@nortelnetworks.com From dhcp-v4@bucknell.edu Fri Oct 15 12:36:31 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16897 for ; Fri, 15 Oct 1999 12:36:29 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA00065; Fri, 15 Oct 1999 12:34:13 -0400 (EDT) Date: Fri, 15 Oct 1999 12:34:13 -0400 (EDT) Message-Id: <199910151630.MAA10350@grosse.manhattan.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: ddns and failover protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 >> Perhaps a refinement of this idea would be to only do a DNS update if the >> DHCP server >> is handing out a new address. Thus if we already know that this client has >> a specific >> IP and we hand out the same IP again to the same client, we do not have to >> update >> DNS. > > Yes, I like that idea. That is more along the lines of what I > was trying to express; sometimes I seem to have trouble conveying > what I mean. I would not like to see updates dropped for clients > who have changed their IP address or domain, but at the same time if > the client has renewed its lease on the same IP address three times, > there should not need to be three sets of DNS updates. The ISC DHCP server (version 3.0) actually performs dynamic updates this way currently - the DDNS update information is stored in the lease database, and if a new lease assignment does not change the information, no update is attempted. Tragically, I think this could become difficult to do with failover, because there is no way for the DHCP servers to be absolutely certain anymore that a lease has in fact expired. This probably got talked about yesterday - I'm sorry I didn't make it to the meeting. :'( _MelloN_ From dhcp-v4@bucknell.edu Fri Oct 15 19:15: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 TAA22971 for ; Fri, 15 Oct 1999 19:15: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 TAA23640; Fri, 15 Oct 1999 19:14:20 -0400 (EDT) Date: Fri, 15 Oct 1999 19:14:20 -0400 (EDT) Message-Id: <4.2.0.58.19991015161014.00a04100@mail.join.com> Errors-To: droms@bucknell.edu Reply-To: robs@join.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Rob Stevens To: Multiple recipients of list Subject: Re: ddns and 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"; format=flowed Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 At 12:36 PM 10/15/99 -0400, Ted Lemon wrote: >The ISC DHCP server (version 3.0) actually performs dynamic updates >this way currently - the DDNS update information is stored in the >lease database, and if a new lease assignment does not change the >information, no update is attempted. Tragically, I think this could >become difficult to do with failover, because there is no way for the >DHCP servers to be absolutely certain anymore that a lease has in fact >expired. This probably got talked about yesterday - I'm sorry I >didn't make it to the meeting. :'( > > I was interested to read this, because for quite a while we have been doing this also. We track locally the (name,IP,MAC) triple. We always avoid trying to update DNS whenever possible because of the expense. I would not like to see all this go out of the window with failover. I was glad to see that in the failover protocol the authors had allowed for sending ip-name binding info, but I'm also concerned about the question of servers having different ideas about the lease expiration. Any desire to make DNS records have SIGs which expire with the DHCP lease is more difficult. I think that to make this work efficiently quite a bit more effort will need to be expended on discussing dynamic DNS-DHCP. From dhcp-v4@bucknell.edu Mon Oct 18 17:44:40 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19935 for ; Mon, 18 Oct 1999 17:44: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 QAA12931; Mon, 18 Oct 1999 16:59:13 -0400 (EDT) Date: Mon, 18 Oct 1999 16:59:13 -0400 (EDT) Message-Id: <4.2.0.58.19991018155725.015d5670@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: Minutes of 3rd and last Failover conference call 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.2.0.58 Last Thursday, we held the last of three conference calls concerning the current failover protocol draft. This last meeting was reasonably well attended, and we considerable progress. Thanks to all of you who attended this call. The roster of attendees is at the end of this mail, as is a list of action items for people from the various calls. Cheers -- Kim -------------------------------------------------------------- Minutes from the 10/14/99 Failover conference call. The last failover conference call again had good attendance, though some couldn't make it for this call. The agenda was to discuss Dynamic DNS and how it should be handled by a failover servers. We added several additional agenda items: how to handle pinging by failover servers, reservations and dynamic BOOTP and failover, and how to get the draft revised by the deadline. Old Business ------------ I forgot to put in the minutes from the 2nd failover conference call that I would be collecting "interesting" scenarios for the failover protocol, and would try to respond to them as to how the failover protocol will handle them. If, at some point, someone wants to edit them into an informational draft, I'll give them everything I've save. Perhaps I will get to it before someone else does. Dynamic DNS and Failover ------------------------ Mark Stapp (the current lead author of the DHCP-DNS draft) kicked off the discussion of dynamic DNS and failover by discussing the approach in the -04 failover draft, and proposing a change. His proposal was to not use a re-constituted version of the client-fqdn option (described in the DHCP-DNS draft) but rather to use a special purpose option which carries just the information required by two failover servers. Mark asked which server writers used Dynamic DNS, and got back the following list of people (I think -- please correct me if I'm wrong): Rob Stevens Richard Jones Bernie Volz David Erdmann Alok Joshi Andre Kostur Mark Stapp Rob Stevens then suggested that dynamic DNS was just another complication in the failover draft, and that we should handle it in another draft that could be associated with the failover draft. After some discussion on this topic, Kim Kinnear asked for a virtual show of hands for people that agreed with Rob, and didn't find anyone else that thought that we should move the integration of dynamic DNS and failover off to a separate draft. Rob suggested that at least the use of dynamic DNS options should be a MAY in the draft and not a SHOULD. Kim suggested that we see what the actual support requires and then deal with that question after the next revision. We then talked about what the general nature of support for dynamic DNS would look like, yielding the following general rules: 1. When a server gets a name from a client and intends to do dynamic DNS updates, it should send the information to its partner in the new option that Mark will specify. It can send this information before it does the DNS add and again after, or just wait until it has done the DNS operation and send it after. The option has flags to indicate whether the operation has been completed or not. 2. A server doesn't do a DNS operation on an expiring lease unless that server is responsive to that DHCP client (e.g., a secondary server doesn't do DNS operations if it is in NORMAL state). 3. A server MUST NOT remove a name from DNS until a lease becomes available to the server to reallocate to another client. Thus, when a server enters partner-down state, it doesn't remove a DNS name for a lease when the lease expires, but only after the lease expires and the MCLT has passed beyond expiration (which is when the lease also becomes FREE). 4. A server can allow the client to process its on DNS A record or not, but it must communicate that as part of the DNS information to the other server. Kim brought up the issue about servers that can be configured to support the "first name wins" strategy of dynamic DNS, where the first DHCP client to present a name gets that name, and later clients get a different name (known by some as a disambiguated name). In this style of dynamic DNS support by DHCP (which is only one of the several styles listed in the DHCP-DNS draft), it is important for the server to be able to detect when the client's name changes. In order to detect this, the server must keep the name that the client originally presented as well as the name that the server put into DNS for the client. If this is to work over failover, the server who puts the name into DNS must send *both* names to the other server. Kim proposed an extension to the new DDNS option that Mark will propose to hold this information. Bernie Volz then suggested that a generalized extension to the failover protocol could be used to solve this (and other) problems. The generalized extension would be a container-style option (reminiscent of the vendor-supplied-options option) could be used to send over to the failover partner all of the "interesting" options that the DHCP client sent in. This could include the host-name or client-fqdn option, solving Kim's problem of sensing the name change, but also it could include the relay-agent-option (among others), in a general way. Kim said that, following that line of thought, what about another container which would include the "interesting" options that the DHCP server sent to the DHCP client (e.g., the renewal and rebinding times are something that can't directly be calculated with any certainty by the partner server, since in a failover server they are based on knowledge of what the partner server knows). Bernie said sure. After some discussion, we agreed on two new options, one for the interesting client input options and one for the interesting client output options. The list of *interesting* options would be given and refined over time in the draft, and new options would be requested to define if they were "interesting" to a failover partner server. All of this would be a SHOULD or MAY in the draft. The format of the options in the container was discussed, and we decided on a format similar to the options area, with a magic-number as the first 4 bytes, and then a free-form options area. This way, can support the older ?R5? options as well the newer ?R6? expanded style options. Bernie said that a binding update only sends difference information, as a response to Kim's question as to whether a server had to save all of the incoming DHCP client options forever to as to be able to send them in every binding update. Kim agree with Bernie that you didn't have to send them every time, and that he would update the draft to indicate that binding updates only send different information. Rob brought up what about a failover partner that sends the these options for a while and then stops -- that would be allowed by a MAY or SHOULD in the draft. Ralph Droms discussed the general sense of what a MAY or SHOULD should mean. Mark read us the exact words from the defining draft, and Kim agreed to put some text in the failover draft suggesting that a server might or might not send these options, but that it SHOULD be consistent in doing it one way or the other (at least without configuration information to the contrary). With these additions to the general protocol, Kim said that his issue with name change determination was solved. The last discussion was about when should a failover partner B do a DNS update when it notices that it wasn't done by the other server A and when B becomes responsive for those clients. We identified two approaches: 1. Begin to update all dynamic DNS names that are not listed as currently up-to-date as a sort of background process. 2. Update dynamic DNS names upon next client contact if they are not listed as currently up-to-date when a client next renews. Either would be acceptable. Pinging by Failover Servers --------------------------- Rob Stevens brought up the issue of pinging by DHCP server, and what to do with this issue in a failover context. Kim mentioned that there is a special state (ABANDONED) in the failover draft which is used to communicate that a server has determined that an IP address is in some sort of unrepairable state and should not be used. Rob discussed what server do when pinging in general, and most (some, many?) server writers agreed that when a client DISCOVER's and it already has a lease for an IP address, that they don't ping. Rob mentioned that at one point they didn't do that -- i.e., they *did* ping, but that turned out to be a problem for both DISCOVER's, but even more so for BOOTP requests that were handled as dynamic BOOTP requests. Generally, from a failover standpoint, pinging only when an IP address was currently believed to be unused by any client was considered a good idea. However, this topic caused Kim to bring up reservations and dynamic BOOTP and failover. Reservations and Failover ------------------------- Reservations are a situation where a particular IP address is "reserved" for only a specific DHCP client. The client still uses DHCP, but gets only a particular IP address whenever it DISCOVER's. In a traditional two server DHCP environment, each server has to have a disjoint set of addresses for allocation, except that they have to have *identical* lists of reservations. In a failover situation, each server needs to be able to hand out a reserved lease. Kim discussed one approach, which is to have each server see these IP addresses as available locally. While this can work, Bernie suggested that perhaps a new state of FREE-RESERVED might be used to indicate a reserved lease. This is fine, but it gets lost as part of the normal lease process. One approach is to simply have each server to "know" which leases are reserved -- and that is fine, but there are synchronization holes if a reservation is made while the servers are running, and they become aware of the new configuration (i.e., the new reservations) at different times. Kim said that he would try to handle this in the revision of the draft, and people could see how they liked it. Dynamic BOOTP and Failover -------------------------- Kim also brought up the dynamic BOOTP case, and mentioned that the only way that he had seen to handle it was to never actually use the other servers IP addresses, even in partner down, when using a range of addresses that support dynamic BOOTP. The reason for this is that "BOOTP is forever", and that the MCLT has no meaning in a situation where a server is doing dynamic BOOTP. In this case, there are obvious benefits to sequestering the addresses available for dynamic BOOTP in a small address range. How to get the next draft completed: ----------------------------------- Kim said that this was the list (moderately large) changes scheduled for the next draft revision (-05): 1. Security section: Bernie Volz (received as of 10/18). 2. SASL information: Ted Lemon. 3. DDNS option proposal: Mark Stapp. 4. Conflict Resolution proposal: Kim Kinnear. 5. State transition diagram for IP addresses: Kim Kinnear. 6. New failover endpoint state for communications interruption during conflict resolution: Kim Kinnear. 7. How to handle reservations proposal: Kim Kinnear. 8. Information on how to handle dynamic BOOTP: Kim Kinnear 9. General updates (many small ones): Kim Kinnear ---------------------------------------------------------- The attendees at this meeting were: Tawei Chen Merrill Lynch EDT tawei_chen@ml.com Ralph Droms Bucknell U. EDT droms@bucknell.com David Erdmann Nortel Networks EDT derdmann@nortelnetworks.com Steve Gonczi Process Software EDT gonzci@process.com Todd Goodyear Merrill Lynch EDT tod_goodyear@ml.com Richard Jones Checkpoint Software PDT richardj@metaip.checkpoint.com Alok Joshi Merrill Lynch EDT alok_joshi@ml.com Kim Kinnear Cisco Systems EDT kkinnear@cisco.com Andre Kostur Incognito PDT andre@incognito.com Diana Lane Wal-Mart Stores CDT dblane@wal-mart.com Greg Rabil Lucent Technologies EDT agrabil@quadritek.com Harry Roberts Merrill Lynch EDT harry_roberts@ml.com Mark Stapp Cisco Systems EDT mjs@cisco.com Rob Stevens Join Systems PDT robs@join.com Bernie Volz Process Software EDT volz@process.com From dhcp-v4@bucknell.edu Tue Oct 19 07:47: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 HAA10403 for ; Tue, 19 Oct 1999 07:47: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 HAA08372; Tue, 19 Oct 1999 07:45:50 -0400 (EDT) Date: Tue, 19 Oct 1999 07:45:50 -0400 (EDT) Message-Id: <199910191122.HAA17415@uplink.net> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: I-D ACTION:draft-ietf-dhc-nsso-01.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The Name Service Search Option for DHCP Author(s) : C. Smith Filename : draft-ietf-dhc-nsso-01.txt Pages : 4 Date : 18-Oct-99 This document defines a new DHCP option which is passed from the DHCP Server to the DHCP Client to specify the order in which name services should be consulted when resolving hostnames and other information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-nsso-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-nsso-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-nsso-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19991018121625.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-nsso-01.txt From dhcp-v4@bucknell.edu Tue Oct 19 08:32: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 IAA12415 for ; Tue, 19 Oct 1999 08:32: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 IAA25972; Tue, 19 Oct 1999 08:31:43 -0400 (EDT) Date: Tue, 19 Oct 1999 08:31:43 -0400 (EDT) Message-Id: <199910191223.IAA00738@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: DHCP and Internet Access 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 PQUIST@WILCO-INT.COM follows. --------------------------------------------------------------------- Hi - I am currently setting up a DHCP server for what will be around 500 clients. Circa 100 of which are considered "trusted clients" and have been granted Internet Access via their IP address thru the firewall. What I need to know is this - Is it possible to configure a Solstice Firewall to grant access to the Internet via recognising a trusted machine name, or does it need to operate via the IP address? If we cannot change the firewall, is there anyway we can reserve a bank of IPs on the DHCP server to allocate to certain machine names? Thanks James Herbert Internal Systems Wilco International Ltd ---------------------------------------------------------------------------- ---- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the materialfrom any computer. ---------------------------------------------------------------------------- ---- ---------------------------------------------------------------------------- ---- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the materialfrom any computer. ---------------------------------------------------------------------------- ---- From dhcp-v6@bucknell.edu Tue Oct 19 11:40:28 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22807 for ; Tue, 19 Oct 1999 11:40:27 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA09449; Tue, 19 Oct 1999 11:34:50 -0400 (EDT) Date: Tue, 19 Oct 1999 11:34:50 -0400 (EDT) Message-Id: <199910191521.LAA27423@mail.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v6@bucknell.edu Sender: dhcp-v6@bucknell.edu Precedence: bulk From: Internet-Drafts@ietf.org (by way of Ralph Droms ) To: Multiple recipients of list Subject: I-D ACTION:draft-ietf-ipsec-dhcp-02.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion list for DHCPv6 internet protocol. Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 FYI... - Ralph ===== A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : DHCP Configuration of IPSEC Tunnel Mode Author(s) : B. Patel, B. Aboba, S. Kelly, V. Gupta Filename : draft-ietf-ipsec-dhcp-02.txt Pages : 12 Date : 18-Oct-99 The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for host configuration. This draft describes the requirements for host configuration in IPSEC tunnel mode and describes how the DHCP protocol may be used for configuration in this case. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dhcp-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-dhcp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-dhcp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19991018121712.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-dhcp-02.txt From dhcp-v4@bucknell.edu Tue Oct 19 11:43: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 LAA22983 for ; Tue, 19 Oct 1999 11:43: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 LAA16842; Tue, 19 Oct 1999 11:41:52 -0400 (EDT) Date: Tue, 19 Oct 1999 11:41:52 -0400 (EDT) Message-Id: <199910191457.KAA00806@grosse.manhattan.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: DHCP and Internet Access X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Is it possible to configure a Solstice Firewall to grant access to > the Internet via recognising a trusted machine name, or does it need > to operate via the IP address? ENOCLUE - sorry. > If we cannot change the firewall, is there anyway we can reserve a > bank of IPs on the DHCP server to allocate to certain machine names? The ISC DHCP server, version 3.0, and probably other DHCP servers, can be configured to recognize some machines as "known" and others as unknown, or to just group machines into different classes. You can then allocate seperate address pools for each class, or for known versus unknown clients. The details of how to do this are described in the DHCP Handbook, Chapter 17, as well as in the manual pages that come with the ISC DHCP server. With the Microsoft server that comes with NT 4.0SP4, you can make reservations for clients, similar to fixed-address allocation on the ISC DHCP server, and so you could simply assign specific IP addresses to specific clients, and then enable those addresses on your firewall. AFAIK, all available DHCP servers support this method of address allocation. _MelloN_ From dhcp-v4@bucknell.edu Tue Oct 19 11:47:05 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23137 for ; Tue, 19 Oct 1999 11:47:05 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA04300; Tue, 19 Oct 1999 11:46:00 -0400 (EDT) Date: Tue, 19 Oct 1999 11:46:00 -0400 (EDT) Message-Id: <199910191521.LAA27423@mail.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: Internet-Drafts@ietf.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Internet-Drafts@ietf.org (by way of Ralph Droms ) To: Multiple recipients of list Subject: I-D ACTION:draft-ietf-ipsec-dhcp-02.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 FYI... - Ralph ===== A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : DHCP Configuration of IPSEC Tunnel Mode Author(s) : B. Patel, B. Aboba, S. Kelly, V. Gupta Filename : draft-ietf-ipsec-dhcp-02.txt Pages : 12 Date : 18-Oct-99 The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for host configuration. This draft describes the requirements for host configuration in IPSEC tunnel mode and describes how the DHCP protocol may be used for configuration in this case. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dhcp-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-dhcp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-dhcp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19991018121712.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-dhcp-02.txt From dhcp-v4@bucknell.edu Wed Oct 20 07:33:28 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25494 for ; Wed, 20 Oct 1999 07:33:27 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id HAA29621; Wed, 20 Oct 1999 07:32:57 -0400 (EDT) Date: Wed, 20 Oct 1999 07:32:57 -0400 (EDT) Message-Id: <199910201125.HAA01235@uplink.net> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: I-D ACTION:draft-ietf-dhc-client-options-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Interpreting Client Options for the Dynamic Host Configuration Protocol Author(s) : R. Hibbs, N. Lane Filename : draft-ietf-dhc-client-options-00.txt Pages : 24 Date : 19-Oct-99 During the summer of 1999, a grand debate raged over the correct interpretation of several DHCP client options as described in [RFC 2132], as well as the need for one option whose proposing Internet-Draft expired. As a result of that debate, the authors gained some insights into the intended (or unintended!) interpretation of certain options defined in [RFC 2132,] particularly the Vendor Class Identifier (option 60) and Vendor Encapsulated Options (option 43.) These insights are presented in this informational Internet-Draft, whose reason for being is to act as an aid to implementers of the DHC protocol, and to future editors of the underlying RFCs and selected, current Internet-Drafts. This memo is not being proposed as a standards-track document, but rather as an aid to clarify existing and future RFCs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-client-options-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-client-options-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-client-options-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19991019135724.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-client-options-00.txt From dhcp-v4@bucknell.edu Wed Oct 20 07:36:32 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25608 for ; Wed, 20 Oct 1999 07:36:31 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id HAA01155; Wed, 20 Oct 1999 07:36:20 -0400 (EDT) Date: Wed, 20 Oct 1999 07:36:20 -0400 (EDT) Message-Id: <199910201125.HAA01254@uplink.net> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: I-D ACTION:draft-ietf-dhc-userclass-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 : The User Class Option for DHCP Author(s) : G. Stump, R. Droms, Y. Gu, R. Vyaghrapuri, A. Demirtjis, B. Beser, J. Privat Filename : draft-ietf-dhc-userclass-04.txt Pages : 5 Date : 19-Oct-99 This option is used by a DHCP client to optionally identify the type or category of user or applications it represents. The information contained in this option is an NVT ASCII text object that represents the user class of which the client is a member. Based on this class, a DHCP server selects the appropriate address pool to assign an address to the client and the appropriate configuration parameters. This document attempts to merge draft-ietf-dhc-userclass-03.txt and draft-ietf-dhc-useraddr-00.txt. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-userclass-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-userclass-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-userclass-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: <19991019135737.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-userclass-04.txt From dhcp-v4@bucknell.edu Wed Oct 20 14:42:05 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18444 for ; Wed, 20 Oct 1999 14:42: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 OAA24265; Wed, 20 Oct 1999 14:40:57 -0400 (EDT) Date: Wed, 20 Oct 1999 14:40:57 -0400 (EDT) Message-Id: <199910201815.OAA01002@marvel.research.telcordia.com> Errors-To: droms@bucknell.edu Reply-To: subir@mailee.research.telcordia.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Subir Das To: Multiple recipients of list Subject: Request for a slot in next IETF X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii Mime-Version: 1.0 Hi, We are going to submit a draft on an extension to DHCP for nodes roaming among commercial wireless networks. May we get a time slot in "dhc" working group to present our submission in next IETF at Washington, DC? Thanks, Subir ******************************************************************************** Subir Das Ofc: MCC 1D-210R Telcordia Technologies Tel: 973 829 4959 (Formerly Bellcore) Fax: 937 829 5888 445, South Street E-mail: subir@research.telcordia.com Morristown, NJ 07960-6438 ******************************************************************************** From dhcp-v6@bucknell.edu Thu Oct 21 09:30: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 JAA21635 for ; Thu, 21 Oct 1999 09:30: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 JAA31229; Thu, 21 Oct 1999 09:25:16 -0400 (EDT) Date: Thu, 21 Oct 1999 09:25:16 -0400 (EDT) Message-Id: <199910211300.JAA13066@mail.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v6@bucknell.edu Sender: dhcp-v6@bucknell.edu Precedence: bulk From: Ralph Droms To: Multiple recipients of list Subject: Agenda for DHC WG meeting in DC X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion list for DHCPv6 internet protocol. Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 As is our custom, the WG will meet twice in Oslo; once for DHCPv4 issues and once for DHCPv6 issues. Here is a tentative agenda, based on requests I've I've received to date. If I've agreed to put you on the agenda, and you don't appear on this tentative agenda, please contact me. - Ralph Tuesday, Nov 9 at 0900-1130 (DHCPv4) ===================================== Current agenda: Yves T'Joens (Alcatel) DHCP reconfigure message Bill Arbaugh (Penn) DHCPv4 authentication Carl Smith (Sun) Name service ordering option Barr Hibbs (Pacbell) DHCP MIB Kim Kinnear (Cisco) Failover protocol Bernie Volz (Process Software) LDAP schema Jerome Privat (BT) User Class option Jerome Privat (BT) Doblephase configuration Mike Patrick (Motorola) Agent options Subir Das () Roaming among commercial wireless networks Bernard Aboba (Microsoft) Kerberos authentication Tuesday, Nov 9 at 1300-1515 (DHCPv6) ===================================== Mike Carney (Sun) Discussion of progress on draft issues From dhcp-v4@bucknell.edu Thu Oct 21 09:35: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 JAA22060 for ; Thu, 21 Oct 1999 09:35:40 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA10372; Thu, 21 Oct 1999 09:33:04 -0400 (EDT) Date: Thu, 21 Oct 1999 09:33:04 -0400 (EDT) Message-Id: <199910211253.IAA22026@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-sso-03.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The Server Selection Option for DHCP Author(s) : G. Stump, P. Gupta, R. Droms, B. Sommerfeld Filename : draft-ietf-dhc-sso-03.txt Pages : 14 Date : 20-Oct-99 This option is provided by DHCP servers to DHCP clients so that clients may optionally select from among multiple offers received from DHCP servers in the network offer from a DHCP. The information contained in this option is an hex value that represents an integer value indicating the priority of the offer in which this option is contained. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-sso-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-sso-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-sso-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19991020133415.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-sso-03.txt From dhcp-v4@bucknell.edu Thu Oct 21 09:41:01 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22517 for ; Thu, 21 Oct 1999 09: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 JAA02234; Thu, 21 Oct 1999 09:40:21 -0400 (EDT) Date: Thu, 21 Oct 1999 09:40:21 -0400 (EDT) Message-Id: <199910211300.JAA13066@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: Agenda for DHC WG meeting in DC X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 As is our custom, the WG will meet twice in Oslo; once for DHCPv4 issues and once for DHCPv6 issues. Here is a tentative agenda, based on requests I've I've received to date. If I've agreed to put you on the agenda, and you don't appear on this tentative agenda, please contact me. - Ralph Tuesday, Nov 9 at 0900-1130 (DHCPv4) ===================================== Current agenda: Yves T'Joens (Alcatel) DHCP reconfigure message Bill Arbaugh (Penn) DHCPv4 authentication Carl Smith (Sun) Name service ordering option Barr Hibbs (Pacbell) DHCP MIB Kim Kinnear (Cisco) Failover protocol Bernie Volz (Process Software) LDAP schema Jerome Privat (BT) User Class option Jerome Privat (BT) Doblephase configuration Mike Patrick (Motorola) Agent options Subir Das () Roaming among commercial wireless networks Bernard Aboba (Microsoft) Kerberos authentication Tuesday, Nov 9 at 1300-1515 (DHCPv6) ===================================== Mike Carney (Sun) Discussion of progress on draft issues From dhcp-v4@bucknell.edu Thu Oct 21 17:34:41 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14677 for ; Thu, 21 Oct 1999 17:34: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 RAA04521; Thu, 21 Oct 1999 17:33:24 -0400 (EDT) Date: Thu, 21 Oct 1999 17:33:24 -0400 (EDT) Message-Id: <19991021211614Z7776-195+2619@stovokor.epilogue.com> Errors-To: droms@bucknell.edu Reply-To: wes@epilogue.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Bill Sommerfeld To: Multiple recipients of list Subject: Re: I-D ACTION:draft-ietf-dhc-sso-03.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 I've taken over editing this draft. I've resubmitted it with some minor wordsmithing and with the one backlogged comment Ralph forwarded to me edited into it. Send comments on it to me. Is it useful? Should it be kept moving? - Bill From dhcp-v4@bucknell.edu Fri Oct 22 10:04:41 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14322 for ; Fri, 22 Oct 1999 10:04:40 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA10948; Fri, 22 Oct 1999 10:03:46 -0400 (EDT) Date: Fri, 22 Oct 1999 10:03:46 -0400 (EDT) Message-Id: <199910221350.JAA26169@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: DC Agenda 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 the latest draft agenda for the DHC WG meetings in DC. Note that the schedule is *very* full. I will post a list of drafts to the mailing list and the agenda to www.dhcp.org later today. *Please* read the relevant drafts and initiate discussion prior to the WG meeting, so that we can have clarity about the issues when we get to DC. - Ralph ===== Tuesday, Nov 9 at 0900-1130 (DHCPv4) ===================================== Current agenda: Yves T'Joens (Alcatel) DHCP reconfigure message Bill Arbaugh (Penn) DHCPv4 authentication Carl Smith (Sun) Name service ordering option Kim Kinnear (Cisco) Failover protocol Jerome Privat (BT) User Class option Jerome Privat (BT) Doublephase configuration Mike Patrick (Motorola) Agent options Subir Das (Telcordia) Roaming among commercial wireless networks Bernard Aboba (Microsoft) Kerberos authentication Mark Stapp (Cisco) DHCP-DNS interaction Bernie Volz (Process Software) Server load balancing Juan Garay (Bell Labs) Option for NAT/IPSec interaction Andreas Gustafsson A DNS RR for DHCP information (Internet Engines, Inc.) Tuesday, Nov 9 at 1300-1515 (DHCPv6) ===================================== Bernie Volz (Process Software) LDAP schema Barr Hibbs (Pacbell) DHCP MIB Barr Hibbs (Pacbell) Client option clarifications Mike Carney (Sun) DHCP options guidelines Mike Carney (Sun) Connectathon Mike Carney (Sun) DHCPv6 Jim Bound (Compaq) Charlie Perkins (Nokia) From dhcp-v6@bucknell.edu Fri Oct 22 10:05:46 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14370 for ; Fri, 22 Oct 1999 10:05: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 JAA30484; Fri, 22 Oct 1999 09:58:33 -0400 (EDT) Date: Fri, 22 Oct 1999 09:58:33 -0400 (EDT) Message-Id: <199910221350.JAA26169@mail.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v6@bucknell.edu Sender: dhcp-v6@bucknell.edu Precedence: bulk From: Ralph Droms To: Multiple recipients of list Subject: DC Agenda X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion list for DHCPv6 internet protocol. Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Here is the latest draft agenda for the DHC WG meetings in DC. Note that the schedule is *very* full. I will post a list of drafts to the mailing list and the agenda to www.dhcp.org later today. *Please* read the relevant drafts and initiate discussion prior to the WG meeting, so that we can have clarity about the issues when we get to DC. - Ralph ===== Tuesday, Nov 9 at 0900-1130 (DHCPv4) ===================================== Current agenda: Yves T'Joens (Alcatel) DHCP reconfigure message Bill Arbaugh (Penn) DHCPv4 authentication Carl Smith (Sun) Name service ordering option Kim Kinnear (Cisco) Failover protocol Jerome Privat (BT) User Class option Jerome Privat (BT) Doublephase configuration Mike Patrick (Motorola) Agent options Subir Das (Telcordia) Roaming among commercial wireless networks Bernard Aboba (Microsoft) Kerberos authentication Mark Stapp (Cisco) DHCP-DNS interaction Bernie Volz (Process Software) Server load balancing Juan Garay (Bell Labs) Option for NAT/IPSec interaction Andreas Gustafsson A DNS RR for DHCP information (Internet Engines, Inc.) Tuesday, Nov 9 at 1300-1515 (DHCPv6) ===================================== Bernie Volz (Process Software) LDAP schema Barr Hibbs (Pacbell) DHCP MIB Barr Hibbs (Pacbell) Client option clarifications Mike Carney (Sun) DHCP options guidelines Mike Carney (Sun) Connectathon Mike Carney (Sun) DHCPv6 Jim Bound (Compaq) Charlie Perkins (Nokia) From dhcp-v4@bucknell.edu Fri Oct 22 10:45: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 KAA16387 for ; Fri, 22 Oct 1999 10:45: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 KAA13002; Fri, 22 Oct 1999 10:44:30 -0400 (EDT) Date: Fri, 22 Oct 1999 10:44:30 -0400 (EDT) Message-Id: <38107346.5395EBE@newbridge.com> Errors-To: droms@bucknell.edu Reply-To: nagan@newbridge.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Raju Narayanaswamy To: Multiple recipients of list Subject: Question about Virtualization and DHCP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.08 [en] (X11; U; SunOS 5.5 sun4u) Content-Transfer-Encoding: 7bit Hi All, I have a question regarding how DHCP works in the context of virtualization of networks. Consider an ISP serving different corporate customers all having their own Virtual Private Networks. Assume the DHCP server is hosted on the Service Provider. This is a case of customers who are not interested in managing/configuring the DHCP servers, so they outsource the responsiblities to the service provider. Now, since the DHCP server caters to many different corporate customers and there may be IP address overlaps between the networks. How does DHCP server intelligently handle this situation of assigning overlapping addresses? Thanks in advance, -Raju -nagan@newbridge.com From dhcp-v4@bucknell.edu Fri Oct 22 11:39: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 LAA19618 for ; Fri, 22 Oct 1999 11:39: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 LAA07744; Fri, 22 Oct 1999 11:38:44 -0400 (EDT) Date: Fri, 22 Oct 1999 11:38:44 -0400 (EDT) Message-Id: <199910221501.LAA09950@grosse.manhattan.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: Question about Virtualization and DHCP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Now, since the DHCP server caters to many different corporate > customers and there may be IP address overlaps between the networks. > How does DHCP server intelligently handle this situation of > assigning overlapping addresses? This is a really interesting question, to which, unfortunately, I don't think there's an obvious answer. If a relay agent at a customer site has the same IP address as a relay agent at another customer site, you have a particular problem - it seems impossible to differentiate the two. Even if the relay agents have different IP addresses, if you have different network numbers, you still have a problem. The only thing I can think of that would work with existing DHCP servers and the existing protocol, given what you are saying, would be to have a seperate DHCP server process for each customer, and configure the customer relay agents to relay requests to their own DHCP servers. If you are doing NAT (as I presume you are), you may be able to configure your NAT router to change not only the IP address but also the UDP destination port of the relay agent and DHCP server, so that you could have more than one DHCP server running on the same machine, each listening on a nonstandard port for the response from the relay agent. If you are willing to change your requirements a little, what I would suggest in preference to what you have proposed is that you assign each customer a different address range from the same private address space. That way you can have one DHCP server. You don't route different customers' networks together - you just assign them different ranges of IP addresses. If you want to change the protocol to make it possible for the DHCP server to do the right thing, I would suggest a new Relay Agent Information option called "Virtual Private Network ID" which could be configured on the relay agent, and used on the DHCP server to choose from a selection of VPNs. You would then have to get your relay agent vendor (presumably also your router vendor) to add this capability to their DHCP relay agent. _MelloN_ From dhcp-v4@bucknell.edu Fri Oct 22 13:14: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 NAA25341 for ; Fri, 22 Oct 1999 13:14: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 NAA26017; Fri, 22 Oct 1999 13:13:21 -0400 (EDT) Date: Fri, 22 Oct 1999 13:13:21 -0400 (EDT) Message-Id: <002a01bf1cbf$20961060$0201a8c0@wfm> Errors-To: droms@bucknell.edu Reply-To: bmoore@nts.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Bill Moore" To: Multiple recipients of list Subject: RE: Question about Virtualization and DHCP 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.2173.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit > If you want to change the protocol to make it possible for the DHCP > server to do the right thing, I would suggest a new Relay Agent > Information option called "Virtual Private Network ID" which could be > configured on the relay agent, and used on the DHCP server to choose > from a selection of VPNs. You would then have to get your relay > agent vendor (presumably also your router vendor) to add this > capability to their DHCP relay agent. Or have the relay agent also overwrite the existing UserClass ID field. > -----Original Message----- > From: dhcp-v4@bucknell.edu [mailto:dhcp-v4@bucknell.edu]On Behalf Of Ted > Lemon > Sent: Friday, October 22, 1999 8:39 AM > To: Multiple recipients of list > Subject: Re: Question about Virtualization and DHCP > > > > > Now, since the DHCP server caters to many different corporate > > customers and there may be IP address overlaps between the networks. > > How does DHCP server intelligently handle this situation of > > assigning overlapping addresses? > > This is a really interesting question, to which, unfortunately, I > don't think there's an obvious answer. If a relay agent at a > customer site has the same IP address as a relay agent at another > customer site, you have a particular problem - it seems impossible to > differentiate the two. Even if the relay agents have different IP > addresses, if you have different network numbers, you still have a > problem. > > The only thing I can think of that would work with existing DHCP > servers and the existing protocol, given what you are saying, would be > to have a seperate DHCP server process for each customer, and > configure the customer relay agents to relay requests to their own > DHCP servers. If you are doing NAT (as I presume you are), you may be > able to configure your NAT router to change not only the IP address > but also the UDP destination port of the relay agent and DHCP server, > so that you could have more than one DHCP server running on the same > machine, each listening on a nonstandard port for the response from > the relay agent. > > If you are willing to change your requirements a little, what I would > suggest in preference to what you have proposed is that you assign > each customer a different address range from the same private address > space. That way you can have one DHCP server. You don't route > different customers' networks together - you just assign them > different ranges of IP addresses. > > If you want to change the protocol to make it possible for the DHCP > server to do the right thing, I would suggest a new Relay Agent > Information option called "Virtual Private Network ID" which could be > configured on the relay agent, and used on the DHCP server to choose > from a selection of VPNs. You would then have to get your relay > agent vendor (presumably also your router vendor) to add this > capability to their DHCP relay agent. > > _MelloN_ > From dhcp-v4@bucknell.edu Fri Oct 22 13:16:32 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25439 for ; Fri, 22 Oct 1999 13:16:29 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA18883; Fri, 22 Oct 1999 13:16:04 -0400 (EDT) Date: Fri, 22 Oct 1999 13:16:04 -0400 (EDT) Message-Id: <199910221706.NAA23525@grosse.manhattan.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: Question about Virtualization and DHCP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Or have the relay agent also overwrite the existing UserClass ID field. Well, yes, but that still involves hacking the relay agent and the DHCP server. If you're going to go to that trouble, why not do it in a standard-conformant way that doesn't conflict with existing, valuable functionality? Adding a new agent option would be just as easy, and that usage would, IMHO, be easy to get standardized. There is no chance that this usage of the user class option would get standardized, IMHO. _MelloN_ From dhcp-v4@bucknell.edu Fri Oct 22 13:55: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 NAA27870 for ; Fri, 22 Oct 1999 13:55: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 NAA21286; Fri, 22 Oct 1999 13:53:39 -0400 (EDT) Date: Fri, 22 Oct 1999 13:53:39 -0400 (EDT) Message-Id: <19991022171839Z7905-195+2639@stovokor.epilogue.com> Errors-To: droms@bucknell.edu Reply-To: wes@epilogue.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Bill Sommerfeld To: Multiple recipients of list Subject: Re: Question about Virtualization and DHCP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Or have the relay agent also overwrite the existing UserClass ID field. This would break nearly any conceivable way of doing DHCP security. - Bill From dhcp-v4@bucknell.edu Sun Oct 24 08:56:38 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08059 for ; Sun, 24 Oct 1999 08:56:38 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA15860; Sun, 24 Oct 1999 08:55:43 -0400 (EDT) Date: Sun, 24 Oct 1999 08:55:43 -0400 (EDT) Message-Id: <199910241237.IAA27176@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: problems implementing dhcp on Linux 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 LTRAN@CTP.COM follows. -------------------------------------------------------------- I am having problems getting my Window NT machine to detect my DHCP server. My DHCP server is on a Linux machine running redhat 6. The DHCP server detects the DHCPDISCOVER request from my laptop running Windows NT and sends a DHCPOFFER reply, but my laptop does not see the reply. I've read somewhere I had to add a router of 255.255.255.255. That didn't help at all. Is there anything else I can try? Lewis From dhcp-v4@bucknell.edu Sun Oct 24 11:17:57 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09891 for ; Sun, 24 Oct 1999 11:17: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 LAA21180; Sun, 24 Oct 1999 11:16:51 -0400 (EDT) Date: Sun, 24 Oct 1999 11:16:51 -0400 (EDT) Message-Id: <199910241458.KAA20309@grosse.manhattan.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: problems implementing dhcp on Linux X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > I am having problems getting my Window NT machine to detect my DHCP > server. My DHCP server is on a Linux machine running redhat 6. The > DHCP server detects the DHCPDISCOVER request from my laptop running > Windows NT and sends a DHCPOFFER reply, but my laptop does not see the > reply. I've read somewhere I had to add a router of 255.255.255.255. > That didn't help at all. Is there anything else I can try? I would encourage you to do two things. First, get the very latest version 2.0 distribution of the ISC DHCP server. Based on what you've said, it sounds like you're using an old RPM with 2.0b1pl6. The latest distribution is at: ftp://ftp.isc.org/isc/dhcp/dhcp-2.0.tar.gz When you get the new distribution, read the README file - it tells you how to configure it on various versions of Linux. If this doesn't help, subscribe to the dhcp-server@isc.org mailing list - send mail to dhcp-server-request@isc.org with the word "subscribe" in the subject line. Then ask your question there. Include the version of the Linux kernel and the name of the distribution. Include a log of the client trying to boot. Send the output of: tcpdump -x -n -e -s 1500 udp port 67, run while the client is trying to boot. We'll do our best to help you! _MelloN_ From dhcp-v4@bucknell.edu Mon Oct 25 08:41:15 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06961 for ; Mon, 25 Oct 1999 08:41: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 IAA06634; Mon, 25 Oct 1999 08:37:27 -0400 (EDT) Date: Mon, 25 Oct 1999 08:37:27 -0400 (EDT) Message-Id: <199910251221.IAA08208@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-loadb-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHC load balancing algorithm Author(s) : B. Volz, S Gonczi, R. Stevens Filename : draft-ietf-dhc-loadb-00.txt Pages : 8 Date : 22-Oct-99 This draft proposes a method of algorithmic load balancing that enables multiple, cooperating servers to decide which one should service a client, without requiring participating servers to exchange information. It proposes a computable server selection mechanism for the DHCP or DHC Failover Protocol. In addition, it provides for the use of the same mechanism to govern the target server selection of a forwarding agent such as a BOOTP relay. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-loadb-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-loadb-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-loadb-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19991022135502.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-loadb-00.txt From dhcp-v4@bucknell.edu Mon Oct 25 08:46:28 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07190 for ; Mon, 25 Oct 1999 08:46:27 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA14215; Mon, 25 Oct 1999 08:44:50 -0400 (EDT) Date: Mon, 25 Oct 1999 08:44:50 -0400 (EDT) Message-Id: <199910251221.IAA19270@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-server-mib-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 : Dynamic Host Configuration Protocol (DHCP) Server MIB Author(s) : R. Hibbs, G. Waters Filename : draft-ietf-dhc-server-mib-04.txt Pages : 37 Date : 22-Oct-99 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-server-mib-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-server-mib-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-server-mib-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: <19991022135513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-server-mib-04.txt From dhcp-v4@bucknell.edu Mon Oct 25 08:48: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 IAA07282 for ; Mon, 25 Oct 1999 08:48: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 IAA13445; Mon, 25 Oct 1999 08:46:13 -0400 (EDT) Date: Mon, 25 Oct 1999 08:46:13 -0400 (EDT) Message-Id: <199910251221.IAA10621@mail.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: Internet-Drafts@ietf.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Internet-Drafts@ietf.org (by way of Ralph Droms ) To: Multiple recipients of list Subject: I-D ACTION:draft-ietf-dnsind-dhcp-rr-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS IXFR, Notification, and Dynamic Update Working Group of the IETF. Title : A DNS RR for encoding DHCP information Author(s) : A. Gustafsson Filename : draft-ietf-dnsind-dhcp-rr-00.txt Pages : 4 Date : 22-Oct-99 This document describes a DNS RR for use by DHCP servers that need to store state information in the DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsind-dhcp-rr-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsind-dhcp-rr-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsind-dhcp-rr-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19991022135417.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsind-dhcp-rr-00.txt From dhcp-v4@bucknell.edu Mon Oct 25 11:38: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 LAA15707 for ; Mon, 25 Oct 1999 11:38: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 LAA12190; Mon, 25 Oct 1999 11:36:04 -0400 (EDT) Date: Mon, 25 Oct 1999 11:36:04 -0400 (EDT) Message-Id: <63D30D6E10CFD11190A90000F805FE8601CE6F9E@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: Domments on draft-ietf-dnsind-dhcp-rr-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain X-Mailer: Internet Mail Service (5.0.1460.8) Mime-Version: 1.0 Gretings, I like the idea of creating a Client id / MAC address mapping in DNS. This makes a lot of sense. I would, however, like to see the format and exact content defined in the draft. This is the right place for it. The alternative is to create yet another short draft, just to nail this down. aRRGH... Steve Gonczi From dhcp-v4@bucknell.edu Mon Oct 25 15:07: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 PAA02423 for ; Mon, 25 Oct 1999 15:07: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 OAA15600; Mon, 25 Oct 1999 14:23:41 -0400 (EDT) Date: Mon, 25 Oct 1999 14:23:41 -0400 (EDT) Message-Id: <199910251758.NAA03174@grosse.manhattan.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: Domments on draft-ietf-dnsind-dhcp-rr-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > As we've been running an internal automatic DNS update mechanism which uses > MAC addresses as a way to denote ownership of a DNS entry, I'd like to > review what's been said and would like to know where the archives are. The archives aren't publically available - it was a private discussion between me and some of the BIND developers. The basic issue is that the use of the client MAC address in IPv6 local address discovery has been flagged as a "privacy" issue, and much fuss made about it. So I'm leery of trying to advance a proposal that not only makes this information globally visible while it's being used, but actually stores it in a database. I'm hoping that people can tell me whether for their purposes a "CREATOR" record would do as well as a "CLIENT-ID" record. I think for DHCP it would. Your case is a specific solution, and you've obviously already decided there's no privacy issue, so that's fine, but the standard protocol has to run the gauntlet of public opinion, and I think public opinion will frown on this use of the MAC address. > As for the "publicly searchable" issue, and keeping in mind that I haven't > been paying attention, it seems like this field could be made to only > distribute to selected servers. There's no such mechanism in the DNS. If it's published, it's published, and anybody can read it. If you run split-horizon DNS, your users may be somewhat protected, but we can't assume that this will be the case generally, particularly since there are plenty of people who consider split-horizon DNS a mistake. > Another option would be to encrypt the MAC address on the DNS server. I don't see why we should bother with this. I don't really see the value of storing this information in the DNS in the first place. _MelloN_ From dhcp-v4@bucknell.edu Mon Oct 25 15:10: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 PAA02505 for ; Mon, 25 Oct 1999 15:10: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 OAA11118; Mon, 25 Oct 1999 14:21:48 -0400 (EDT) Date: Mon, 25 Oct 1999 14:21:48 -0400 (EDT) Message-Id: <199910251749.MAA26004@drawbridge.damark.com> Errors-To: droms@bucknell.edu Reply-To: william.wells@damark.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "william.wells" To: Multiple recipients of list Subject: RE: Domments on draft-ietf-dnsind-dhcp-rr-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain Mime-Version: 1.0 I have to apologize that I've not been paying much attention as I'd like due to various other "fires" but I triggered on "MAC". As we've been running an internal automatic DNS update mechanism which uses MAC addresses as a way to denote ownership of a DNS entry, I'd like to review what's been said and would like to know where the archives are. Our locally written mechanism is probably in the 5-10 year old range and doesn't use DHCP; all IP reservation information is maintained in DNS which allows redundant servers to provide the same information for existing systems. In our case, when a PC needs an IP address, we see if the DNS entry corresponding to the PCs existing IP address matches on MAC address and is a valid IP address for the sub-net the PC is on. If so, we use whatever IP address (and name) is currently assigned. If not, we search DNS for the MAC and if it belongs to an IP address on the sub-net the PC is on, we use that one. Otherwise, we assign a new IP address according to various rules and remove the old from the old sub-net. We allow multiple subnets on a network segment (192.168.16.x and 172.24.x.x, for example). As we use IP address for validating some types of accesses, we normally assign out of a pool (much like DHCP) but also allow a manual assignment to an IP address outside of the pool to "stick". Yet, if the assignment expires (weeks here) or the system gets moved to another address space, a new IP will be assigned in the default pool. As for the "publicly searchable" issue, and keeping in mind that I haven't been paying attention, it seems like this field could be made to only distribute to selected servers. This would keep the "public" to the systems which are performing the IP address assignments (or validation), not the entire Internet. If you are going to allow valid existing assignments of IP addresses outside the pool managed by a particular DHCP server to "stick" (redundant servers), then you need more than who created the IP address, you also need to know the MAC address. Another option would be to encrypt the MAC address on the DNS server. If the systems which are looking for a MAC address performed the encryption prior to asking for the MAC (all using the same key), then the DNS server wouldn't need to decrypt the information in order to locate the entry. In this case, a 1-way encryption algorithm could be used. Indeed, the DNS server wouldn't necessarily need to even know the algorithm. Again, I apologize for jumping into the discussion "cold" and will be glad to read the archives someone could point them out. > -----Original Message----- > From: Ted Lemon [SMTP:mellon@isc.org] > Sent: Monday, October 25, 1999 11:49 AM > To: Multiple recipients of list > Subject: Re: Domments on draft-ietf-dnsind-dhcp-rr-00.txt > > > One objection that's come up with this draft is that MAC addresses are > considered by the paranoid to be "private," which means that if we > stuff them in the DNS, where they're publically searchable, somebody > might freak out. > > I'm actually wondering if just having a DNS RRtype that says who > created the name would be enough - e.g., instead of storing the client > MAC address, you have a CREATOR record that contains the IP address of > the DHCP server, or even just to a unique, locally-defined token. > > Can anybody comment on whether or not a CREATOR record like this would > be enough? The reason this draft got proposed is that the DNS guys > *really* don't like the DHCP-DNS use of the KEY record, and we'd like > for there to be an alternative. > > _MelloN_ From dhcp-v4@bucknell.edu Mon Oct 25 15:11:41 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02529 for ; Mon, 25 Oct 1999 15:11:40 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA03738; Mon, 25 Oct 1999 12:48:50 -0400 (EDT) Date: Mon, 25 Oct 1999 12:48:50 -0400 (EDT) Message-Id: <199910251552.LAA02303@grosse.manhattan.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: Domments on draft-ietf-dnsind-dhcp-rr-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 One objection that's come up with this draft is that MAC addresses are considered by the paranoid to be "private," which means that if we stuff them in the DNS, where they're publically searchable, somebody might freak out. I'm actually wondering if just having a DNS RRtype that says who created the name would be enough - e.g., instead of storing the client MAC address, you have a CREATOR record that contains the IP address of the DHCP server, or even just to a unique, locally-defined token. Can anybody comment on whether or not a CREATOR record like this would be enough? The reason this draft got proposed is that the DNS guys *really* don't like the DHCP-DNS use of the KEY record, and we'd like for there to be an alternative. _MelloN_ From dhcp-v4@bucknell.edu Mon Oct 25 15:29: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 PAA03123 for ; Mon, 25 Oct 1999 15:29: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 PAA03758; Mon, 25 Oct 1999 15:24:08 -0400 (EDT) Date: Mon, 25 Oct 1999 15:24:08 -0400 (EDT) Message-Id: <199910251923.MAA02201@gulag.araneus.fi> Errors-To: droms@bucknell.edu Reply-To: gson@iengines.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: gson@iengines.com (Andreas Gustafsson) To: Multiple recipients of list Subject: Re: Domments on draft-ietf-dnsind-dhcp-rr-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > > MAC addresses as a way to denote ownership of a DNS entry, I'd like to > > review what's been said and would like to know where the archives are. > > The archives aren't publically available - it was a private discussion > between me and some of the BIND developers. The basic issue is that > the use of the client MAC address in IPv6 local address discovery has > been flagged as a "privacy" issue, and much fuss made about it. So > I'm leery of trying to advance a proposal that not only makes this > information globally visible while it's being used, but actually > stores it in a database. Please note that the use of MAC addresses in the public DNS for identifying clients is specified in draft-ietf-dhc-dhcp-dns-10.txt, not in draft-ietf-dnsind-dhcp-rr-00.txt. The DHCP RR is simply intended as a mechanism of storing whatever client identifiction draft-ietf-dhc-dhcp-dns cares to specify. I am not trying to say what information DHCP servers should store in the DNS, or even whether they should store anything at all. All I'm saying is that if something is stored, it should use a unique record type instead of overloading KEY. If you feel the use of the MAC address is inappropriate, you need to take it up with the authors of draft-ietf-dhc-dhcp-dns-10.txt. If the dhcp-rr draft does not advance, it does not mean that the MAC address is not published in the DNS - it just means that it is published in a KEY record rather than a DHCP record. That would hardly be an improvement. Pre-00 versions of the dhcp-rr draft in private circulation did contain a reference to the specific MAC based form of client identifiers described in the current version of the dhcp-dns draft, but in response to criticism, I removed that reference before submitting the draft for publication. Thus, the dhcp-dns draft could be changed not to use the MAC, without having to change the dhcp-rr draft. > I don't see why we should bother with this. I don't really see the > value of storing this information in the DNS in the first place. This, too, is a draft-ietf-dhc-dhcp-dns issue. -- Andreas Gustafsson, gson@iengines.com From dhcp-v4@bucknell.edu Mon Oct 25 16:43:57 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05052 for ; Mon, 25 Oct 1999 16:43: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 QAA22036; Mon, 25 Oct 1999 16:41:41 -0400 (EDT) Date: Mon, 25 Oct 1999 16:41:41 -0400 (EDT) Message-Id: <199910251934.PAA03846@grosse.manhattan.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: Domments on draft-ietf-dnsind-dhcp-rr-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > This, too, is a draft-ietf-dhc-dhcp-dns issue. No, not really. Yes, the DHCP-DNS draft does specify using the MAC address, which I think is wrong, and I am indeed referring to that draft when I ask people on this mailing list whether or not they think this is necessary. But the option proposed in the dnsind-dhcp-rr draft _is_ DHCP- specific, and the only DHCP option that it would make sense to store would be the MAC address or client identifier, both of which have the problem I described. This is why I'm suggesting a CREATOR RRtype would be better. I think we should decide what we want to store in the DNS before trying to advance a DHCP-specific draft describing a new DNS record. I think you're right to be trying to create a better way to do this, but I think we need to decide what we need before you advance a draft providing it! :') _MelloN_ From dhcp-v4@bucknell.edu Mon Oct 25 16:56: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 QAA05218 for ; Mon, 25 Oct 1999 16:56: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 QAA16283; Mon, 25 Oct 1999 16:44:08 -0400 (EDT) Date: Mon, 25 Oct 1999 16:44:08 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: ndlane@wal-mart.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Nathan Lane To: Multiple recipients of list Subject: RE: Domments on draft-ietf-dnsind-dhcp-rr-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; X-Mailer: Internet Mail Service (5.5.2650.21) Mime-Version: 1.0 > -----Original Message----- > From: Ted Lemon [SMTP:mellon@isc.org] > Sent: Monday, October 25, 1999 1:24 PM > To: Multiple recipients of list > Subject: Re: Domments on draft-ietf-dnsind-dhcp-rr-00.txt > > > > As we've been running an internal automatic DNS update mechanism which uses > > MAC addresses as a way to denote ownership of a DNS entry, I'd like to > > review what's been said and would like to know where the archives are. > > The archives aren't publically available - it was a private discussion > between me and some of the BIND developers. The basic issue is that > the use of the client MAC address in IPv6 local address discovery has > been flagged as a "privacy" issue, and much fuss made about it. So > I'm leery of trying to advance a proposal that not only makes this > information globally visible while it's being used, but actually > stores it in a database. I'm hoping that people can tell me whether > for their purposes a "CREATOR" record would do as well as a > "CLIENT-ID" record. I think for DHCP it would. > [Nathan Lane] It really goes deeper than that...and the overloading of the KEY resource record is of specific concern to us. It was brought up last April by members of our team. In our opinion, the owner of the DNS record is specifically NOT the client, but the CID from the client stored in the DNS is useful for us. A "creator" concept may help the superfluous updates that could occur under certain failover conditions as well. (And, the use of CID vs. MAC vs. GUID vs. whatever is really heating up. What should be used to identify the client??? Pretty soon the client will have more ID's than a quick change artist in the former Soviet Union!) (Also, note that the MAC is not necessarily globally unique.) I like the current use of the TXT record to store the CID associated with a DNS PTR. It works enterprise-wide without having to upgrade even our oldest, most catankerous servers. Our server doesn't let us turn this feature off...it would be nice if it did, so we would have the choice. Given the option, we'd probably continue to use it. It's a LOT easier to look in DNS for a TXT record than to go to a switch and find the MAC. I really hate introducting new "views" into the DNS space - user A can see SRV records, but user B cannot see SRV records, etc...a new RR Type will have a lag, in our environment, of about three to five years. A copy of an initial discussion is below: -----Original Message----- From: Diana Lane Sent: Tuesday, June 08, 1999 1:27 PM To: 'dhcp-dns@bucknell.edu' Subject: RE: Dynamic v. static entries Olafur Gudmundsson wrote: "Cricket Liu" writes: > Hi, folks. > > I just got back from a customer who's planning an extensive Windows 2000 > rollout, and I'm beginning to see just how important it'll be to have a > feature in BIND to make part (i.e., certain domain names or RRs) of a > dynamic zone static. > > We found that the Microsoft DHCP Server in Windows 2000 will just delete A > RRs attached to a name if it wants to add an A RR to the name. Here's an > example: You boot DHCP client foo, and foo gets IP address 192.168.1.2. > Unfortunately, you've already got a server in the zone called foo. Whether > you've given the DHCP client or the server responsibility for adding DHCP > client foo's A RR, server foo's A RR gets deleted. Yuck. I see two problems with this behavior, This is a protocol violation. DHCP server SHOULD/MUST NOT delete data that it is not the source of. This is a serious security risk, any dynamically configured machine can now take out a series of servers by simply changing it's hostname and doing DHCP DISCOVER. WOW!!! In the case of a workstation's data replacing that of an industrial device such as a conveyor belt, it is also a serious safety risk. I sent some comments regarding this topic to the dhcp-v4 list about two months ago. I have read draft-ietf-dhc-dhcp-dns-09 and I realize that it proposes a KEY RR to protect an existing entry from modification; however, that approach requires support for RFC 2065. In an enterprise the size of Wal-Mart, it is highly improbable that all name servers will be upgraded to this level in less than two years. I apologize to those for whom this is repetition, but I believe those comments remain relevant: Given a zone on a server that supports dynamic updates, where some names in the zone belong to statically addressed servers performing business-critical functions, one does not want one's DHCP server(s) to blithely send updates that replace those servers' A records and PTR records with those of a DHCP client that happens to send the same hostname as the server in its DHCPREQUEST. That would be a Bad Thing. [...specific method deleted...involved using TXT records to protect important servers through the use of an update prereq...] There are some caveats associated with this approach: The initial DNS lookups and prerequisite queries need to be performed before the DHCPOFFER so that any policy-specific options can be included in the DHCPOFFER. The actual update, if any, may be performed after the DHCPACK is sent in order to avoid updates for incomplete transactions. In addition, Windows NT clients complain loudly via an obnoxious dialog box if they are sent options they did not request. This may be considered desirable as it will almost certainly result in the user opening a trouble ticket (which will lead to the client name being changed to something acceptable). I have seen two other approaches to the problem of name collisions. Neither meets my needs in supporting my customers. One approach is to disambiguate the name a client sends by appending extra characters if the name sent in the hostname option field is the same as an existing domain name. This has a rather nasty tendency to break certain applications that rely on a specific PTR record being returned. Another approach is to replace any existing resource record by that domain name with the new domain name and data, regardless of any other factors. This approach provides no protection against server names being usurped by PCs, printers, whiteboards, or other DHCP clients. Thanks! Diana Lane Senior Network Engineer IP Research & Development Wal-Mart Stores, Inc. 501/277-3177 Be gentle to all, and stern with yourself. - Teresa of Avila -Nathan Lane Wal-Mart Stores, Inc. (501) 277-3177 From dhcp-v4@bucknell.edu Mon Oct 25 18:38:05 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06846 for ; Mon, 25 Oct 1999 18:38:04 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id SAA19241; Mon, 25 Oct 1999 18:37:03 -0400 (EDT) Date: Mon, 25 Oct 1999 18:37:03 -0400 (EDT) Message-Id: <4.2.0.58.19991025143612.01ddb260@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: mjs@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Mark Stapp To: Multiple recipients of list Subject: Re: Comments on draft-ietf-dnsind-dhcp-rr-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"; format=flowed Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Ted, At 12:49 PM 10/25/1999 -0400, Ted Lemon wrote: >One objection that's come up with this draft is that MAC addresses are >considered by the paranoid to be "private," which means that if we >stuff them in the DNS, where they're publically searchable, somebody >might freak out. The issue about what kind of information is to be added to the DNS to support the decision-making I've tried to describe in the dhcp-dns draft is completely separate from the issue of what RR type carries the information. If there is an objection about adding client-ids or MAC addresses into the DNS in some form, we'll have to address it whether we use the KEY RR or some other RR type. "Paranoid" or not, this is clearly a real concern at several levels in the ietf. For those who haven't heard about this, see: http://playground.sun.com/ipng/ipv6-address-privacy.html >I'm actually wondering if just having a DNS RRtype that says who >created the name would be enough - e.g., instead of storing the client >MAC address, you have a CREATOR record that contains the IP address of >the DHCP server, or even just to a unique, locally-defined token. > >Can anybody comment on whether or not a CREATOR record like this would >be enough? Unfortunately, the point of associating client information with A records (and possibly other types) is that it's the association with the client that's interesting, not necessarily an association with the entity that performed the update. The case is one where, for example, a company has two buildings, and has a dhcp server in each building. Suppose a laptop user gets an address from server A, and the user has a windows client that suggests a hostname that the user would like to have associated with the laptop. Server A adds an A RR embedding that hostname into one of the organization's zones. If the user goes over to building B and boots there, server B will find that an A RR already exists on the laptop's domain name. If information exists in the DNS that allows server B to determine that the name is modifiable via DDNS, and to determine whether the record is associated with the current DHCP client or with some other client, server B can be configured to do some very useful and valuable things. Server B can replace the existing A RR, since the client is now using a new IP address. If another client boots, and this second client has been configured with the same hostname as the first client, server B can be configured to replace the existing A RR on that domain name, or not to replace it. If server B notices that a client's suggested domain name already has RRs, and it does not have the DHCP-DNS form of the KEY RR, the server might be configured to conclude that the records were added by an administrator, rather than through DHCP activity. The server might avoid modifying that name in any way, assuming that the administrator's static DNS configuration shouldn't change without his or her own explicit activity. It's the information about the client that allows a decision to be made, not information about the server. > The reason this draft got proposed is that the DNS guys >*really* don't like the DHCP-DNS use of the KEY record, and we'd like >for there to be an alternative. That's an interesting statement - I wish some of "the DNS guys" who've sent me comments over the last year had mentioned their objections. I've had comments, some extensive and some brief, from all of the DNS WG chairs, among others who regularly contribute in DNSIND. Until now, I have not supposed that the use of the KEY RR for this purpose appeared particularly controversial. The KEY RR is explicitly specified (it has 'protocol' and 'algorithm' fields which are available for assignment by iana) to support extensibility. I don't believe that I've proposed an "overloaded" form of the KEY RR; I've just proposed extending it in the way that it supports. There are, unfortunately, two problems with a new RR type: 1) it creates a significant deployment barrier for any installations with pre-9.0 BIND servers (I'll assume that 9 could be taught about a proposed new RR type). I don't think that the opaque information that will be contained in the KEY RR associated with a DHCP-DNS update poses a threat to the operation of DNS servers which understand the KEY type, or to any other DNS client that understands other forms of KEY RR. The number of sites that will have difficulty deploying the current proposal is much smaller. Using the KEY RR would allow the DHCP community to begin deploying useful functionality promptly. 2) it creates a dependency between the dhcp-dns draft and a brand-new draft that has to make its way through the DNS WG. -- Mark From dhcp-v4@bucknell.edu Mon Oct 25 19:27: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 TAA07285 for ; Mon, 25 Oct 1999 19:27: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 TAA28032; Mon, 25 Oct 1999 19:26:12 -0400 (EDT) Date: Mon, 25 Oct 1999 19:26:12 -0400 (EDT) Message-Id: <199910252254.RAA10149@drawbridge.damark.com> Errors-To: droms@bucknell.edu Reply-To: william.wells@damark.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "william.wells" To: Multiple recipients of list Subject: RE: Domments on draft-ietf-dnsind-dhcp-rr-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; Mime-Version: 1.0 There is some differences in approaches between our solution and DHCP. In our case, the DNS table contains all information related to IP address assignments (but not the algorithm for assigning IP addresses); that is, the DNS table is "the" IP assignment table. Hence, the allocation software scans DNS to determine free slots and such. When it wants to allocate an IP address, it actually asks the IP manager to update DNS with a new IP for this MAC/hostname. This is like DHCP in that there is a IP manager but unlike DHCP which uses separate tables. Please remember that ours predated the availability of DHCP on PCs so our approach was different. DNS was readily available so we used DNS to hold information and since DNS is where systems (firewalls, for example) go to determine the IP addresses of other systems. We put the DNS information in TXT records as others in this thread have mentioned but these aren't published outside since all of our internal systems use the "internal only IP addresses"; we have different DNS servers for the Internet. The main reasons for storing the MAC address, my perspective, is to validate ownership of the IP (but may be unnecessary in a true DHCP world)and to allow an easy mapping of MAC address to IP address. Once you have a MAC address, you can use other network tools to determine which hub/switch/port, etc the system is on. You are correct in that our solution works in our environment and hasn't needed to be reviewed publicly. I'd love to dump ours in favor of DHCP/DNS but, last I checked, DHCP didn't support our environment well. I'm looking forward to when it does. It seems to me that allowing only the original "creator" to modify/delete an entry would make redundant DHCP servers which serve the same address pool difficult; especially if the original server which allocated the IP address was unavailable. However, defining a creator pool (multiple server IP addresses which you define as working as a unit) would work assuming that the multiple DHCP servers coordinate their information. It would also seem to make it difficult for a second DHCP server to 'yank' the IP address from the first DHCP server if the system crossed server network boundaries (and therefore used different servers). In environments where changing IP addresses for any reason other than a network switch is considered to be a bad thing, I think you need to use long lease times. If you wait for the long lease to expire, you may fill a class C network with systems which no longer exist. Of course, 'yanking' an IP address assignment is somewhat scary if you can't control who and when.... I've just gotten the mail from Mark Stapp so will go read that and learn more. > -----Original Message----- > From: Ted Lemon [SMTP:mellon@isc.org] > Sent: Monday, October 25, 1999 12:58 PM > To: william.wells > Cc: Multiple recipients of list > Subject: Re: Domments on draft-ietf-dnsind-dhcp-rr-00.txt > > > > As we've been running an internal automatic DNS update mechanism which > uses > > MAC addresses as a way to denote ownership of a DNS entry, I'd like to > > review what's been said and would like to know where the archives are. > > The archives aren't publically available - it was a private discussion > between me and some of the BIND developers. The basic issue is that > the use of the client MAC address in IPv6 local address discovery has > been flagged as a "privacy" issue, and much fuss made about it. So > I'm leery of trying to advance a proposal that not only makes this > information globally visible while it's being used, but actually > stores it in a database. I'm hoping that people can tell me whether > for their purposes a "CREATOR" record would do as well as a > "CLIENT-ID" record. I think for DHCP it would. > > Your case is a specific solution, and you've obviously already decided > there's no privacy issue, so that's fine, but the standard protocol > has to run the gauntlet of public opinion, and I think public opinion > will frown on this use of the MAC address. > > > As for the "publicly searchable" issue, and keeping in mind that I > haven't > > been paying attention, it seems like this field could be made to only > > distribute to selected servers. > > There's no such mechanism in the DNS. If it's published, it's > published, and anybody can read it. If you run split-horizon DNS, > your users may be somewhat protected, but we can't assume that this > will be the case generally, particularly since there are plenty of > people who consider split-horizon DNS a mistake. > > > Another option would be to encrypt the MAC address on the DNS server. > > I don't see why we should bother with this. I don't really see the > value of storing this information in the DNS in the first place. > > _MelloN_ From dhcp-v4@bucknell.edu Tue Oct 26 11:57: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 LAA11250 for ; Tue, 26 Oct 1999 11:57: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 LAA06092; Tue, 26 Oct 1999 11:55:02 -0400 (EDT) Date: Tue, 26 Oct 1999 11:55:02 -0400 (EDT) Message-Id: <4.2.0.58.19991026110539.01d85e10@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: mjs@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Mark Stapp To: Multiple recipients of list Subject: Re: Comments on draft-ietf-dnsind-dhcp-rr-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"; format=flowed Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 At 12:49 PM 10/25/1999 -0400, Ted Lemon wrote: >One objection that's come up with this draft is that MAC addresses are >considered by the paranoid to be "private," which means that if we >stuff them in the DNS, where they're publically searchable, somebody >might freak out. I wonder whether a one-way hash option might be enough to address this at sites where this kind of privacy is a concern. Administrators who wanted to cloak the client-ids would need to configure the DHCP servers with a shared secret. The servers could then store the client-id info. in encrypted form in the DNS RR. I don't think there's a reason to try to involve the DNS server at all. As long as the DHCP servers could reliably make the client-domain name association, the rest of the decision-making would be unaffected. The mechanism to encrypt client-id data would be specified in the draft, but as an optional capability. This would be a capability that implementations SHOULD support, but which would be disabled by default. Is there anyone in the WG who's familiar enough with the 'MAC privacy' issue to be able to tell us whether this might be a reasonable response? Ralph or Tom maybe? Anyone have a favorite encryption method - SHA1 OK? -- Mark From dhcp-v4@bucknell.edu Tue Oct 26 13:15: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 NAA14670 for ; Tue, 26 Oct 1999 13:15:46 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA16437; Tue, 26 Oct 1999 13:14:25 -0400 (EDT) Date: Tue, 26 Oct 1999 13:14:25 -0400 (EDT) Message-Id: <199910261554.LAA01575@grosse.manhattan.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: Comments on draft-ietf-dnsind-dhcp-rr-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Hm. I see your point WRT seperate servers, and I think a hash is the right solution for obfuscation. Unfortunately, this still means we need to fix the DHCP RRtype. > > The reason this draft got proposed is that the DNS guys > >*really* don't like the DHCP-DNS use of the KEY record, and we'd like > >for there to be an alternative. > > That's an interesting statement - I wish some of "the DNS guys" who've sent > me comments over the last year had mentioned their objections. Sigh. This may be partially my fault - I objected to the use of the KEY record, and mentioned it verbally on a number of occasions, possibly even within your earshot, but never wrote up a formal counterproposal. I also didn't point it out to the ISC DNS hackers, so they may not have been aware of it until recently - I'm not sure. > I don't believe that I've proposed an "overloaded" form of the KEY > RR; I've just proposed extending it in the way that it supports. I think maybe Andreas should respond to this. Your use of the KEY record seems incorrect to me, but I'm by no means the expert. > There are, unfortunately, two problems with a new RR type: > > 1) it creates a significant deployment barrier for any installations with > pre-9.0 BIND servers (I'll assume that 9 could be taught about a proposed > new RR type). Adding RRtypes is not difficult. Given that DNS update support wasn't even available until BIND 8.2, which is a very recent release, I don't think this should be considered a major impediment. I can't see why this can't be available in the next release of BIND 8 (although having said this may elicit flamage from my colleagues in BIND-8-land... :') > The number of sites that will have difficulty deploying the current > proposal is much smaller. Using the KEY RR would allow the DHCP > community to begin deploying useful functionality promptly. I think doing things the right way is better than doing things the expedient way. > 2) it creates a dependency between the dhcp-dns draft and a brand-new draft > that has to make its way through the DNS WG. That's true, but doesn't mean that a new RRtype is the wrong way to go. Andreas? _MelloN_ From dhcp-v4@bucknell.edu Tue Oct 26 13:23: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 NAA15207 for ; Tue, 26 Oct 1999 13:23: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 NAA13805; Tue, 26 Oct 1999 13:22:28 -0400 (EDT) Date: Tue, 26 Oct 1999 13:22:28 -0400 (EDT) Message-Id: <3F7F50D4CAF1D211BF070090273CBD32F886E7@oh15ex06.reyrey.com> Errors-To: droms@bucknell.edu Reply-To: john_simpson@reyrey.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Simpson, John R" To: Multiple recipients of list Subject: FW: MAC based filters and DHCP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain X-Mailer: Internet Mail Service (5.5.2448.0) Mime-Version: 1.0 > Greetings, > I tried to send this to the DHCP-INTEREST list, but I ran into some administrative issues that are still being worked out. > What's the best way to ignore client requests based on manufacturer > MAC identifier when using the ISC DHCP server? Is it possible with > version 2, or do I need to use the beta version 3? We've got some > terminal servers that use BOOTP with the DHCP option enabled and we want > the DHCP server to ignore their requests. A filter based on the first > three bytes of their MAC address would do it, but I haven't figured out > how to implement it yet. I've learned a lot by reading through the man > pages included with the source distribution, and just ordered the DHCP > book by Ralph Droms & Ted Lemon -- DHCP is a lot more feature-rich than > the last time I worked with it. > > There are some features in both the version 2 and version 3 > dhcp.conf man pages that look promising, but I haven't found anything > that explicitly shows using a partial MAC address to deny a request. What > am I (hopefully) missing? > > Thanks in advance, > > John Simpson > ------------------------------------------------ > John R. Simpson (937) 485-2269 > IVDS Network Architecture (fax) (937) 485-2427 > Reynolds and Reynolds mailto:John_Simpson@reyrey.com > From dhcp-v4@bucknell.edu Tue Oct 26 14:44: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 OAA19077 for ; Tue, 26 Oct 1999 14:44: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 OAA13907; Tue, 26 Oct 1999 14:42:13 -0400 (EDT) Date: Tue, 26 Oct 1999 14:42:13 -0400 (EDT) Message-Id: <4.2.0.58.19991026123518.01d83400@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: mjs@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Mark Stapp To: Multiple recipients of list Subject: Re: Comments on draft-ietf-dnsind-dhcp-rr-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"; format=flowed Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Ted, At 11:54 AM 10/26/1999 -0400, Ted Lemon wrote: >Hm. I see your point WRT seperate servers, and I think a hash is the >right solution for obfuscation. Unfortunately, this still means we >need to fix the DHCP RRtype. > > > > The reason this draft got proposed is that the DNS guys > > >*really* don't like the DHCP-DNS use of the KEY record, and we'd like > > >for there to be an alternative. > > > > That's an interesting statement - I wish some of "the DNS guys" who've > sent > > me comments over the last year had mentioned their objections. > >Sigh. This may be partially my fault - I objected to the use of the >KEY record, and mentioned it verbally on a number of occasions, >possibly even within your earshot, but never wrote up a formal >counterproposal. I also didn't point it out to the ISC DNS hackers, >so they may not have been aware of it until recently - I'm not sure. > > > I don't believe that I've proposed an "overloaded" form of the KEY > > RR; I've just proposed extending it in the way that it supports. > >I think maybe Andreas should respond to this. Your use of the KEY >record seems incorrect to me, but I'm by no means the expert. I guess I still don't understand what your objection is. I thought your first mail said that it was the "DNS guys" who objected. This message suggests that no one else objected until you objected. But you also ask Andreas to respond with the details of the objection, saying that my proposal merely "seems incorrect" to you. Never mind the "formal counterproposal": if you're the one who objects, you should state your objection clearly so that we can evaluate it and respond to it. I've stated pretty clearly that the chapter and verse that defines the KEY RR supports extending it, and that that's all I think we should do: we should use the RR the way that it's specified. Do you read the specification differently? Why add extensibility to the KEY RR if no one's allowed to extend it? > > There are, unfortunately, two problems with a new RR type: > > > > 1) it creates a significant deployment barrier for any installations with > > pre-9.0 BIND servers (I'll assume that 9 could be taught about a proposed > > new RR type). > >Adding RRtypes is not difficult. Given that DNS update support >wasn't even available until BIND 8.2, which is a very recent release, >I don't think this should be considered a major impediment. I can't >see why this can't be available in the next release of BIND 8 >(although having said this may elicit flamage from my colleagues in >BIND-8-land... :') You can't add new RR types without requiring that the sites that want to use them upgrade all of their BIND servers. That's not a flame, but it is an impediment to deployment. This is a well-known problem, and the only solution is a BIND transplant. That's why flexible, extensible RRs like the KEY RR are useful: new uses can be found that are backwards-compatible (at least back as far as 4.9.5 or maybe 4.9.2), and that can be deployed promptly. > > The number of sites that will have difficulty deploying the current > > proposal is much smaller. Using the KEY RR would allow the DHCP > > community to begin deploying useful functionality promptly. > >I think doing things the right way is better than doing things the >expedient way. Frankly, I don't think that I've made an "expedient" proposal. I've made a proposal that complies with the DNS protocol specifications for the KEY RR, and that's a practical solution to the need we have. > > 2) it creates a dependency between the dhcp-dns draft and a brand-new > draft > > that has to make its way through the DNS WG. > >That's true, but doesn't mean that a new RRtype is the wrong way to >go. Certainly: but using the KEY RR suffers no demonstrated disadvantages, works technically, and can be deployed readily. I'd like to see from you why a new RR must be deployed to support the dhcp-dns draft. Just because we can initiate the process of inventing a new RR doesn't mean that we have to do so in order to provide the capabilities that the dhcp-dns draft describes. Please state your objection to the proposal that's on the table, and let's see whether there's consensus in the WG that it's insurmountable. -- Mark From dhcp-v4@bucknell.edu Tue Oct 26 14: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 OAA19207 for ; Tue, 26 Oct 1999 14: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 OAA21536; Tue, 26 Oct 1999 14:45:19 -0400 (EDT) Date: Tue, 26 Oct 1999 14:45:19 -0400 (EDT) Message-Id: <199910261804.LAA06992@gulag.araneus.fi> Errors-To: droms@bucknell.edu Reply-To: gson@iengines.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: gson@iengines.com (Andreas Gustafsson) To: Multiple recipients of list Subject: Re: Comments on draft-ietf-dnsind-dhcp-rr-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Ted Lemon said: > > I don't believe that I've proposed an "overloaded" form of the KEY > > RR; I've just proposed extending it in the way that it supports. > > I think maybe Andreas should respond to this. Your use of the KEY > record seems incorrect to me, but I'm by no means the expert. The KEY record is clearly intended specifically for cryptographic purposes. RFC2535 says "These resource records represent the public keys of entities named in the DNS and are used for key distribution." DHCP client identifiers are not public keys. The "protocol" field in the KEY record is there to support the storage of public keys for cryptographic protocols other than DNSSEC, not to support non-crypto protocols. Using the KEY RR for non-crypto purposes will work, but that does not mean it is appropriate. > Adding RRtypes is not difficult. [...] I can't > see why this can't be available in the next release of BIND 8 Adding support for the DHCP RR to name servers (including BIND 8) is trivial thanks to its similarity to the existing NSAP type. The factors limiting the prompt deployment of the DHCP RR are elsewhere: 1. Getting an RR type number assigned by IANA. This is one reason why I chose to make the DHCP RR proposal a DNSIND WG draft - I believe this is the fastest route to getting a number assigned. 2. Getting existing name servers upgraded, especially secondary name servers that may not be under the control of the organization wishing to use the DHCP RR. -- Andreas Gustafsson, gson@iengines.com From dhcp-v4@bucknell.edu Tue Oct 26 14:48: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 OAA19337 for ; Tue, 26 Oct 1999 14:48: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 OAA11483; Tue, 26 Oct 1999 14:47:09 -0400 (EDT) Date: Tue, 26 Oct 1999 14:47:09 -0400 (EDT) Message-Id: <199910261827.OAA02202@grosse.manhattan.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: Comments on draft-ietf-dnsind-dhcp-rr-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > I guess I still don't understand what your objection is. I thought your > first mail said that it was the "DNS guys" who objected. This message > suggests that no one else objected until you objected. But you also ask > Andreas to respond with the details of the objection, saying that my > proposal merely "seems incorrect" to you. No, that's not true - the DNS guys who objected did so when they independently read the draft, not when I prompted them to take a look at it. The above statement makes it sound like I am trying to instigate trouble here, which is not the case. I simply think this is an incorrect usage of the KEY record, but am deferring to those who understand DNS better than I to explain why in detail. I've already apologized for my failure to call this to their attention and complain more vociferously earlier. I'm sorry I wasn't able to come to IETF in Oslo, but Oslo was just too hard for me to get to - unfortunate, because I had wanted to bring this up there. If you read rfc2065 where it describes what keys are for, it's quite clear that it intends that keys be used for signing transactions on zones. Nowhere does it suggest that the key record implies some kind of ownership, or that it be used as an identifier. Your proposed use of the KEY record goes directly against the intended purpose of the KEY record. This is why I object to it. I don't know what Andreas's objection is, which is why I asked him to state it. I am concerned that in using the KEY record the way you have, you will confuse programs that are using it in the intended way. In addition, I am concerned that by using a record type which has a seperate use, you may create a situation where the KEY can't be properly used as an update prerequisite. Finally, I am concerned that your usage will box us into a corner later on when we try to extend the uses of the KEY RR in ways that are relevant to its intended use. > I've stated pretty clearly that the chapter and verse that defines > the KEY RR supports extending it, ..to different public key signature algorithms... > and that that's all I think we should do: > we should use the RR the way that it's specified. With this, I agree completely. > Do you read the > specification differently? Why add extensibility to the KEY RR if no one's > allowed to extend it? Extensability is intended in the sense that if the current signature algorithm is found to be flawed in the future, a different one can be chosen without breaking the protocol. It is not, in my reading, intended to allow the KEY record to be used for something entirely other than authenticating DNS transactions. > You can't add new RR types without requiring that the sites that want to > use them upgrade all of their BIND servers. You can't use the DHCP-DNS update protocol without upgrading your DHCP server, either. If you want new functionality, sometimes you have to, well, deploy it. I agree with you that this is an impediment, but I think doing the right thing now is better than having not done the right thing will be later, and I'm sorry, but despite your insistence to the contrary, using the KEY record in this way is not the right thing, and it says so right there in black and white (er, white and blue :') in the RFC! I think that if you actually consider a real deployment strategy, you're really not talking about a lot of DNS servers that would have to be upgraded - it's not like caching DNS servers are ever likely to see these records, for example, because resolvers will never ask for them. So in all likelihood you have to upgrade your internal primaries and secondaries, and if your DHCP server is on a different system, you have to at least install a DHCP-RRtype-aware resolver on that one system. IMHO, it's worth it. I'm only sorry I didn't make a fuss about this sooner. Sigh. _MelloN_ From dhcp-v4@bucknell.edu Tue Oct 26 16:03: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 QAA23699 for ; Tue, 26 Oct 1999 16:03: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 QAA31385; Tue, 26 Oct 1999 16:02:10 -0400 (EDT) Date: Tue, 26 Oct 1999 16:02:10 -0400 (EDT) Message-Id: <199910261911.OAA24280@drawbridge.damark.com> Errors-To: droms@bucknell.edu Reply-To: william.wells@damark.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "william.wells" To: Multiple recipients of list Subject: RE: Comments on draft-ietf-dnsind-dhcp-rr-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain Mime-Version: 1.0 The link provided in one of the previous mail messages provided a good description of the privacy issues. To overly simplify, the issue was that people could use a system name, IP, or MAC to determine a system. Hence, the document described periodically changing these values so that tracking things back would be more difficult. However, having said that, rather than trust my summary, read the document. Within a business, the privacy issues are less important but their issues have some validity, especially when it comes to ISP connections from homes where things aren't hidden behind firewalls. Its similar to software vendors stamping documents or software with a code which uniquely identifies the system where a document was prepared and then registering that system ID in a world-wide database. There are cases when freedom of speech can be hindered if you know that someone can track a document back to you by some hidden code. As far an encrypting the MAC, I agree with your approach. Indeed, for privacy concerns, the encrypted result could change every time the IP was renewed (which addresses some of the privacy issues) providing that all the other DHCP servers in the "group" could decode it (a public key algorithm with random 'stuff' added to the MAC?). The previously mentioned documents recommended using MD5 since that is apparently already required by the standards. > -----Original Message----- > From: Mark Stapp [SMTP:mjs@cisco.com] > Sent: Tuesday, October 26, 1999 10:58 AM > To: Multiple recipients of list > Subject: Re: Comments on draft-ietf-dnsind-dhcp-rr-00.txt > > At 12:49 PM 10/25/1999 -0400, Ted Lemon wrote: > > >One objection that's come up with this draft is that MAC addresses are > >considered by the paranoid to be "private," which means that if we > >stuff them in the DNS, where they're publically searchable, somebody > >might freak out. > > > I wonder whether a one-way hash option might be enough to address this at > sites where this kind of privacy is a concern. Administrators who wanted > to > cloak the client-ids would need to configure the DHCP servers with a > shared > secret. The servers could then store the client-id info. in encrypted form > > in the DNS RR. I don't think there's a reason to try to involve the DNS > server at all. As long as the DHCP servers could reliably make the > client-domain name association, the rest of the decision-making would be > unaffected. The mechanism to encrypt client-id data would be specified in > the draft, but as an optional capability. This would be a capability that > implementations SHOULD support, but which would be disabled by default. > > Is there anyone in the WG who's familiar enough with the 'MAC privacy' > issue to be able to tell us whether this might be a reasonable response? > Ralph or Tom maybe? Anyone have a favorite encryption method - SHA1 OK? > > -- Mark From dhcp-v4@bucknell.edu Tue Oct 26 16:06: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 QAA23829 for ; Tue, 26 Oct 1999 16:06: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 QAA03289; Tue, 26 Oct 1999 16:05:02 -0400 (EDT) Date: Tue, 26 Oct 1999 16:05:02 -0400 (EDT) Message-Id: <199910261929.PAA02558@grosse.manhattan.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: FW: MAC based filters and DHCP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 The answer is that you can do that in 2.0 and 3.0 - just write host declarations, as described in the documentation and in the sample dhcpd.conf file (don't put in a fixed-address declaration if you don't need one), and then write "deny unknown-clients;" at the top of the configuration file. If you need to ignore requests based on the first three bytes of the MAC address, you'd do that like so (only in 3.0): if substring (hardware, 1, 3) = xx:xx:xx { deny booting; } Where xx:xx:xx is the three-byte manufacturer code. If you're going to support a lot of manufacturer codes, I'd suggest this: class "ignore" { match substring (hardware, 1, 3); deny booting; } subclass "ignore" xx:xx:xx; subclass "ignore" yy:yy:yy; et cetera. The advantage of the last choice, for large numbers of manufacturer IDs, is that the comparison is hashed, so you don't have to compare as many keys, and so it's quicker. I thought I'd replied to you last time I saw your query - I'm sorry if I didn't! :'} _MelloN_ From dhcp-v4@bucknell.edu Tue Oct 26 17:05: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 RAA27398 for ; Tue, 26 Oct 1999 17:05: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 RAA16743; Tue, 26 Oct 1999 17:04:00 -0400 (EDT) Date: Tue, 26 Oct 1999 17:04:00 -0400 (EDT) Message-Id: <199910262006.QAA02786@grosse.manhattan.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: Comments on draft-ietf-dnsind-dhcp-rr-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > As far an encrypting the MAC, I agree with your approach. Indeed, for > privacy concerns, the encrypted result could change every time the IP was > renewed (which addresses some of the privacy issues) providing that all the > other DHCP servers in the "group" could decode it (a public key algorithm > with random 'stuff' added to the MAC?). I think the record has to have a predictably constant value. Probably TRT is to hash the client MAC with some shared secret key and stuff the output of the hash in the DNS. _MelloN_ From dhcp-v4@bucknell.edu Tue Oct 26 18:22:48 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02052 for ; Tue, 26 Oct 1999 18:22: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 SAA32666; Tue, 26 Oct 1999 18:21:27 -0400 (EDT) Date: Tue, 26 Oct 1999 18:21:27 -0400 (EDT) Message-Id: <2D97764EC014D311BFD5006094A3E712027A96D3@HONTS326.homeoffice.wal-mart.com> Errors-To: droms@bucknell.edu Reply-To: dblane@wal-mart.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Diana Lane To: Multiple recipients of list Subject: RE: Comments on draft-ietf-dnsind-dhcp-rr-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; X-Mailer: Internet Mail Service (5.5.2650.21) Mime-Version: 1.0 Mark, You wrote: > The reason this draft got proposed is that the DNS guys >*really* don't like the DHCP-DNS use of the KEY record, and we'd like >for there to be an alternative. That's an interesting statement - I wish some of "the DNS guys" who've sent me comments over the last year had mentioned their objections. I've had comments, some extensive and some brief, from all of the DNS WG chairs, among others who regularly contribute in DNSIND. Until now, I have not supposed that the use of the KEY RR for this purpose appeared particularly controversial. The KEY RR is explicitly specified (it has 'protocol' and 'algorithm' fields which are available for assignment by iana) to support extensibility. I don't believe that I've proposed an "overloaded" form of the KEY RR; I've just proposed extending it in the way that it supports. While I'm not a DNS "guy," ;-) we had a discussion back in June (there was also a discussion on another list in April) in which I was concerned about the ramifications of the following type of environment: zone master for "example.com" runs BIND 8.x, supports KEY RR, etc. zone slaves for "example.com" run BIND 4.x, do not understand KEY RR, etc. zone master accepts dynamic updates from DHCP servers, which use KEY RR to distinguish the "owner" of a name What happens to the slaves when they go to do a zone transfer? Your response was, in a nutshell, that the number of organizations with many servers to upgrade and a long upgrade cycle was too small for this to be a global concern, and as I saw only one or two other people voicing the same concern, I dropped this, for the time being focusing on home-grown protections. Your assertion that your proposal does not involve "overloading" the KEY RR but rather "extending" it leaves me nonplussed, however. How does overloading differ from extending? If you have time, I would like to be enlightened (this can be offline if it is inappropriate online). However, in the same vein, I would not like to be dependent on a new RR type that does not yet exist, such as has been proposed. That would put both standardized protection and server level-setting even farther into the future. Thanks! Diana Lane IP Research & Development Wal-Mart Stores, Inc. 501/277-3177 Be gentle to all, and stern with yourself. - Teresa of Avila From dhcp-v4@bucknell.edu Tue Oct 26 23:53: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 XAA17627 for ; Tue, 26 Oct 1999 23:53: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 XAA29697; Tue, 26 Oct 1999 23:52:29 -0400 (EDT) Date: Tue, 26 Oct 1999 23:52:29 -0400 (EDT) Message-Id: <4.1.19991026220025.00adc600@localhost> Errors-To: droms@bucknell.edu Reply-To: ogud@tislabs.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Olafur Gudmundsson To: Multiple recipients of list Subject: Re: Comments on draft-ietf-dnsind-dhcp-rr-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.1 At 02:43 PM 10/26/99 , Mark Stapp wrote: >Ted, > In order to get this out, I have not had enough time to check my writing I apologize for any overly strong comments and muddled arguments that may be in here, but some of us can not write as well and fast as Ted ;-) >At 11:54 AM 10/26/1999 -0400, Ted Lemon wrote: > >>Hm. I see your point WRT seperate servers, and I think a hash is the >>right solution for obfuscation. Unfortunately, this still means we >>need to fix the DHCP RRtype. >> >> > > The reason this draft got proposed is that the DNS guys >> > >*really* don't like the DHCP-DNS use of the KEY record, and we'd like >> > >for there to be an alternative. >> > >> > That's an interesting statement - I wish some of "the DNS guys" who've >> sent >> > me comments over the last year had mentioned their objections. >> >>Sigh. This may be partially my fault - I objected to the use of the >>KEY record, and mentioned it verbally on a number of occasions, >>possibly even within your earshot, but never wrote up a formal >>counterproposal. I also didn't point it out to the ISC DNS hackers, >>so they may not have been aware of it until recently - I'm not sure. This is also my fault, I knew about the work and disagreed with it but did not forward you my comments, sorry. >> >> > I don't believe that I've proposed an "overloaded" form of the KEY >> > RR; I've just proposed extending it in the way that it supports. >> >>I think maybe Andreas should respond to this. Your use of the KEY >>record seems incorrect to me, but I'm by no means the expert. Key is for Public Key material, you want to stick arbitrary binary (or some other data) into it. BAD! > > >I guess I still don't understand what your objection is. I thought your >first mail said that it was the "DNS guys" who objected. This message >suggests that no one else objected until you objected. But you also ask >Andreas to respond with the details of the objection, saying that my >proposal merely "seems incorrect" to you. Well before we start throwing rocks at each other, if you re-read the Abstract of your Internet draft (the June version) there is NO indication that the draft defines new a DHCP options OR proposes overloading of existing DNS records. In the process of figuring a bigger mess, that is Dynamic update and secure dynamic update in DNS (mainly in the context of Bind-9) Andreas, Ted, me and few others talked about the issues involved. DHCP is not the only customer of Dynamic update, and things must be looked at in a global sense as well as local one, one of the important issues that needs to be addressed is how will this fit in with the security mechanism selected for DNS dynamic update, if mechanism selected is friendly to the requirements of DHCP then that changes things. The DHCP-DNS draft has been around for a long time and been updated many times but one of the problems it has run up against is that most people do not know or agree on all the requirements from both DNS or DHCP perspectives. I (as the DNSIND working group co-chair) encouraged Andreas to document his ideas and put them forward, because of his experience in implementing both DNS and DHCP servers. My hope was to start an intelligent discussion on the topic and help us all come to an agreement faster, by having a counterproposal on the table it is easier to judge the merits of the two proposals. > >Never mind the "formal counterproposal": if you're the one who objects, you >should state your objection clearly so that we can evaluate it and respond >to it. I've stated pretty clearly that the chapter and verse that defines >the KEY RR supports extending it, and that that's all I think we should do: >we should use the RR the way that it's specified. Do you read the >specification differently? Why add extensibility to the KEY RR if no one's >allowed to extend it? Ted and Andreas are not the only one's arguing but even if they where the only ones that in my opinion is enough to take a step back and think, neither one of them is an troublemaker. At this point I'm not allowing any drafts to enter as official DNSIND working group documents that in any way extend or modify the KEY, SIG and NXT records unless the change is deemed beneficial to DNS and DNSSEC. Overloading of KEY record with random data is not beneficial. The KEY record is extensible to accommodate NEW KEY algorithms, not random data, the SINK record is for that. Side bar: SINK record is now in WG last call, so far all the comments received have been against advancing that proposal. > >> > There are, unfortunately, two problems with a new RR type: There are the same problems with any solution. >> > >> > 1) it creates a significant deployment barrier for any installations with >> > pre-9.0 BIND servers (I'll assume that 9 could be taught about a proposed >> > new RR type). >> >>Adding RRtypes is not difficult. Given that DNS update support >>wasn't even available until BIND 8.2, which is a very recent release, >>I don't think this should be considered a major impediment. I can't >>see why this can't be available in the next release of BIND 8 >>(although having said this may elicit flamage from my colleagues in >>BIND-8-land... :') > > >You can't add new RR types without requiring that the sites that want to >use them upgrade all of their BIND servers. That's not a flame, but it is >an impediment to deployment. This is a well-known problem, and the only >solution is a BIND transplant. That's why flexible, extensible RRs like the >KEY RR are useful: new uses can be found that are backwards-compatible (at >least back as far as 4.9.5 or maybe 4.9.2), and that can be deployed promptly. > If you check the code you will notice that bind-4.9.x and Bind-8.1 and Bind-8.2.x will not load KEY algorithms that they do not know. Thus such servers can not be used as primary or secondary for zones with DHCP overloaded KEY record. Thus your argument is not valid. > > >> > The number of sites that will have difficulty deploying the current >> > proposal is much smaller. Using the KEY RR would allow the DHCP >> > community to begin deploying useful functionality promptly. >> >>I think doing things the right way is better than doing things the >>expedient way. > >Frankly, I don't think that I've made an "expedient" proposal. I've made a >proposal that complies with the DNS protocol specifications for the KEY RR, >and that's a practical solution to the need we have. I beg to differ, we need to think about the semantics of record that is used by DHCP, can there be one and only one record of this kind, or can there be many ? If the requested semantics are one and only one then mucking with the KEY record or any other existing record will not achieve your goal. A new type for DHCP specific use on the other hand can have the right semantics attached to it. > > >> > 2) it creates a dependency between the dhcp-dns draft and a brand-new >> draft >> > that has to make its way through the DNS WG. >> >>That's true, but doesn't mean that a new RRtype is the wrong way to >>go. The dependency exists any way as some draft will have to explain how to store the data in the key record that draft would have to be processed by the DNS working group. The DNS working group can process drafts of new types in short order. The only thing I can not guarantee is the result up or down. > >Certainly: but using the KEY RR suffers no demonstrated disadvantages, >works technically, and can be deployed readily. I'd like to see from you >why a new RR must be deployed to support the dhcp-dns draft. Just because >we can initiate the process of inventing a new RR doesn't mean that we have >to do so in order to provide the capabilities that the dhcp-dns draft >describes. Please state your objection to the proposal that's on the table, >and let's see whether there's consensus in the WG that it's insurmountable. > >-- Mark > The object of the exercise is to DO THE RIGHT THING, not do what seemed like a good idea at some point. The whole ID process it to foster ideas and allow differences to be evaluated. I stated my objections and technical reasons above, in addition I want to point out the following: Your draft as it is now uses an appendix to hint at the use of the KEY record and has algorithm as TBD. To get any reservation will require interaction with the DNSIND working group or it's successor. Your document will have to go through IETF last call at some point, it is better to get the dialogue over with now, than during IETF last call. I hope we can discuss and resolve this issue before the end of the IETF. Olafur (speaking as the DNS??? WG chair) ---------------------------------------------------- Olafur Gudmundsson - NAI Labs (443)-259-2389 the Security Research Division of Network Associates, Inc. 3060 Wasthington Road, Rt 97, Glenwood MD 21738 ogud@tislabs.com Olafur_Gudmundsson@nai.com Private: ogud@acm.org From dhcp-v4@bucknell.edu Wed Oct 27 09:47:32 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12011 for ; Wed, 27 Oct 1999 09:47:31 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA26670; Wed, 27 Oct 1999 09:46:45 -0400 (EDT) Date: Wed, 27 Oct 1999 09:46:45 -0400 (EDT) Message-Id: <199910271258.IAA28936@mail.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: I-D ACTION:draft-ietf-dhc-authentication-12.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Authentication for DHCP Messages Author(s) : R. Droms, W. Arbaugh Filename : draft-ietf-dhc-authentication-12.txt Pages : 16 Date : 26-Oct-99 The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. In some situations, network administrators may wish to constrain the allocation of addresses to authorized hosts. Additionally, some network administrators may wish to provide for authentication of the source and contents of DHCP messages. This document defines a new DHCP option through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-authentication-12.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-authentication-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-authentication-12.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: <19991026145042.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-authentication-12.txt From dhcp-v4@bucknell.edu Wed Oct 27 09:50: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 JAA12097 for ; Wed, 27 Oct 1999 09:50:21 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA02033; Wed, 27 Oct 1999 09:49:28 -0400 (EDT) Date: Wed, 27 Oct 1999 09:49:28 -0400 (EDT) Message-Id: <4.2.0.58.19991027092451.01df3960@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: mjs@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Mark Stapp To: Multiple recipients of list Subject: Re: Comments on draft-ietf-dnsind-dhcp-rr-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"; format=flowed Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Yes, any 'randomness' would have to be generated identically among all the parties who needed to transform a given client-id in order to compare it to RR contents. That's probably more complication than is necessary. -- Mark At 05:04 PM 10/26/1999 -0400, Ted Lemon wrote: > > As far an encrypting the MAC, I agree with your approach. Indeed, for > > privacy concerns, the encrypted result could change every time the IP was > > renewed (which addresses some of the privacy issues) providing that all the > > other DHCP servers in the "group" could decode it (a public key algorithm > > with random 'stuff' added to the MAC?). > >I think the record has to have a predictably constant value. >Probably TRT is to hash the client MAC with some shared secret key and >stuff the output of the hash in the DNS. > > _MelloN_ From dhcp-v4@bucknell.edu Wed Oct 27 11:10:01 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15967 for ; Wed, 27 Oct 1999 11:10: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 LAA00833; Wed, 27 Oct 1999 11:08:43 -0400 (EDT) Date: Wed, 27 Oct 1999 11:08:43 -0400 (EDT) Message-Id: <5104D4DBC598D211B5FE0000F8FE7EB204087185@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: open issues on User Class draft 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'd like to start discussing open issues wrt the User Class draft. 1) General This version is the result of merging two different drafts: one defining the concept of User Class and one proposing to use User Class for address assignment; I'd like to have the opinion of the people on this list on this new version. One general question that I have is: how much should be standardised and how much should be matter of policy and server implementation? 2) Specific issues: - one important issue is support for multiple User Classes. Please see section 6 of the draft. - another discussion item is how a server should deal with competing option values (see end of section 5). Thanks, Jerome BT From dhcp-v4@bucknell.edu Wed Oct 27 12:25: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 MAA20720 for ; Wed, 27 Oct 1999 12:25: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 MAA10894; Wed, 27 Oct 1999 12:23:06 -0400 (EDT) Date: Wed, 27 Oct 1999 12:23:06 -0400 (EDT) Message-Id: <4.2.0.58.19991027090819.01def670@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: mjs@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Mark Stapp To: Multiple recipients of list Subject: Re: Comments on draft-ietf-dnsind-dhcp-rr-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"; format=flowed Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Olafur, Thanks for your extremely direct and clear response: you've nothing to apologize for in the effective email department. If anyone deserves an apology, it sounds as if it's Ted and Andreas. I didn't mean to dismiss anyone as a idle troublemaker, to try to end-run around issues that are the responsibility of DNSEXT, or to avoid the right thing. I didn't understand Ted's original objection, not having been party to the discussions that have clearly been taking place. I thought that I'd proposed something that was reasonable, and that enough folks had reviewed that proposal over the last year to have revealed any fundamental mistakes. The objections you raise to the use of KEY *are* fundamental. If the current dhcp-dns draft (there is a new one, but it hasn't cleared customs yet this week) doesn't use the right RR, I'll revise it to refer to the new DHCP RR. That won't be published before Washington, obviously, but I'll bring it along and see if I can post it somewhere. I'll also add a section describing the MAC/client-id privacy issue, and an optional method for encrypting that data. Andreas: could we chat about the DHCP RR's RDATA format? I think it might need to include a version, and it probably should be composed of binary data that's CLVs so it can be extended in the future. The section of dhcp-rr titled "DHCP RDATA Format" suggests that the format of the RDATA might need to be specified in the DHCP RR draft, but it also says that DNS software should consider it opaque. May I send you some sample words? Or can your draft just reference the DHCP-DNS draft, and leave the specification of the RR's contents to a draft or RFC that is in the DHC group? Thanks, Mark At 11:18 PM 10/26/1999 -0400, Olafur Gudmundsson wrote: >At 02:43 PM 10/26/99 , Mark Stapp wrote: > >Ted, > > >In order to get this out, I have not had enough time to check my writing >I apologize for any overly strong comments and muddled arguments that >may be in here, but some of us can not write as well and fast as Ted ;-) > > >At 11:54 AM 10/26/1999 -0400, Ted Lemon wrote: > > > >>Hm. I see your point WRT seperate servers, and I think a hash is the > >>right solution for obfuscation. Unfortunately, this still means we > >>need to fix the DHCP RRtype. > >> > >> > > The reason this draft got proposed is that the DNS guys > >> > >*really* don't like the DHCP-DNS use of the KEY record, and we'd like > >> > >for there to be an alternative. > >> > > >> > That's an interesting statement - I wish some of "the DNS guys" who've > >> sent > >> > me comments over the last year had mentioned their objections. > >> > >>Sigh. This may be partially my fault - I objected to the use of the > >>KEY record, and mentioned it verbally on a number of occasions, > >>possibly even within your earshot, but never wrote up a formal > >>counterproposal. I also didn't point it out to the ISC DNS hackers, > >>so they may not have been aware of it until recently - I'm not sure. > >This is also my fault, I knew about the work and disagreed with it >but did not forward you my comments, sorry. > > >> > >> > I don't believe that I've proposed an "overloaded" form of the KEY > >> > RR; I've just proposed extending it in the way that it supports. > >> > >>I think maybe Andreas should respond to this. Your use of the KEY > >>record seems incorrect to me, but I'm by no means the expert. > >Key is for Public Key material, you want to stick arbitrary binary (or >some other data) into it. BAD! > > > > > > > >I guess I still don't understand what your objection is. I thought your > >first mail said that it was the "DNS guys" who objected. This message > >suggests that no one else objected until you objected. But you also ask > >Andreas to respond with the details of the objection, saying that my > >proposal merely "seems incorrect" to you. > >Well before we start throwing rocks at each other, if you re-read the >Abstract of your Internet draft (the June version) there is NO >indication that the draft defines new a DHCP options OR proposes >overloading of existing DNS records. > >In the process of figuring a bigger mess, that is Dynamic update and >secure dynamic update in DNS (mainly in the context of Bind-9) >Andreas, Ted, me and few others talked about the issues involved. >DHCP is not the only customer of Dynamic update, and things must be looked at >in a global sense as well as local one, one of the important issues that >needs to be addressed is how will this fit in with the security mechanism >selected for DNS dynamic update, if mechanism selected is friendly to >the requirements of DHCP then that changes things. > >The DHCP-DNS draft has been around for a long time and been updated many >times but one of the problems it has run up against is that most people do >not know or agree on all the requirements from both DNS or DHCP >perspectives. > >I (as the DNSIND working group co-chair) encouraged Andreas to >document his ideas and put them forward, because of his experience in >implementing both DNS and DHCP servers. >My hope was to start an intelligent discussion on the topic and help us >all come to an agreement faster, by having a counterproposal on the table >it is easier to judge the merits of the two proposals. > > > > >Never mind the "formal counterproposal": if you're the one who objects, you > >should state your objection clearly so that we can evaluate it and respond > >to it. I've stated pretty clearly that the chapter and verse that defines > >the KEY RR supports extending it, and that that's all I think we should do: > >we should use the RR the way that it's specified. Do you read the > >specification differently? Why add extensibility to the KEY RR if no one's > >allowed to extend it? > >Ted and Andreas are not the only one's arguing but even if they where the >only ones that in my opinion is enough to take a step back and think, >neither one of them is an troublemaker. > >At this point I'm not allowing any drafts to enter as official DNSIND working >group documents that in any way extend or modify the KEY, SIG and NXT records >unless the change is deemed beneficial to DNS and DNSSEC. >Overloading of KEY record with random data is not beneficial. >The KEY record is extensible to accommodate NEW KEY algorithms, >not random data, the SINK record is for that. >Side bar: SINK record is now in WG last call, so far all the comments received >have been against advancing that proposal. > > > > > >> > There are, unfortunately, two problems with a new RR type: > >There are the same problems with any solution. > > >> > > >> > 1) it creates a significant deployment barrier for any installations > with > >> > pre-9.0 BIND servers (I'll assume that 9 could be taught about a > proposed > >> > new RR type). > >> > >>Adding RRtypes is not difficult. Given that DNS update support > >>wasn't even available until BIND 8.2, which is a very recent release, > >>I don't think this should be considered a major impediment. I can't > >>see why this can't be available in the next release of BIND 8 > >>(although having said this may elicit flamage from my colleagues in > >>BIND-8-land... :') > > > > > >You can't add new RR types without requiring that the sites that want to > >use them upgrade all of their BIND servers. That's not a flame, but it is > >an impediment to deployment. This is a well-known problem, and the only > >solution is a BIND transplant. That's why flexible, extensible RRs like the > >KEY RR are useful: new uses can be found that are backwards-compatible (at > >least back as far as 4.9.5 or maybe 4.9.2), and that can be deployed > promptly. > > > >If you check the code you will notice that bind-4.9.x and Bind-8.1 and >Bind-8.2.x will not load KEY algorithms that they do not know. >Thus such servers can not be used as primary or secondary for zones >with DHCP overloaded KEY record. Thus your argument is not valid. > > > > > > >> > The number of sites that will have difficulty deploying the current > >> > proposal is much smaller. Using the KEY RR would allow the DHCP > >> > community to begin deploying useful functionality promptly. > >> > >>I think doing things the right way is better than doing things the > >>expedient way. > > > >Frankly, I don't think that I've made an "expedient" proposal. I've made a > >proposal that complies with the DNS protocol specifications for the KEY RR, > >and that's a practical solution to the need we have. > >I beg to differ, we need to think about the semantics of record that >is used by DHCP, can there be one and only one record of this kind, or >can there be many ? >If the requested semantics are one and only one then mucking with the KEY >record or any other existing record will not achieve your goal. A new type >for DHCP specific use on the other hand can have the right semantics >attached to it. > > > > > > >> > 2) it creates a dependency between the dhcp-dns draft and a brand-new > >> draft > >> > that has to make its way through the DNS WG. > >> > >>That's true, but doesn't mean that a new RRtype is the wrong way to > >>go. > >The dependency exists any way as some draft will have to explain how >to store the data in the key record that draft would have to be processed >by the DNS working group. >The DNS working group can process drafts of new types in short order. >The only thing I can not guarantee is the result up or down. > > > > > >Certainly: but using the KEY RR suffers no demonstrated disadvantages, > >works technically, and can be deployed readily. I'd like to see from you > >why a new RR must be deployed to support the dhcp-dns draft. Just because > >we can initiate the process of inventing a new RR doesn't mean that we have > >to do so in order to provide the capabilities that the dhcp-dns draft > >describes. Please state your objection to the proposal that's on the table, > >and let's see whether there's consensus in the WG that it's insurmountable. > > > >-- Mark > > > >The object of the exercise is to DO THE RIGHT THING, not do what seemed >like a good idea at some point. The whole ID process it to foster >ideas and allow differences to be evaluated. > >I stated my objections and technical reasons above, >in addition I want to point out the following: >Your draft as it is now uses an appendix to hint at the use of the KEY >record and has algorithm as TBD. To get any reservation will require >interaction with the DNSIND working group or it's successor. >Your document will have to go through IETF last call at some point, >it is better to get the dialogue over with now, than during IETF last call. > >I hope we can discuss and resolve this issue before the end of the IETF. > > Olafur (speaking as the DNS??? WG chair) >---------------------------------------------------- >Olafur Gudmundsson - NAI Labs (443)-259-2389 >the Security Research Division of Network Associates, Inc. >3060 Wasthington Road, Rt 97, Glenwood MD 21738 >ogud@tislabs.com Olafur_Gudmundsson@nai.com Private: ogud@acm.org > From dhcp-v4@bucknell.edu Wed Oct 27 15:23: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 PAA02138 for ; Wed, 27 Oct 1999 15:23: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 PAA07112; Wed, 27 Oct 1999 15:21:32 -0400 (EDT) Date: Wed, 27 Oct 1999 15:21:32 -0400 (EDT) Message-Id: <199910271818.LAA12597@gulag.araneus.fi> Errors-To: droms@bucknell.edu Reply-To: gson@iengines.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: gson@iengines.com (Andreas Gustafsson) To: Multiple recipients of list Subject: Re: Comments on draft-ietf-dnsind-dhcp-rr-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > Andreas: could we chat about the DHCP RR's RDATA format? I think it might > need to include a version, and it probably should be composed of binary > data that's CLVs so it can be extended in the future. I also think it should be extendable. When using the DHCP RR to store multiple kinds of DHCP information , I would prefer to use multiple DHCP records rather than a single DHCP RR containing multiple key-value pairs. That's the traditional DNS way, and it also makes the explicit LENGTH field unnecessary. I don't think an explicit version field is necessary, either. An RDATA format like this one should suffice: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | SUBTYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| / DATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ The interpretation of DATA depends on the value of SUBTYPE (or CODE, if you prefer that terminology). E.g., SUBTYPE = 0000 (hex) Reserved, not to be allocated. SUBTYPE = 0001 (hex) Hashed client identification. DATA is the 16-byte MD5 hash of the client-id DHCP option data received from the client, excluding the code and length bytes. [This section should also specify the method used to synthesize a client-id option for clients that did not send one.] SUBTYPE = 0002 ... FFFF (hex) To be allocated by IANA in cooperation with the DHC Working Group. Any kind of CLV or SUBTYPE scheme will of course require a nontrivial "IANA Considerations" section in whatever draft/RFC it is specified in... > The section of > dhcp-rr titled "DHCP RDATA Format" suggests that the format of the RDATA > might need to be specified in the DHCP RR draft, but it also says that DNS > software should consider it opaque. May I send you some sample words? Or > can your draft just reference the DHCP-DNS draft, and leave the > specification of the RR's contents to a draft or RFC that is in the DHC group? I would prefer to leave the detailed specification of the RDATA format to a DHC WG draft; you may consider the above RDATA format suggestion input to that draft. In any case, the RDATA format should remain opaque to the DNS server. No matter what internal structure the DHC WG defines for the RDATA field, its text representation in DNS server zone dumps must continue to be a single hexadecimal string, so that the implementation of the DHCP RR in DNS servers does not have to change as the specification evolves or is extended. -- Andreas Gustafsson, gson@iengines.com From dhcp-v4@bucknell.edu Wed Oct 27 17:22: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 RAA09614 for ; Wed, 27 Oct 1999 17:22: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 RAA22392; Wed, 27 Oct 1999 17:20:52 -0400 (EDT) Date: Wed, 27 Oct 1999 17:20:52 -0400 (EDT) Message-Id: <199910272035.QAA07037@grosse.manhattan.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: Comments on draft-ietf-dnsind-dhcp-rr-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > I also think it should be extendable. When using the DHCP RR to store > multiple kinds of DHCP information , I would prefer to use multiple > DHCP records rather than a single DHCP RR containing multiple > key-value pairs. OTOH, I think it would really be better to just say what the RR is for, and leave it at that. It should just be an opaque hunk of data, chosen by the DHCP server. Either the DHCP-DNS or the DHCP RR draft should say how the server computes this hunk of data, but otherwise it should be left alone, because this data needs to be usable in an update message as a prerequisite, and if the DHCP server has to do a query to see what the value is first in order to see what to put in the prerequisite, you've kind of defeated its purpose. I guess I could hang with a version number, because the default version could be set in the DHCP server configuration, but I really don't like the idea of being able to store multiple arbitrary hunks of data in the RR that's being used by the DHCP-DNS draft, whatever RR it is that gets used. I don't see any reason for a special DHCP record for storing other client-specific data in the DNS - if people want to store client-specific data in the DNS, the TXT record already does that. _MelloN_ From dhcp-v4@bucknell.edu Thu Oct 28 11:12: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 LAA25532 for ; Thu, 28 Oct 1999 11:12: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 LAA03988; Thu, 28 Oct 1999 11:10:57 -0400 (EDT) Date: Thu, 28 Oct 1999 11:10:57 -0400 (EDT) Message-Id: <199910281503.KAA14536@drawbridge.damark.com> Errors-To: droms@bucknell.edu Reply-To: william.wells@damark.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "william.wells" To: Multiple recipients of list Subject: RE: Comments on draft-ietf-dnsind-dhcp-rr-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain Mime-Version: 1.0 My initial response was that having DHCP update the TXT record would conflict with my usage of the TXT record. But, if DHCP is going to be the thing which created the record in the first place, I wouldn't really have any need to use the TXT record. -- Different/related topic One usage of putting a end-system identifier (ex: encrypted MAC) is the ability to determine if the IP currently assigned really "belongs" to the end-system. For us, this would allow us to manually assign an IP address outside of the normal DHCP pool (perhaps in a "manually assigned" pool known by DHCP but which DHCP leaves alone) and have the server return the manually assigned IP address on a DHCP request from the end-system. Perhaps this capability already exists in some servers. If I can do the manual assignment via a DHCP server, then it could scribble the necessary information into the TXT record; otherwise, I'd need to need to add the information by hand. If done by DHCP, I assume DHCP would allocate one from the pool instead of specifying the entire IP address (?). Note that this is different than using a "BOOTP" style static assignment. If the end-system changes building, DHCP would need to reassign a dynamic IP address as the network changed. All the static assignment algorithms I've seen will continue to deliver the now incorrect IP address. The other big advantage I see of the end-system identifier lies with multiple DHCP servers (redundancy). If one server can look in DNS and determine that the end-system has an existing valid assignment from another DHCP server, it may be possible for the failover DHCP server to renew the least of the original IP address even though its outside if its normal allocation pool. If this were done, it would probably be wise to require that the failover DHCP server(s) know about the allocation pools of the other server(s) and perhaps even that one of the other server(s) allocated the IP address in the first place. > -----Original Message----- > From: Ted Lemon [SMTP:mellon@isc.org] > Sent: Wednesday, October 27, 1999 4:21 PM > To: Multiple recipients of list > Subject: Re: Comments on draft-ietf-dnsind-dhcp-rr-00.txt > > > > I also think it should be extendable. When using the DHCP RR to store > > multiple kinds of DHCP information , I would prefer to use multiple > > DHCP records rather than a single DHCP RR containing multiple > > key-value pairs. > > OTOH, I think it would really be better to just say what the RR is > for, and leave it at that. It should just be an opaque hunk of data, > chosen by the DHCP server. Either the DHCP-DNS or the DHCP RR draft > should say how the server computes this hunk of data, but otherwise it > should be left alone, because this data needs to be usable in an > update message as a prerequisite, and if the DHCP server has to do a > query to see what the value is first in order to see what to put in > the prerequisite, you've kind of defeated its purpose. > > I guess I could hang with a version number, because the default > version could be set in the DHCP server configuration, but I really > don't like the idea of being able to store multiple arbitrary hunks of > data in the RR that's being used by the DHCP-DNS draft, whatever RR it > is that gets used. I don't see any reason for a special DHCP record > for storing other client-specific data in the DNS - if people want to > store client-specific data in the DNS, the TXT record already does > that. > > _MelloN_ From dhcp-v4@bucknell.edu Thu Oct 28 14:21:46 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03163 for ; Thu, 28 Oct 1999 14:21: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 MAA32322; Thu, 28 Oct 1999 12:46:39 -0400 (EDT) Date: Thu, 28 Oct 1999 12:46:39 -0400 (EDT) Message-Id: <199910281614.MAA20670@mail.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: I-D ACTION:draft-ietf-dhc-option-review-and-namespace-01.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : New Option Review Guidelines and Additional Option Namespace Author(s) : M. Carney Filename : draft-ietf-dhc-option-review-and-namespace-01.txt Pages : 13 Date : 27-Oct-99 This document outlines deficiencies that have become evident since RFC 2131 and RFC 2132 were published regarding the allocation of new option codes, the review of drafts covering these new option codes, and the availability of option codes for new parameters. The document then presents proposals for correcting these deficiencies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-option-review-and-namesp ace-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-option-review-and-namespace-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-option-review-and-namespace-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19991027135815.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-option-review-and-namespace-01.txt From dhcp-v4@bucknell.edu Thu Oct 28 14:24: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 OAA03436 for ; Thu, 28 Oct 1999 14:24:20 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA28702; Thu, 28 Oct 1999 12:50:30 -0400 (EDT) Date: Thu, 28 Oct 1999 12:50:30 -0400 (EDT) Message-Id: <199910281615.MAA21423@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-05.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-05.txt Pages : 122 Date : 27-Oct-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-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-failover-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-failover-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19991028064047.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-failover-05.txt From dhcp-v4@bucknell.edu Thu Oct 28 14:27: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 OAA03805 for ; Thu, 28 Oct 1999 14:27: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 MAA20631; Thu, 28 Oct 1999 12:38:43 -0400 (EDT) Date: Thu, 28 Oct 1999 12:38:43 -0400 (EDT) Message-Id: <199910281610.JAA22041@ha1mpk-mail.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 To: Multiple recipients of list Subject: I-D ACTION:draft-gupta-dhcp-auth-01.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_28 SunOS 5.8 sun4u sparc Content-Type: MULTIPART/mixed; BOUNDARY=Husk_of_Hares_807_000 Mime-Version: 1.0 --Husk_of_Hares_807_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: aYnZx/ilQEgKehlivCzfMQ== Looks like a typo (dncp-v4 rather than dhcp-v4) will prevent this announcement from appearing on the DHCP mailing list. This version reflects the feedback I received in Oslo. The draft name is still draft-gupta-* rather than draft-ietf-dhcp-* because I was unable to get it out to the chairs by Oct 15 (as per their request). Hopefully, the next submission of this draft will reflect the name change. In the meantime, please send whatever comments you might have. There are certain unresolved issues (look for paragraphs marked DISCUSSION) that require working group input. thanks for your time, vipul ------------- Begin Forwarded Message ------------- Mime-Version: 1.0 To: IETF-Announce:;@loki.ietf.org CC: dncp-v4@bucknell.edu From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-gupta-dhcp-auth-01.txt Date: Thu, 28 Oct 1999 07:07:55 -0400 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Flexible Authentication for DHCP Messages Author(s) : V. Gupta Filename : draft-gupta-dhcp-auth-01.txt Pages : 12 Date : 27-Oct-99 This memo proposes a new protocol (Protocol 2) for DHCP authentication within the general framework outlined by Droms and Arbaugh [DrAr98]. This protocol supports the use of digital signatures and multiple forms of replay detection in authenticating Dynamic Host Configuration Protocol (DHCP) messages. The use of digital signatures simplifies key management and also allows authentication of mobile clients that roam between different administrative domains. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gupta-dhcp-auth-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-gupta-dhcp-auth-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-gupta-dhcp-auth-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------------- End Forwarded Message ------------- --Husk_of_Hares_807_000 Content-Type: TEXT/plain; name=NoName; charset=us-ascii Content-Description: NoName Content-MD5: Zl5CKCwMKqrq9pphrsuEZA== Content-Type: text/plain Content-ID: <19991027140040.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-gupta-dhcp-auth-01.txt --Husk_of_Hares_807_000 Content-Type: TEXT/plain; name="draft-gupta-dhcp-auth-01.txt"; charset=us-ascii Content-Description: draft-gupta-dhcp-auth-01.txt Content-MD5: HmuJvVNzKZj+QduRvWHidg== Content-Type: text/plain Content-ID: <19991027140040.I-D@ietf.org> --Husk_of_Hares_807_000-- From dhcp-v4@bucknell.edu Fri Oct 29 08:28:01 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20786 for ; Fri, 29 Oct 1999 08:28: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 IAA15888; Fri, 29 Oct 1999 08:27:38 -0400 (EDT) Date: Fri, 29 Oct 1999 08:27:38 -0400 (EDT) Message-Id: <199910291201.IAA16462@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-05.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-05.txt Pages : 122 Date : 27-Oct-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-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-failover-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-failover-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19991029070249.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-failover-05.txt From dhcp-v4@bucknell.edu Fri Oct 29 09:28:48 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24067 for ; Fri, 29 Oct 1999 09:28: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 JAA18128; Fri, 29 Oct 1999 09:27:26 -0400 (EDT) Date: Fri, 29 Oct 1999 09:27:26 -0400 (EDT) Message-Id: <199910291301.JAA13617@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-schema-01.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Schema for LDAP Author(s) : A. Bennett, B. Volz, A. Westerinen Filename : draft-ietf-dhc-schema-01.txt Pages : 30 Date : 28-Oct-99 This document presents an LDAP schema to represent the configuration of the DHCP protocol within a TCP/IP network. It can be used to represent the configuration(s) of an entire enterprise network, a subset of the network, or even a single server A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-schema-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-schema-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-schema-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19991028141705.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-schema-01.txt From dhcp-v4@bucknell.edu Fri Oct 29 13:39:41 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09083 for ; Fri, 29 Oct 1999 13:39:40 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA18194; Fri, 29 Oct 1999 13:38:21 -0400 (EDT) Date: Fri, 29 Oct 1999 13:38:21 -0400 (EDT) Message-Id: <199910291713.NAA17138@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-11.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Interaction between DHCP and DNS Author(s) : M. Stapp, Y. Rekhter Filename : draft-ietf-dhc-dhcp-dns-11.txt Pages : 18 Date : 28-Oct-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-11.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcp-dns-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcp-dns-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19991029091856.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcp-dns-11.txt From dhcp-v4@bucknell.edu Fri Oct 29 14:33:28 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12087 for ; Fri, 29 Oct 1999 14:33: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 OAA06147; Fri, 29 Oct 1999 14:32:33 -0400 (EDT) Date: Fri, 29 Oct 1999 14:32:33 -0400 (EDT) Message-Id: <199910291752.NAA22746@marvel.research.telcordia.com> Errors-To: droms@bucknell.edu Reply-To: subir@mailee.research.telcordia.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Subir Das To: Multiple recipients of list Subject: draft-itsumo-drcp-00.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii Mime-Version: 1.0 Just wanted to let the group know that our draft in now available at: http://www.ietf.cnri.reston.va.us/internet-drafts/draft-itsumo-drcp-00.txt It describes our Dynamic Registration and Configuration Protocol (DRCP). DRCP is basically DHCP modified for roaming users. We will give a brief description of it at the Tuesday morning dhc seession in Washington. We'd really appreciate any feedback or ideas people have. Thanks Subir ******************************************************************************** Subir Das Ofc: MCC 1D-210R Telcordia Technologies Tel: 973 829 4959 (Formerly Bellcore) Fax: 937 829 5888 445, South Street E-mail: subir@research.telcordia.com Morristown, NJ 07960-6438 ******************************************************************************** From dhcp-v4@bucknell.edu Sun Oct 31 17:30: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 RAA03821 for ; Sun, 31 Oct 1999 17:30:08 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA26145; Sun, 31 Oct 1999 17:29:20 -0500 (EST) Date: Sun, 31 Oct 1999 17:29:20 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: I-D ACTION:draft-ietf-dhc-authentication-12.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Authentication for DHCP Messages Author(s) : R. Droms, W. Arbaugh Filename : draft-ietf-dhc-authentication-12.txt Pages : 16 Date : 26-Oct-99 The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. In some situations, network administrators may wish to constrain the allocation of addresses to authorized hosts. Additionally, some network administrators may wish to provide for authentication of the source and contents of DHCP messages. This document defines a new DHCP option through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-authentication-12.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-authentication-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-authentication-12.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: <19991026145042.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-authentication-12.txt From dhcp-v4@bucknell.edu Sun Oct 31 17:34: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 RAA05165 for ; Sun, 31 Oct 1999 17:34:55 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA07000; Sun, 31 Oct 1999 17:34:45 -0500 (EST) Date: Sun, 31 Oct 1999 17:34:45 -0500 (EST) Message-Id: <199910312223.RAA04641@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: X-Server on DHCP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 message sent to dhcp-v4@bucknell.edu by LAMDV@YAHOO.COM follows. ---------------------------------------------------------------- Hi, I was wondering if I can get any tip how to resolve my problem. Currently I am using an X-server software (X-Win32) to connect to my school unix server from home. Before switching to an ISP that has dynamic IP, I was successfully remoted the unix server without any trouble. However, I keep receiving an error message "/usr/openwin/bin/xterm Xt error: Can't open display: MYIP:0" eversince I switch my ISP. I contacted the program vendor but so far has not had any luck following their instruction. I was wondering if any of you have any suggestion for me since I found your email addresses searching for DHCP informations. Thanks in advance for all your help. Best regards, Daniel ===== ----------------------------- She...bewild my heart I know not why Yet, I love her 'til I die ! -William Shakespeare- __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com