From owner-dhcp-v4@bucknell.edu Sun Apr 2 12:50:06 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25261 for ; Sun, 2 Apr 2000 12:50:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA01230; Sun, 2 Apr 2000 12:49:32 -0400 (EDT) Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA03632 for ; Sun, 2 Apr 2000 12:49:11 -0400 (EDT) Received: from droms-mac ([134.82.129.7]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id MAA14419 for ; Sun, 2 Apr 2000 12:49:10 -0400 (EDT) Message-Id: <4.2.2.20000401170732.00a5c240@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sat, 01 Apr 2000 17:13:31 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: WG meeting in Adelaide Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN The WG met in Adelaide for a total of about 3.5 hours over two meetings. I will post minutes of the meetings to the mailing list for review as soon as I have a draft prepared. If you gave a presentation to the WG meting in Adelaide, and you would like to have your slides included in the IETF minutes, please send me a copy (preferably electronic). If you have notes from the meeting that you would be willing to contribute to the meeting minutes, please send them to me. If you'd like to discuss how we might digitally record future DHC WG meetings - for assistance in writing meeting minutes and to make the full meeting available to those unable to attend - please contact me. - Ralph Droms From owner-dhcp-v4@bucknell.edu Mon Apr 3 08:20:13 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16477 for ; Mon, 3 Apr 2000 08:20:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA22961; Mon, 3 Apr 2000 08:19:07 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id IAA31002 for ; Mon, 3 Apr 2000 08:18:46 -0400 (EDT) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id OAA29368 for ; Mon, 3 Apr 2000 14:18:44 +0200 (MET DST) Received: from eed.ericsson.se (dhcp1-69 [164.48.195.69]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id OAA19551 for ; Mon, 3 Apr 2000 14:18:43 +0200 (MET DST) Message-ID: <38E88C0B.9CC02FAB@eed.ericsson.se> Date: Mon, 03 Apr 2000 14:18:19 +0200 From: Juan-Antonio Ibanez X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: Question about RFC2131 and address renewal Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: Juan-Antonio.Ibanez@eed.ericsson.se Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hi, I would like to get some clarification about something not clearly sated in RFC 2131 concerning the address renewal process. Is it possible that in RENEWING or REBINDING state a client receives a different IP address than its current one? I.e. the server decides not to extend the current lease but instead allocates a different address to the client. In RFC 2131, page 32, there is a confusing sentence: "The server may choose not to extend the lease (as a policy decision by the network administrator), but should return a DHCPACK message regardless." If the server does not extend the lease, shouldn't it rather send a DHCPNAK? Thanks in advance, Juan From owner-dhcp-v4@bucknell.edu Tue Apr 4 10:32:51 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04699 for ; Tue, 4 Apr 2000 10:32:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA00236; Tue, 4 Apr 2000 10:26:25 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id KAA10869 for ; Tue, 4 Apr 2000 10:25:48 -0400 (EDT) Received: from grosse.manhattan.fugue.com (user-37kac09.dialup.mindspring.com [207.69.48.9]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id SAA10708; Mon, 3 Apr 2000 18:17:44 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id MAA01461; Mon, 3 Apr 2000 12:24:18 -0700 (MST) Message-Id: <200004031924.MAA01461@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Question about RFC2131 and address renewal In-Reply-To: Message from Juan-Antonio Ibanez of "Mon, 03 Apr 2000 14:18:19 +0200." <38E88C0B.9CC02FAB@eed.ericsson.se> Date: Mon, 03 Apr 2000 12:24:18 -0700 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > In RFC 2131, page 32, there is a confusing sentence: "The server may > choose not to extend the lease (as a policy decision by the network > administrator), but should return a DHCPACK message regardless." If the > server does not extend the lease, shouldn't it rather send a DHCPNAK? It can send a DHCPACK that doesn't extend the lease. A DHCPNAK would force the client to give the address up immediately, which would be wrong if there were still time left on the lease. _MelloN_ From owner-dhcp-v6@bucknell.edu Tue Apr 4 15:55:47 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14268 for ; Tue, 4 Apr 2000 15:55:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA23827; Tue, 4 Apr 2000 15:48:23 -0400 (EDT) Received: from sbcsmtp2.ptss.com (sbcsmtp2.ptss.com [204.107.19.24]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id PAA21213 for ; Tue, 4 Apr 2000 15:43:53 -0400 (EDT) Received: from mail2.pacbell.com (mail2.pacbell.com [129.245.2.18]) by sbcsmtp2.ptss.com (8.8.8/8.8.8) with ESMTP id MAA26137 for ; Tue, 4 Apr 2000 12:42:28 -0700 (PDT) Received: from msgnorth98.ffcrc.pacbell.com .(msgnorth98.ffcrc.pacbell.com [150.234.34.86]) by mail2.PacBell.COM (8.8.5/8.8.5-pb990306) with ESMTP id MAA13425 for ; Tue, 4 Apr 2000 12:43:37 -0700 (PDT) Received: by msgnorth98.ffcrc.pacbell.com with Internet Mail Service (5.5.2650.21) id <22J36VHM>; Tue, 4 Apr 2000 12:43:06 -0700 Message-ID: <11901E11CF13D311B91A0008C7A4F99C01FB1FB2@msgnorth17.ffcrc.pacbell.com> From: "HIBBS, BARR (SBCSI)" To: DHCPv6 discussion list Subject: I'm retiring!! Date: Tue, 4 Apr 2000 12:43:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ralph-- I'm retiring from Pacific*Bell as of this Friday, 7 April. I've been bitten by the "dot-com" bug and will be moving to a startup that is providing global DNS services for the new domain registrars and other large users. I'll still participate in the working group, but my primary focus for the next year will be DNS, so this isn't "good-bye," just a change of focus. See you soon! --Barr From owner-dhcp-v4@bucknell.edu Wed Apr 5 14:19:00 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14164 for ; Wed, 5 Apr 2000 14:18:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA20113; Wed, 5 Apr 2000 14:10:05 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id OAA14350 for ; Wed, 5 Apr 2000 14:09:53 -0400 (EDT) Received: from vaiobean ([204.57.137.66]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id KAA30083; Wed, 5 Apr 2000 10:57:08 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: DHCPv4 discussion list Cc: Subject: Detection of DHCP server failures Date: Wed, 5 Apr 2000 11:12:19 -0700 Message-ID: <000801bf9f2a$7c6cef60$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <200004031924.MAA01461@grosse.manhattan.fugue.com> Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit In the development of failover and load balancing protocols, we have learned that there are many ways that a given service can fail. In the most extreme case, this can include catastrophic hardware failures that take down the entire machine. However, services can also fail in more subtle ways. For example, a process or thread may fail, leaving other processes or threads intact. Or the process or thread may remain intact, but respond incorrectly to queries. Or a hardware subsystem may fail, leaving others intact. In the example of a DHCP server running the DHCP failover protocol, the detection of DHCP failure is tied to the inability to respond to DHCP failover protocol messages. This means that the failover mechanism is not in itself tied to the operation of the DHCP server. This introduces a number of potential problems, including: a. The possibility that the thread or process handling DHCP failover will fail, but not the actual DHCP server process or thread. I believe that the DHCP failover protocol is immune to problems resulting from this. b. The possibility that the DHCP server process or thread will die but not that the DHCP failover thread or process. In this case, failure will not be detected. c. The possibility that the DHCP server will have a failure that may cause it to send out invalid DHCP packets, while the DHCP failover process or thread remains intact. d. The possibility that a partial hardware failure may cripple the DHCP server, while still allowing it to respond to DHCP failover messages. For example, a multi-homed DHCP server could lose a NIC, disabling DHCP service for one or more subnets, without being detected by DHCP failover. The cases described above, plus others that may be imagined, lead me to believe that the DHCP failover mechanism alone cannot provide a reliable mechanism for the true determination of DHCP server health. To provide such a determination it is necessary to use a variety of health monitoring mechanisms, including examination of data from the DHCP server MIB, external monitoring involving submission of "test" DHCPDISCOVER packets, etc. Through these mechanisms, it may be determined that a DHCP server is malfunctioning even though it (and the DHCP Failover protocol) believe it is doing just fine. In this case, it would appear to me that a mechanism may be needed in the DHCP failover protocol for a secondary to indicate to the primary "you're malfunctioning" so that the secondary can take over, even though the primary may think it's operating just fine. From owner-dhcp-v6@bucknell.edu Thu Apr 6 11:03:57 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09541 for ; Thu, 6 Apr 2000 11:03:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA08542; Thu, 6 Apr 2000 10:59:52 -0400 (EDT) Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id KAA29169 for ; Thu, 6 Apr 2000 10:59:44 -0400 (EDT) Received: from droms-mac (pm3mi1-40.uplink.net [209.173.86.41]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id KAA17919 for ; Thu, 6 Apr 2000 10:59:42 -0400 (EDT) Message-Id: <4.2.2.20000406105626.00a53730@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 06 Apr 2000 10:58:59 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: I'm retiring!! In-Reply-To: <11901E11CF13D311B91A0008C7A4F99C01FB1FB2@msgnorth17.ffcrc. pacbell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hey - congratulations! I was offered a position with a startup not too long ago, but decided not to take the plunge. I am changing jobs - at least temporarily - I will be on sabbatical leave next year, and am going to be working with Cisco (formerly American Internet) up in Chelmsford. Confidentially, this is likely going to be a permanent move... We missed you in Adelaide - lots of good cold beverages and no one to take notes in the DHC WG meetings. Hope to see you in Pittsburgh. - Ralph At 12:43 PM 4/4/00 -0700, you wrote: >Ralph-- > >I'm retiring from Pacific*Bell as of this Friday, 7 April. I've been bitten >by the "dot-com" bug and will be moving to a startup that is providing >global DNS services for the new domain registrars and other large users. > >I'll still participate in the working group, but my primary focus for the >next year will be DNS, so this isn't "good-bye," just a change of focus. > >See you soon! > >--Barr From owner-dhcp-v6@bucknell.edu Thu Apr 6 11:53:03 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10210 for ; Thu, 6 Apr 2000 11:53:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA16966; Thu, 6 Apr 2000 11:48:55 -0400 (EDT) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id LAA21486; Thu, 6 Apr 2000 11:48:07 -0400 (EDT) Received: from droms-mac (pm3mi2-35.uplink.net [209.173.86.84]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id LAA17953; Thu, 6 Apr 2000 11:48:05 -0400 (EDT) Message-Id: <4.2.2.20000406113043.00a3f570@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 06 Apr 2000 11:47:41 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Personal move Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Well, due to an unfortunate gaffe, I seem to have unintentionally made an announcement I had intended to make soon. I will be on sabbatical leave from Bucknell during the next academic year, and during that year I will be working with Cisco in Chelmsford. I expect to continue on as DHC WG chair and, in fact, hope to be able to focus more on DHCP issues during the coming year... - Ralph From owner-dhcp-v4@bucknell.edu Thu Apr 6 11:53:50 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10222 for ; Thu, 6 Apr 2000 11:53:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA28688; Thu, 6 Apr 2000 11:48:53 -0400 (EDT) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id LAA21486; Thu, 6 Apr 2000 11:48:07 -0400 (EDT) Received: from droms-mac (pm3mi2-35.uplink.net [209.173.86.84]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id LAA17953; Thu, 6 Apr 2000 11:48:05 -0400 (EDT) Message-Id: <4.2.2.20000406113043.00a3f570@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 06 Apr 2000 11:47:41 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Personal move Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Well, due to an unfortunate gaffe, I seem to have unintentionally made an announcement I had intended to make soon. I will be on sabbatical leave from Bucknell during the next academic year, and during that year I will be working with Cisco in Chelmsford. I expect to continue on as DHC WG chair and, in fact, hope to be able to focus more on DHCP issues during the coming year... - Ralph From owner-dhcp-v4@bucknell.edu Thu Apr 6 12:07:51 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10404 for ; Thu, 6 Apr 2000 12:07:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA30611; Thu, 6 Apr 2000 12:03:48 -0400 (EDT) Received: from sbcsmtp2.ptss.com (sbcsmtp2.ptss.com [204.107.19.24]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA01113 for ; Thu, 6 Apr 2000 12:03:30 -0400 (EDT) Received: from mail2.pacbell.com (mail2.pacbell.com [129.245.2.18]) by sbcsmtp2.ptss.com (8.8.8/8.8.8) with ESMTP id JAA08791 for ; Thu, 6 Apr 2000 09:02:34 -0700 (PDT) Received: from msgnorth98.ffcrc.pacbell.com .(msgnorth98.ffcrc.pacbell.com [150.234.34.86]) by mail2.PacBell.COM (8.8.5/8.8.5-pb990306) with ESMTP id JAA12324 for ; Thu, 6 Apr 2000 09:03:45 -0700 (PDT) Received: by msgnorth98.ffcrc.pacbell.com with Internet Mail Service (5.5.2650.21) id <22J3914P>; Thu, 6 Apr 2000 09:03:13 -0700 Message-ID: <11901E11CF13D311B91A0008C7A4F99C01FB1FB7@msgnorth17.ffcrc.pacbell.com> From: "HIBBS, BARR (SBCSI)" To: DHCPv4 discussion list Subject: RE: Detection of DHCP server failures Date: Thu, 6 Apr 2000 09:03:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: RBHIBBS@msg.pacbell.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > From: Bernard Aboba[SMTP:aboba@internaut.com] > Sent: Wednesday, April 05, 2000 11:12 AM > > In the development of failover and load balancing protocols, > we have learned that there are many ways that a given service > can fail. In the most extreme case, this can include catastrophic > hardware failures that take down the entire machine. However, > services can also fail in more subtle ways. For example, a > process or thread may fail, leaving other processes or > threads intact. Or the process or thread may remain intact, > but respond incorrectly to queries. Or a hardware subsystem > may fail, leaving others intact. > ...I certainly agree with your observation, Bernard, and am pleased you've introduced the topic for discussion. > In the example of a DHCP server running the DHCP failover > protocol, the detection of DHCP failure is tied to the > inability to respond to DHCP failover protocol messages. > This means that the failover mechanism is not in itself > tied to the operation of the DHCP server. > ...yes, but I believe that the mindset was that processing of packets from dhcp clients was not a separate process thread from processing of interserver messages. Kim, can you expand on this? > This introduces a number of potential problems, including: > > a. The possibility that the thread or process handling > DHCP failover will fail, but not the actual DHCP > server process or thread. I believe that the DHCP > failover protocol is immune to problems resulting from > this. > ...why? if there are two independent process threads, they presumably must communicate. If the packet process completely fails, won't its lack of response to the failover process be noticed? But at the same time, if the packet process only partially fails, continuing to respond to the failover process but not to client packets, how would the failover process detect this? > b. The possibility that the DHCP server process or thread > will die but not that the DHCP failover thread or > process. In this case, failure will not be detected. > ...I don't think you've stated this correctly. See my comments above. > c. The possibility that the DHCP server will have a failure > that may cause it to send out invalid DHCP packets, > while the DHCP failover process or thread remains > intact. > ...again, how can this be detected? If the packet process is sending and receiving data, the obvious signs of process health such as advancing message counters won't reveal a problem, and if the packet process and failover process continue to communicate, the failover process could easily be fooled. > d. The possibility that a partial hardware failure may > cripple the DHCP server, while still allowing it to > respond to DHCP failover messages. For example, a > multi-homed DHCP server could lose a NIC, disabling > DHCP service for one or more subnets, without being > detected by DHCP failover. > ...yes, but this is no different from some types of hardware failures that might go undetected in a non-failover server. For example, I rely on the networking software to report failure or completion of send requests. Suppose the NIC suddenly failed such that data was shifted out of the transmit registers, but not actually written on the wire. That would likely not be detected by the network layer, so the server would not detect a send failure. > The cases described above, plus others that may be imagined, > lead me to believe that the DHCP failover mechanism alone > cannot provide a reliable mechanism for the true determination > of DHCP server health. > > To provide such a determination it is necessary to use a variety > of health monitoring mechanisms, including examination of data > from the DHCP server MIB, external monitoring involving submission > of "test" DHCPDISCOVER packets, etc. > > Through these mechanisms, it may be determined that a DHCP server > is malfunctioning even though it (and the DHCP Failover protocol) > believe it is doing just fine. > > In this case, it would appear to me that a mechanism may be needed > in the DHCP failover protocol for a secondary to indicate to the > primary "you're malfunctioning" so that the secondary can take over, > even though the primary may think it's operating just fine. > Agreed! I'm not sure that this is something that is appropriate for an RFC though, as the methods for detection of various failures are very much system-specific. --Barr From owner-dhcp-v4@bucknell.edu Thu Apr 6 13:02:04 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11423 for ; Thu, 6 Apr 2000 13:02:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA00916; Thu, 6 Apr 2000 12:53:20 -0400 (EDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA27518 for ; Thu, 6 Apr 2000 12:50:58 -0400 (EDT) Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Thu, 6 Apr 2000 11:46:22 -0500 Received: from zcard00b.ca.nortel.com ([47.128.208.105]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2M702NT1; Thu, 6 Apr 2000 12:46:20 -0400 Received: from NET-DPARKINSON ([141.251.81.87]) by zcard00b.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HR1A0V7T; Thu, 6 Apr 2000 12:46:19 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Dean Parkinson" To: DHCPv4 discussion list Subject: Renew after a move to another subnet while powered up Date: Thu, 6 Apr 2000 12:47:27 -0400 Message-ID: <002701bf9fe7$ca56c850$5751fb8d@net-dparkinson.corpnorth.baynetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Reply-To: dparkins@nortelnetworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit I would like to know whether a DHCP Server should send a NAK if a client moves from one subnet to another while still powered up and the renew is sent from the client to the server at the proper time (1/2 the lease time). Here is the scenario. I have two subnets and each have a range that is served by the same DHCP Server. A laptop is plugged into one of the subnets and is started. The lease that is given out to the client is for 1 hour. Five minutes later the laptop is unplugged and plugged back in to a connection on the second subnet. The user did not shut the machine down. They just unplugged the network cable, moved to say an adjacent office, and plugged back in. However, the new connection is on another subnet from the first. When another 25 minutes goes by the laptop does a renew. At this point I would like to know what the DHCP server should do. Should it send a NAK, should it stay silent or should it send an OFFER? In your response could you please indicate where in RFC 2131 it gives the proper behaviour? Thanks, Dean Parkinson From owner-dhcp-v4@bucknell.edu Thu Apr 6 15:10:23 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13272 for ; Thu, 6 Apr 2000 15:10:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA06397; Thu, 6 Apr 2000 15:02:13 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id PAA03048 for ; Thu, 6 Apr 2000 15:01:23 -0400 (EDT) Received: from grosse.manhattan.fugue.com (user-37kac0k.dialup.mindspring.com [207.69.48.20]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id WAA19055; Wed, 5 Apr 2000 22:53:12 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id MAA02784; Thu, 6 Apr 2000 12:00:28 -0700 (MST) Message-Id: <200004061900.MAA02784@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Renew after a move to another subnet while powered up In-Reply-To: Message from "Dean Parkinson" of "Thu, 06 Apr 2000 12:47:27 -0400." <002701bf9fe7$ca56c850$5751fb8d@net-dparkinson.corpnorth.baynetworks.com> Date: Thu, 06 Apr 2000 12:00:28 -0700 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > At this point I would > like to know what the DHCP server should do. Should it send a NAK, should > it stay silent or should it send an OFFER? In your response could you > please indicate where in RFC 2131 it gives the proper behaviour? When the client is in the RENEWING state, it's unicasting its DHCPREQUEST, so the server will never see it, because the client can no longer contact its router. If the server *did* for some reason get the DHCPREQUEST message, it would not know from what subnet it came, and therefore would not be able to determine whether or not it should NAK the message. At 85% of the lease duration, the client should go into the REBINDING state, at which point it will broadcast its DHCPREQUEST message. The server will get this message, see that the IP address is wrong for the subnet, and send a DHCPNAK at that time (assuming it's configured correctly). _MelloN_ From owner-dhcp-v4@bucknell.edu Thu Apr 6 15:12:41 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13311 for ; Thu, 6 Apr 2000 15:12:40 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA17753; Thu, 6 Apr 2000 15:07:19 -0400 (EDT) Received: from mail.connectedsystems.com (mail.connectedsystems.com [205.227.183.106]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id PAA26049 for ; Thu, 6 Apr 2000 15:02:37 -0400 (EDT) From: clausen@connsys.com Received: from software-caleb (mail2.connectedsystems.com [205.227.183.98]) by mail.connectedsystems.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HYT6R3DC; Thu, 6 Apr 2000 11:44:42 -0700 To: DHCPv4 discussion list Date: Thu, 6 Apr 2000 12:02:36 -0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: siaddr vs sname vs option 66 Message-ID: <38EC7CDC.32645.51B4519@localhost> Priority: normal X-mailer: Pegasus Mail for Win32 (v3.12c) Reply-To: clausen@connsys.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7BIT i think i have discovered an error in rfc 2132, in the section on option 66. there's an inconsistancy, at any rate. here's what 2132 has to say: > 9.4 TFTP server name > > This option is used to identify a TFTP server when the 'sname' > field in the DHCP header has been used for DHCP options > > The code for this option is 66, and its minimum length is 1. it seems that the intent is to provide a way to communicate the information that the sname field carries when sname has been overloaded using option 52. however, the quote above also implies that sname, when not overloaded, carries the name of the tftp server. this does not agree with what other rfcs have to say on the subject. rfc 2131 says this: > DHCP clarifies the interpretation of the 'siaddr' field as the > address of the server to use in the next step of the client's > bootstrap process. seems pretty clear that siaddr is supposed to be the tftp server name. 2131 doesn't really say anything about the meaning of sname when it's not overloaded, however, the original bootp rfc (951) says: > If the client wishes to restrict booting to a particular server > name, it may place a null-terminated string in 'sname'. The > name used should be any of the allowable names or nicknames of > the desired host. sname is for client-to-server communication, to restrict booting to a particular host. i can find no mention of any meaning for this field if it's set in a packet sent by the server. so given all this, i have the following questions: what field should contain the tftp server name/address: siaddr or sname? if not blank or overloaded, what is the meaning of sname in a dhcp discover or dhcp request? if not blank or overloaded, what is the meaning of sname in a dhcp offer or dhcp ack? is option 66 supposed to be a replacement for sname if sname is overloaded? or is it supposed to really be the tftp server name, as described in the first quote above? if option 66 really is the tftp server name, is this meant to replace siaddr? if both are set in a dhcp ack, which should the client use? "For, I say fortunately, I always carry a spare set of feathers." --Foghorn Leghorn From owner-dhcp-v4@bucknell.edu Thu Apr 6 15:55:54 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13935 for ; Thu, 6 Apr 2000 15:55:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA02771; Thu, 6 Apr 2000 15:49:05 -0400 (EDT) Received: from quadntweb.quadritek.com ([198.200.138.211]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id PAA00986 for ; Thu, 6 Apr 2000 15:48:51 -0400 (EDT) Received: from agrabilnt ([198.200.138.254]) by quadntweb.quadritek.com (Post.Office MTA Undefined release Undefined ID# 0-59484U200L100S0V35) with SMTP id com; Thu, 6 Apr 2000 15:45:54 -0400 From: agrabil@quadritek.com (Greg Rabil) To: DHCPv4 discussion list Subject: RE: siaddr vs sname vs option 66 Date: Thu, 6 Apr 2000 15:47:19 -0400 Message-ID: <00ae01bfa000$eae825f0$fe8ac8c6@quadritek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <38EC7CDC.32645.51B4519@localhost> Reply-To: agrabil@quadritek.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Clausen, As I've been down this road myself, let me try to explain what I've found... Regards, Greg A. Gregory Rabil Team Leader - Network Services Development IP Services Product Group Lucent Technologies, InterNetworking Systems grabil@lucent.com agrabil@quadritek.com > -----Original Message----- > From: owner-dhcp-v4@bucknell.edu [mailto:owner-dhcp-v4@bucknell.edu]On > Behalf Of clausen@connsys.com > Sent: Thursday, April 06, 2000 3:03 PM > To: DHCPv4 discussion list > Subject: siaddr vs sname vs option 66 > > > i think i have discovered an error in rfc 2132, in the section on > option 66. there's an inconsistancy, at any rate. > > here's what 2132 has to say: > > > 9.4 TFTP server name > > > > This option is used to identify a TFTP server when the 'sname' > > field in the DHCP header has been used for DHCP options > > > > The code for this option is 66, and its minimum length is 1. > > it seems that the intent is to provide a way to communicate the > information that the sname field carries when sname has been > overloaded using option 52. > > however, the quote above also implies that sname, when not > overloaded, carries the name of the tftp server. this does not agree > with what other rfcs have to say on the subject. rfc 2131 says this: > > > DHCP clarifies the interpretation of the 'siaddr' field as the > > address of the server to use in the next step of the client's > > bootstrap process. > > seems pretty clear that siaddr is supposed to be the tftp server > name. 2131 doesn't really say anything about the meaning of > sname when it's not overloaded, however, the original bootp rfc > (951) says: > > > If the client wishes to restrict booting to a particular server > > name, it may place a null-terminated string in 'sname'. The > > name used should be any of the allowable names or nicknames of > > the desired host. > > sname is for client-to-server communication, to restrict booting to a > particular host. i can find no mention of any meaning for this field if > it's set in a packet sent by the server. > > so given all this, i have the following questions: > > what field should contain the tftp server name/address: siaddr or > sname? Nearly all clients that I know of will look in the siaddr for the address of the TFTP server. This includes Bootp clients as well as newer DHCP clients that also require TFTP images for bootstrap. > > if not blank or overloaded, what is the meaning of sname in a dhcp > discover or dhcp request? Nothing that I know of. I don't think this value will ever be filled in by a client or relay agent. > > if not blank or overloaded, what is the meaning of sname in a dhcp > offer or dhcp ack? That's a good question. Typically, I put the _name_ of the TFTP server, just to be "compliant" with how I understand the field to be in the protocol (which you've discussed above). > > is option 66 supposed to be a replacement for sname if sname is > overloaded? or is it supposed to really be the tftp server name, as > described in the first quote above? Option 66 is _supposed_ to be the sname, if the sname field has been overloaded with options. However, Microsoft's server will always put the TFTP server name in option 66, so many client vendors have coded to this. > > if option 66 really is the tftp server name, is this meant to replace > siaddr? if both are set in a dhcp ack, which should the client use? > Again, I've yet to see a client that actually uses the sname, they all seem to rely on siaddr, or option 66 in the case where they've only tested with MS-DHCP. > > > "For, I say fortunately, I always carry a spare set > of feathers." > --Foghorn Leghorn > > From owner-dhcp-v4@bucknell.edu Thu Apr 6 17:45:20 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15466 for ; Thu, 6 Apr 2000 17:45:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA17702; Thu, 6 Apr 2000 17:41:00 -0400 (EDT) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id RAA02416 for ; Thu, 6 Apr 2000 17:40:46 -0400 (EDT) Received: from droms-mac (pm3mi3-0.uplink.net [209.173.86.97]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id RAA18103; Thu, 6 Apr 2000 17:40:42 -0400 (EDT) Message-Id: <4.2.2.20000406172735.00a43930@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 06 Apr 2000 17:40:12 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Re: Renew after a move to another subnet while powered up Cc: dhcp-v4@bucknell.edu In-Reply-To: <002701bf9fe7$ca56c850$5751fb8d@net-dparkinson.corpnorth.ba ynetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN As an aside - in theory, the DHCP client on the laptop would be informed that the laptop has been disconnected and reconnected to a network segment (all the interface might know is that carrier was lost for some period of time). The DHCP client would go into INIT-REBOOT state immediately and, through a broadcast REQUEST, the DHCP server can determine if the client is still on the same network segment. In practice, I don't know that any DHCP clients do receive notice from the interface about loss of connectivity... - Ralph At 12:47 PM 4/6/00 -0400, you wrote: >I would like to know whether a DHCP Server should send a NAK if a client >moves from one subnet to another while still powered up and the renew is >sent from the client to the server at the proper time (1/2 the lease time). > >Here is the scenario. > >I have two subnets and each have a range that is served by the same DHCP >Server. A laptop is plugged into one of the subnets and is started. The >lease that is given out to the client is for 1 hour. Five minutes later the >laptop is unplugged and plugged back in to a connection on the second >subnet. The user did not shut the machine down. They just unplugged the >network cable, moved to say an adjacent office, and plugged back in. >However, the new connection is on another subnet from the first. When >another 25 minutes goes by the laptop does a renew. At this point I would >like to know what the DHCP server should do. Should it send a NAK, should >it stay silent or should it send an OFFER? In your response could you >please indicate where in RFC 2131 it gives the proper behaviour? > >Thanks, >Dean Parkinson From owner-dhcp-v4@bucknell.edu Thu Apr 6 18:14:31 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15868 for ; Thu, 6 Apr 2000 18:14:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id SAA12113; Thu, 6 Apr 2000 18:13:05 -0400 (EDT) Received: from alcor.process.com (alcor.process.com [192.42.95.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id SAA20218; Thu, 6 Apr 2000 18:12:51 -0400 (EDT) Received: by process.com (MX V5.1-X A2w8g) id 10; Thu, 6 Apr 2000 18:12:33 -0500 Sender: owner-dhcp-v4@bucknell.edu Date: Thu, 6 Apr 2000 18:12:33 -0500 From: Bernie Volz To: DHCPv4 discussion list CC: DHCP-V4@bucknell.edu Message-ID: <009E837C.247FEC7B.10@process.com> Subject: Re: Renew after a move to another subnet while powered up Reply-To: volz@process.com X-Sender: volz@process.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Windows 2000 (Professional) actually behaves relatively well with respect to this situation. What it does when it detects the cable being plugged back in is to ping the router. If the router is still reachable, it assumes the existing lease is still valid (provided it hasn't reached t1/t2 or the expired time). If the router does not respond, I believe it attempts to renew the lease (not sure exactly what it does here, whether it unicasts first or broadcasts). I've been using Windows 2000 on the laptop for a while, and the DHCP client behaves nicely and handles moving between subnets extremely well. - Bernie Date: Thu, 06 Apr 2000 17:40:12 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Re: Renew after a move to another subnet while powered up As an aside - in theory, the DHCP client on the laptop would be informed that the laptop has been disconnected and reconnected to a network segment (all the interface might know is that carrier was lost for some period of time). The DHCP client would go into INIT-REBOOT state immediately and, through a broadcast REQUEST, the DHCP server can determine if the client is still on the same network segment. In practice, I don't know that any DHCP clients do receive notice from the interface about loss of connectivity... - Ralph From owner-dhcp-v4@bucknell.edu Thu Apr 6 19:34:36 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17082 for ; Thu, 6 Apr 2000 19:34:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id TAA06546; Thu, 6 Apr 2000 19:29:38 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id TAA27743; Thu, 6 Apr 2000 19:29:30 -0400 (EDT) Received: from grosse.manhattan.fugue.com (a9.pm3-33.theriver.com [206.30.150.73]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id DAA21245; Thu, 6 Apr 2000 03:21:24 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id QAA00833; Thu, 6 Apr 2000 16:28:40 -0700 (MST) Message-Id: <200004062328.QAA00833@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Renew after a move to another subnet while powered up In-Reply-To: Message from Ralph Droms of "Thu, 06 Apr 2000 17:40:12 -0400." <4.2.2.20000406172735.00a43930@mail.bucknell.edu> Date: Thu, 06 Apr 2000 16:28:40 -0700 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > In practice, I don't know that any DHCP clients do receive notice from the > interface about loss of connectivity... I think the latest OpenTransport client does. _MelloN_ From owner-dhcp-v4@bucknell.edu Thu Apr 6 22:14:34 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19234 for ; Thu, 6 Apr 2000 22:14:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id WAA29723; Thu, 6 Apr 2000 22:10:24 -0400 (EDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id WAA31545 for ; Thu, 6 Apr 2000 22:10:20 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id TAA29431 for ; Thu, 6 Apr 2000 19:10:19 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 06 Apr 2000 19:10:18 -0700 Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37]) by scv2.apple.com (8.9.3/8.9.3) with SMTP id TAA24497 for ; Thu, 6 Apr 2000 19:10:17 -0700 (PDT) Message-Id: <200004070210.TAA24497@scv2.apple.com> Subject: Re: Renew after a move to another subnet while powered up Date: Thu, 6 Apr 2000 19:10:18 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: DHCPv4 discussion list MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Reply-To: cheshire@apple.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >I would like to know whether a DHCP Server should send a NAK if a client >moves from one subnet to another while still powered up and the renew is >sent from the client to the server at the proper time (1/2 the lease time). The renew request is unicast to the server, so even if the server gets it, the reply will almost certainly not make it back to the client. >At 85% of the lease duration, the client should go into the REBINDING >state, at which point it will broadcast its DHCPREQUEST message. >The server will get this message, see that the IP address is wrong for >the subnet, and send a DHCPNAK at that time (assuming it's configured >correctly). In recent tests, most servers did NOT generate a NAK in this state, though the point is moot, really. A NAK would put the client back into INIT state a little quicker, but by REBINDING time, the client has already been non-functional for almost an hour. The correct solution is to detect the link change as soon as it happens, where possible, and reconfigure immediately. Stuart Cheshire * Web Page * Wizard Without Portfolio, Apple Computer From owner-dhcp-v4@bucknell.edu Thu Apr 6 22:14:38 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19245 for ; Thu, 6 Apr 2000 22:14:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id WAA19411; Thu, 6 Apr 2000 22:12:13 -0400 (EDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id WAA02380 for ; Thu, 6 Apr 2000 22:11:42 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id TAA29536 for ; Thu, 6 Apr 2000 19:11:41 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 6 Apr 2000 19:11:33 -0700 Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id TAA24251 for ; Thu, 6 Apr 2000 19:11:40 -0700 (PDT) Message-Id: <200004070211.TAA24251@scv1.apple.com> Subject: Re: Renew after a move to another subnet while powered up Date: Thu, 6 Apr 2000 19:11:41 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: DHCPv4 discussion list Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Reply-To: cheshire@apple.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >I think the latest OpenTransport client does. > > _MelloN_ The DHCP client in Mac OS Open Transport versions 2.5 and higher will accept a kOTPortNetworkChange message from the Ethernet driver to inform it if a link-state change, and reconfigure a new address if necessary. However, that only works for drivers that generate the message. We're evangelising driver writers to generate this message, but they haven't all got the message yet... Stuart Cheshire * Web Page * Wizard Without Portfolio, Apple Computer From owner-dhcp-v4@bucknell.edu Fri Apr 7 00:25:00 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21636 for ; Fri, 7 Apr 2000 00:24:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id AAA14988; Fri, 7 Apr 2000 00:20:35 -0400 (EDT) Received: from fw-1.phoneware.com.au (fw-1.phoneware.com.au [210.9.15.34]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id AAA12807 for ; Fri, 7 Apr 2000 00:20:20 -0400 (EDT) Received: (qmail 8140 invoked from network); 7 Apr 2000 04:20:00 -0000 Received: from mel.phoneware.com.au (210.9.15.42) by fw-2.phoneware.com.au with SMTP; 7 Apr 2000 04:20:00 -0000 Received: by mel.phoneware.com.au with Internet Mail Service (5.0.1460.8) id <2FDM8NJ2>; Fri, 7 Apr 2000 14:21:51 +1000 Message-ID: <641C3DCFCBECD31180FB0000F8040A78C36A@mel.phoneware.com.au> From: Andrew Wallace To: DHCPv4 discussion list Subject: newbie question, querying dhcp servers (DHCPINFORM?) Date: Fri, 7 Apr 2000 14:21:50 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Reply-To: Andrew_Wallace@phoneware.com.au Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I want to find out the host names associated with an IP address on our network which uses a DHCP server. Can I send a query to a DHCP server that will return a host name from the IP address? If not, is there anyway I can find the host name from the IP in a DHCP environment? Looking at RFC2131 I was wondering what would happen if I send a DCHPINFORM message to the server requesting the hostname details (with the giaddr field to the address that I would like the response sent to). How does this sound? Do any DHCP servers support any sort of IP-to-name resolution? (by the way we're using a Windows NT DHCP server v4.1) I would appreciate any help/thoughts, Thnaks, Andrew Wallace Phoneware Communication Systems Pty Ltd Telephone: (03) 9210 4263 Fax: (03) 9887 6199 Email: andrew_wallace@phoneware.com.au www: http://www.phoneware.com.au From owner-dhcp-v4@bucknell.edu Fri Apr 7 01:08:47 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22631 for ; Fri, 7 Apr 2000 01:08:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id BAA08550; Fri, 7 Apr 2000 01:05:42 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id BAA27006 for ; Fri, 7 Apr 2000 01:05:34 -0400 (EDT) Received: from grosse.manhattan.fugue.com (a10.pm3-29.theriver.com [206.102.195.74]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id IAA22209; Thu, 6 Apr 2000 08:57:22 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id WAA00383; Thu, 6 Apr 2000 22:05:11 -0700 (MST) Message-Id: <200004070505.WAA00383@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: newbie question, querying dhcp servers (DHCPINFORM?) In-Reply-To: Message from Andrew Wallace of "Fri, 07 Apr 2000 14:21:50 +1000." <641C3DCFCBECD31180FB0000F8040A78C36A@mel.phoneware.com.au> Date: Thu, 06 Apr 2000 22:05:11 -0700 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN DHCP doesn't do that - you need DNS. Do a DNS query taking the IP address, reversed, plus .in-addr.arpa. So if your IP address is 1.2.3.4, look up a PTR record for 4.3.2.1.in-addr.arpa. There's no requirement that this be associated with a name, but most network administrators do set up PTR records like this. The nslookup command to do this, BTW, would be: nslookup ... > set type=PTR > 4.3.2.1.in-addr.arpa. ... _MelloN_ From owner-dhcp-v4@bucknell.edu Fri Apr 7 03:07:36 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04002 for ; Fri, 7 Apr 2000 03:07:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id DAA23496; Fri, 7 Apr 2000 03:02:34 -0400 (EDT) Received: from s4.smtp.oleane.net (s4.smtp.oleane.net [195.25.12.14]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id DAA30102 for ; Fri, 7 Apr 2000 03:02:23 -0400 (EDT) Received: from inet.siege.snpe.fr (inet.siege.snpe.fr [62.160.97.1]) by s4.smtp.oleane.net (Postfix) with SMTP id 863DA20AF1 for ; Fri, 7 Apr 2000 08:00:46 +0200 (CEST) Received: inet.siege.snpe.fr Message-ID: From: "ORIGIN (Prest.)" To: DHCPv4 discussion list Subject: unsubscribe DHCPv4 discussion list Date: Fri, 7 Apr 2000 09:01:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Reply-To: ORIGIN@SNPE.COM Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN From owner-dhcp-v4@bucknell.edu Fri Apr 7 04:39:18 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04717 for ; Fri, 7 Apr 2000 04:39:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id EAA22065; Fri, 7 Apr 2000 04:33:30 -0400 (EDT) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id EAA29016 for ; Fri, 7 Apr 2000 04:33:17 -0400 (EDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 07 Apr 2000 14:01:10 +0530 Received: from purushn.future.futsoft.com ([10.0.14.28]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id NAA24521 for ; Fri, 7 Apr 2000 13:40:25 +0530 Received: by localhost with Microsoft MAPI; Fri, 7 Apr 2000 13:49:43 +0530 Message-Id: <01BFA098.20DB9D80.purushn@future.futsoft.com> From: Purushothaman N Reply-To: "purushn@future.futsoft.com" To: DHCPv4 discussion list Subject: unsubscribe DHCPv4 discussion list Date: Fri, 7 Apr 2000 13:49:41 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN From owner-dhcp-v4@bucknell.edu Fri Apr 7 05:29:41 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05182 for ; Fri, 7 Apr 2000 05:29:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id FAA28398; Fri, 7 Apr 2000 05:25:46 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id FAA20712 for ; Fri, 7 Apr 2000 05:25:30 -0400 (EDT) Received: from vaiobean ([204.57.137.66]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id CAA32162; Fri, 7 Apr 2000 02:12:16 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: DHCPv4 discussion list Subject: RE: Detection of DHCP server failures Date: Fri, 7 Apr 2000 02:27:35 -0700 Message-ID: <002c01bfa073$82f990a0$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <009E82B2.B2639FEE.107@process.com> Importance: Normal Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Thanks everyone for the thoughtful responses. >The load balancing draft (most recent version) has >the concept of allowing the "secondary" server to start responding to >requests if it "feels" that the "primary" is not responding in a timely >fashion. This handles some, not all, of the issues you raise. I agree that several (most? all?) of these issues boil down to allowing the secondary to take over due to a "feeling". Some questions are what the "feeling" can result from, whether there are some corner conditions in which this won't work and what the implications are. I agree that timeliness is important. It seems to me that the "feeling" can also come from other sources, such as a secondary looking at retransmissions, from an external monitor sending DHCPDISCOVER packets and analyzing the semantics of the response; or from a management station polling the DHCP server and analyzing data from the DHCP MIB. The "action" may be: the secondary should start responding. Should it inform the primary that it has taken this action? In the case of an external monitor, the observed behavior may indicate a possible malfunction of the primary sufficiently grave as to be worth attempting to shut it down or restart it. This has no protocol implications, however. >I believe that the mindset was that processing of packets from >dhcp clients was not a separate process thread from processing of >interserver messages. Kim, can you expand on this? This is really an implementation issue, but I think that it cannot be necessarily assumed. >But at the same time, if the >packet process only partially fails, continuing to respond to the failover >process but not to client packets, how would the failover process detect >this? It could be detected by other means referred to above, namely external monitors, analysis of SNMP data, etc. When detected, the secondary may want to step in even though the primary is still indicating that it believes it is healthy. >Suppose the NIC suddenly failed such that data was shifted out of the >transmit registers, but not actually written on the wire. That would likely >not be detected by the network layer, so the server would not detect a send >failure. Yes, and I have seen this kind of failure in practice. The point is that the DHCP server is not necessarily the best judge of its own health. However, an external monitor may detect the failure and so the secondary may learn that the primary is not as healthy as it says it is. >If the packet process is sending and >receiving data, the obvious signs of process health such as advancing >message counters won't reveal a problem, and if the packet process and >failover process continue to communicate, the failover process could easily >be fooled. Yes, and I have also seen this kind of failure occur in real systems. The solution is to have an external monitor do semantic analysis. In the load balancing business this is called "active content verification" and is considered essential for verifying (mostly web) server health. If performed, this can be another input to the secondary giving it a "feeling" that the primary is sick. >Agreed! I'm not sure that this is something that is appropriate for an RFC >though, as the methods for detection of various failures are very much >system-specific. I'm not saying that it is very relevant to inclusion in the RFC thought I think a paragraph on the subject might be useful. I does appear to have implications for how the protocol is designed though and I would like to understand if all these cases are in fact covered. >Some of the failure cases (such as internal to the DHCP server) are >likely NEVER to be fully eliminated. For example, if a DHCP Server >is really broken and starts giving out bad leases, there's not much >one can do except to warn an operator. Actually, there is something that can be done, namely having an external monitor inform the DHCP server that it is malfunctioning so that it can be shut down or be restarted. Of course, that's not relevant to the failover protocol design. From owner-dhcp-v4@bucknell.edu Fri Apr 7 05:34:01 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05267 for ; Fri, 7 Apr 2000 05:34:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id FAA17806; Fri, 7 Apr 2000 05:32:57 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id FAA05888 for ; Fri, 7 Apr 2000 05:32:43 -0400 (EDT) Received: from vaiobean ([204.57.137.66]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id CAA32169; Fri, 7 Apr 2000 02:19:42 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: DHCPv4 discussion list Subject: RE: Renew after a move to another subnet while powered up Date: Fri, 7 Apr 2000 02:35:02 -0700 Message-ID: <002d01bfa074$8d6ee9d0$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <200004070211.TAA24251@scv1.apple.com> Importance: Normal Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit >The DHCP client in Mac OS Open Transport versions 2.5 and higher will >accept a kOTPortNetworkChange message from the Ethernet driver to inform >it if a link-state change, and reconfigure a new address if necessary. Indeed, Windows 2000 also has this feature, called Media Sense. It's also pretty important for detecting issues that could otherwise cause the host to assume that it is in an auto-configuration situation, such as a loose cable. In such circumstances, a host could obtain a linklocal address for itself even in the presence of a DHCP server, causing considerable puzzlement on the part of the user as well as the network admin. From owner-dhcp-v4@bucknell.edu Fri Apr 7 11:31:51 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10532 for ; Fri, 7 Apr 2000 11:31:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA32143; Fri, 7 Apr 2000 11:25:36 -0400 (EDT) Received: from marvin.axion.bt.co.uk (marvin.axion.bt.co.uk [132.146.16.82]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id LAA25880 for ; Fri, 7 Apr 2000 11:23:09 -0400 (EDT) From: jerome.privat@bt.com Received: from cbtlipnt02.btlabs.bt.co.uk by marvin (local) with ESMTP; Fri, 7 Apr 2000 15:53:53 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id <2LABA8D1>; Fri, 7 Apr 2000 15:54:08 +0100 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB204087482@mbtlipnt02.btlabs.bt.co.uk> To: DHCPv4 discussion list Subject: RE: Comments on draft-ietf-dhc-userclass-05.txt Date: Fri, 7 Apr 2000 15:53:59 +0100 X-Mailer: Internet Mail Service (5.5.2651.88) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Reply-To: jerome.privat@bt.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN - Regarding the length fields, I am wondering if it is valid to have the N field (total length of the option) being a 2-byte field. RFC 2132 says that every variable-length DHCP option starts with a tag octet followed by a length octet, followed by "length" octets of data. This seems to imply that a valid DHCP option must have a one-byte length field. - Regarding using a start and end time subfields for each class: I would prefer to keep the User class option as simple as possible, just carrying the User Class values as opaque objects. A DHCP server admin can configure different lease times for different address pools and/or different User Class values. Has anybody else on the list a view on that? The WG consensus at the Washington meeting was to keep the option as simple as it can be... Thanks, Jerome Privat BT -----Original Message----- From: Steve Gonczi [mailto:Gonczi@PROCESS.COM] Sent: 03 March 2000 19:51 To: DHCPv4 discussion list Subject: Comments on draft-ietf-dhc-userclass-05.txt Hello, I believe the N and Ln fields should be 2 byte fields. It is quite possible, that the individual class values end up longer than 255 esp. if the values are generated by some ticket issuing authority / self-registration server. (In practice, these class values may end up being certificates, or some simpler authenticated tickets). Also, it would be quite useful to include start and end time subfields for each class value. (Something like time_t formatted UTC values... 32 bit NBO etc.. etc..) The obvious use of the end time is to provide a ttl for the ticket (a.k.a class x ) and the start time could be used for reserving resources for a specific time slot. E.g.: to schedule a video conference ahead of time. /Steve Gonczi Process Software Corporation From owner-dhcp-v4@bucknell.edu Fri Apr 7 12:52:51 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12309 for ; Fri, 7 Apr 2000 12:52:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA10127; Fri, 7 Apr 2000 12:38:39 -0400 (EDT) Received: from sbcsmtp2.ptss.com (sbcsmtp2.ptss.com [204.107.19.24]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA23457 for ; Fri, 7 Apr 2000 12:38:19 -0400 (EDT) Received: from mail2.pacbell.com (mail2.pacbell.com [129.245.2.18]) by sbcsmtp2.ptss.com (8.8.8/8.8.8) with ESMTP id JAA25245; Fri, 7 Apr 2000 09:37:17 -0700 (PDT) Received: from msgnorth98.ffcrc.pacbell.com .(msgnorth98.ffcrc.pacbell.com [150.234.34.86]) by mail2.PacBell.COM (8.8.5/8.8.5-pb990306) with ESMTP id JAA16684; Fri, 7 Apr 2000 09:38:25 -0700 (PDT) Received: by msgnorth98.ffcrc.pacbell.com with Internet Mail Service (5.5.2650.21) id <22J30T0J>; Fri, 7 Apr 2000 09:37:07 -0700 Message-ID: <11901E11CF13D311B91A0008C7A4F99C01FB2006@msgnorth17.ffcrc.pacbell.com> From: "HIBBS, BARR (SBCSI)" To: DHCPv4 discussion list Subject: RE: Comments on draft-ietf-dhc-userclass-05.txt Date: Fri, 7 Apr 2000 09:37:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Reply-To: RBHIBBS@msg.pacbell.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > From: jerome.privat@bt.com[SMTP:jerome.privat@bt.com] > Reply To: jerome.privat@bt.com > > - Regarding the length fields, I am wondering if it is valid > to have the N field (total length of the option) being a 2-byte > field. > RFC 2132 says that every variable-length DHCP option > starts with a tag octet followed by a length octet, followed > by "length" octets of data. This seems to imply that a valid > DHCP option must have a one-byte length field. > ...more than "implies." DHCPv4 (per RFC2132) supports only a one-octet length field, permitting the total length of an option to be 1-255 octets (0 is permitted, of course, but why bother sending a null option?) > - Regarding using a start and end time subfields for each class: > I would prefer to keep the User class option as simple as > possible, just carrying the User Class values as opaque objects. > A DHCP server admin can configure different lease times for > different address pools and/or different User Class values. > Has anybody else on the list a view on that? The WG consensus at > the Washington meeting was to keep the option as simple as it > can be... > ...I agree that the User Class option should be treated very much like the Vendor Class option, that is, the option data should be considered an opaque octet string. ...Steve's original point was about starting and ending times rather than lease durations, but I agree with you that including times in the option violates the principal of simplicity, presumably because that implies the server would not treat the data as a string of opaque octets. > -----Original Message----- > From: Steve Gonczi [mailto:Gonczi@PROCESS.COM] > Sent: 03 March 2000 19:51 > > > I believe the N and Ln fields should be 2 byte fields. > ...are you suggesting that we ratchet up the DHCPv4 version number, Steve? That is really a much bigger issue than the User Class option. > It is quite possible, that the individual class values end up longer than > 255 > esp. if the values are generated by some ticket issuing authority / > self-registration server. (In practice, these class values may end up > being > certificates, or some simpler authenticated tickets). > ...I don't believe we should be concerned with the contents of the option at all -- treat it as an opaque octet string. > Also, it would be quite useful to include start and end time subfields for > each class value. (Something like time_t formatted UTC values... 32 bit > NBO etc.. > etc..) The obvious use of the end time is to provide a ttl for the ticket > (a.k.a > class x ) and the start time could be used for reserving resources for a > specific time > slot. E.g.: to schedule a video conference ahead of time. > ...again, the contents of the User Class data shouldn't be of concern to the working group. In the application for User Classes that I forsee, time values would be of no use at all, so I would argue that it should not be included. From owner-dhcp-v4@bucknell.edu Fri Apr 7 14:21:57 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14318 for ; Fri, 7 Apr 2000 14:21:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA02323; Fri, 7 Apr 2000 14:15:53 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id OAA03078 for ; Fri, 7 Apr 2000 14:15:36 -0400 (EDT) Received: from grosse.manhattan.fugue.com (a0.pm3-24.theriver.com [206.102.192.16]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id WAA23189; Thu, 6 Apr 2000 22:07:30 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id LAA00823; Fri, 7 Apr 2000 11:09:18 -0700 (MST) Message-Id: <200004071809.LAA00823@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Comments on draft-ietf-dhc-userclass-05.txt In-Reply-To: Message from jerome.privat@bt.com of "Fri, 07 Apr 2000 15:53:59 +0100." <5104D4DBC598D211B5FE0000F8FE7EB204087482@mbtlipnt02.btlabs.bt.co.uk> Date: Fri, 07 Apr 2000 11:09:18 -0700 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > - Regarding the length fields, I am wondering if it is valid > to have the N field (total length of the option) being a 2-byte > field. If it's a DHCP option for RFC2131/2132, then the length has to be one byte. If it's for DHCPv4NG (the work Mike Carney has been doing) then it should be two bytes. Given that we don't have an RFC number to refer to for DHCPv4NG, it's probably reasonable to specify one byte. I'm not sure why you're asking this question, though - the draft currently specifies a one-byte length. > Regarding using a start and end time subfields for each class: > I would prefer to keep the User class option as simple as > possible I would prefer this too. Indeed, unless we want to spend another year specifying how the start and end times should be used, I don't see that we have a choice. Since I'm looking at it, here are some additional comments: > If i is the number of User Classes carried in the option, > its total length N is equal to i + sum(Li). This use of mathematical notation is a bit questionable, because you don't have the wherewithal to do subscripting. I would suggest phrasing it in english: The length of the option as specified in Len must be the sum of the lengths of each of the class names, starting with Len1 through to the length of the last class. I'm not claiming this is any clearer - it's just that it doesn't assume people will guess that, for example, sum(Li) means the sum of all Len fields starting with Len1 and going to the last Len field. :') > Servers not equipped to interpret the user class specified by > a client MUST ignore it (although it may be reported). I'd rephrase this: A server that is not equiped to interpret any given user class specified by a client MUST ignore it (although it may be reported). If a server recognizes one or more user classes specified by the client, but does not recognize one or more other user classes specified by the client, the server MAY use the user classes it recognizes. > DHCP clients implementing this option SHOULD allow users to enter > their User Class. DHCP clients implementing this option SHOULD allow users to enter one or more user class values. These latter two changes come up because of the ability for this option to carry more than one class - I think the language in the draft is from a time when the user class option only specified one class. :'} _MelloN_ From owner-dhcp-v4@bucknell.edu Fri Apr 7 15:18:42 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15972 for ; Fri, 7 Apr 2000 15:18:40 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA14506; Fri, 7 Apr 2000 15:14:57 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id PAA26400 for ; Fri, 7 Apr 2000 15:14:36 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id MAA20302 for ; Fri, 7 Apr 2000 12:14:32 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id MAA00907 for ; Fri, 7 Apr 2000 12:14:29 -0700 (MST)] Received: from dma.isg.mot.com (cabs1.dma.isg.mot.com [150.21.2.34]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id PAA21908 for ; Fri, 7 Apr 2000 15:14:24 -0400 (EDT) Message-Id: <200004071914.PAA21908@noah.dma.isg.mot.com> To: DHCPv4 discussion list Subject: DHCP-DISCOVER on new subnet Date: Fri, 07 Apr 2000 15:14:24 -0400 From: "Michael W. Patrick" Reply-To: mpatrick@dma.isg.mot.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN DHCPv4-list, Related to the subject of renewals on a new subnet is the problem of DHCP-DISCOVER by a client that changes its subnet. We currently have this problem in some deployed cable modem networks. The problem when a cable modem (CM) can "hear" the downstream transmissions of different head-end "cable modem termination systems" (CMTSs) that act as routers (and DHCP relay agents). DHCP packets are relayed by both CMTSs to the same DHCP server. After performing DHCP on one CMTS (and obtaining a lease on that CMTS's subnet), the CM may be instructed to switch to a different downstream channel, for the other CMTS. In effect, this is as if the DHCP client decided itself to switch to a different subnet, and needs to get a new IP address on that subnet. The problem we've seen in the field is that some DHCP servers will return the "old" IP address, even though the client performs a DHCP-DISCOVER (and the new CMTS adds its proper giaddr). This behavior of the server is allowed and indeed encouraged (with "SHOULD") by the RFC2131, section 4.3.1: ---- 4.3.1 DHCPDISCOVER message When a server receives a DHCPDISCOVER message from a client, the server chooses a network address for the requesting client. If no address is available, the server may choose to report the problem to the system administrator. If an address is available, the new address SHOULD be chosen as follows: o The client's current address as recorded in the client's current binding, ELSE o The client's previous address as recorded in the client's (now expired or released) binding, if that address is in the server's pool of available addresses and not already allocated, ELSE o The address requested in the 'Requested IP Address' option, if that address is valid and not already allocated, ELSE o A new address allocated from the server's pool of available addresses; the address is selected based on the subnet from which the message was received (if 'giaddr' is 0) or on the address of the relay agent that forwarded the message ('giaddr' when not 0). ---- If the DHCP server does NOT use the above algorithm, and recognizes that the giaddr of the new DHCP-DISCOVER from the client represents a "moved" client, then the "multiple CMTS" problem is avoided. Some DHCP servers indeed do this. Here's my questions to the group: 1. Which DHCP server vendors avoid the 'multiple CMTS' problem? That is, which DHCP servers will recognize a relayed DHCP-DISCOVER from a client that has moved to a new scope and will therefore give it a proper address on that subnet? 2. Shouldn't the algorithm in 4.3.1 be modified to REQUIRE servers to recognize DHCP-DISCOVERs with a giaddr that is not in the scope of the current (or last) client lease, and for which a new scope must therefore be identified? 3. Am I missing something that Cable Modem clients can do to FORCE the DHCP server to abandon the old lease and give them a new lease on the new subnet? Even if the CM did a DHCP-RELEASE before the new DHCP-DISCOVER, bullet 2 of 4.3.1 suggests that the server return the old lease anyway! At the moment, our workaround "non-recognizing" servers is to add reservations for the same client on BOTH CMTS subnets. This doesn't scale well, and we'd like to have automatically-assigned leases. And we can't do this unless the DHCP server properly recognizes a changed client subnet. Shouldn't we require this of servers? Thanx, mike From owner-dhcp-v4@bucknell.edu Fri Apr 7 15:46:41 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16653 for ; Fri, 7 Apr 2000 15:46:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA29470; Fri, 7 Apr 2000 15:43:54 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id PAA25382 for ; Fri, 7 Apr 2000 15:43:41 -0400 (EDT) Received: from vaiobean ([204.57.137.66]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id MAA32671; Fri, 7 Apr 2000 12:30:27 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: DHCPv4 discussion list Subject: RE: Comments on draft-ietf-dhc-userclass-05.txt Date: Fri, 7 Apr 2000 12:45:45 -0700 Message-ID: <003c01bfa0c9$df2cd070$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <11901E11CF13D311B91A0008C7A4F99C01FB2006@msgnorth17.ffcrc.pacbell.com> Importance: Normal Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Out of curiousity: what is the difference between the user class option and the DHCP authentication option, when used with Protocol 0 (authentication token). It seems to me that both options accomplish the same thing, sending an opaque string that can be construed as a claim of identity. Some potential differences: * The authentication option Protocol 0 seems designed to be sent from the server to the client. However, it does not appear prohibited for clients to send it in a DHCPDISCOVER and for servers to use this as an indication of the class of user. * DHCP authentication requires that the receiver discard the packet if the contents of the authentication option cannot be validated. Thus there is a difference in behavior between sending an unknown Protocol 0 token and sending an unknown user class option. From owner-dhcp-v4@bucknell.edu Fri Apr 7 19:35:55 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21151 for ; Fri, 7 Apr 2000 19:35:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id TAA11043; Fri, 7 Apr 2000 19:32:09 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id TAA13827 for ; Fri, 7 Apr 2000 19:32:06 -0400 (EDT) Received: from grosse.manhattan.fugue.com (a47.pm3-28.theriver.com [206.102.195.63]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id DAA25921; Fri, 7 Apr 2000 03:24:00 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id QAA00443; Fri, 7 Apr 2000 16:31:49 -0700 (MST) Message-Id: <200004072331.QAA00443@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: DHCP-DISCOVER on new subnet In-Reply-To: Message from "Michael W. Patrick" of "Fri, 07 Apr 2000 15:14:24 -0400." <200004071914.PAA21908@noah.dma.isg.mot.com> Date: Fri, 07 Apr 2000 16:31:49 -0700 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > After performing DHCP on one CMTS (and obtaining a lease on that > CMTS's subnet), the CM may be instructed to switch to a different > downstream channel, for the other CMTS. In effect, this is as if the > DHCP client decided itself to switch to a different subnet, and needs > to get a new IP address on that subnet. Hm. Is it the case that before the switch, the client will only be heard through one CMTS relay agent, and after the switch, the client will only be heard through the other? If that's the case, then the DHCP server should not be assigning IP addresses on one subnet to the client when it is being relayed through a relay agent on another subnet. If the client is being heard through both relay agents all the time, then you have a nasty problem to deal with. Can you clarify which of these situations holds true? If the former situation is true, then the DHCP server is probably misconfigured. The DHCP server depends heavily on the administrator to describe the network layout, and if the administrator makes a mistake, the sort of error that you're talking about could easily happen, and does not represent a server bug. _MelloN_ From owner-dhcp-v4@bucknell.edu Fri Apr 7 19:36:45 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21162 for ; Fri, 7 Apr 2000 19:36:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id TAA09135; Fri, 7 Apr 2000 19:35:53 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id TAA22678 for ; Fri, 7 Apr 2000 19:35:38 -0400 (EDT) Received: from grosse.manhattan.fugue.com (a47.pm3-28.theriver.com [206.102.195.63]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id DAA25933; Fri, 7 Apr 2000 03:27:32 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id QAA00463; Fri, 7 Apr 2000 16:35:22 -0700 (MST) Message-Id: <200004072335.QAA00463@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Comments on draft-ietf-dhc-userclass-05.txt In-Reply-To: Message from "Bernard Aboba" of "Fri, 07 Apr 2000 12:45:45 MST." <003c01bfa0c9$df2cd070$428939cc@ntdev.microsoft.com> Date: Fri, 07 Apr 2000 16:35:22 -0700 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > It seems to me that both options accomplish the > same thing, sending an opaque string that can be > construed as a claim of identity. No, they don't. A class is not the same thing as an identity. There can be many non-identical members of a class. It would be entirely appropriate for more than one client to report the same user class, and this should not result in incorrect behaviour on the part of the server. A better question would be, what is the difference between the client identifier option and the DHCP authentication option, when used with Protocol 0. :') _MelloN_ From owner-dhcp-v4@bucknell.edu Sat Apr 8 08:07:01 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10039 for ; Sat, 8 Apr 2000 08:07:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA05370; Sat, 8 Apr 2000 08:01:49 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id IAA06823 for ; Sat, 8 Apr 2000 08:01:44 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id FAA23947; Sat, 8 Apr 2000 05:01:42 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id FAA11859; Sat, 8 Apr 2000 05:01:42 -0700 (MST)] Received: from dma.isg.mot.com (cabs1.dma.isg.mot.com [150.21.2.34]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id IAA27522; Sat, 8 Apr 2000 08:01:41 -0400 (EDT) Message-Id: <200004081201.IAA27522@noah.dma.isg.mot.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: DHCP-DISCOVER on new subnet In-reply-to: Your message of "Fri, 07 Apr 2000 16:31:49 EDT." <200004072331.QAA00443@grosse.manhattan.fugue.com> Date: Sat, 08 Apr 2000 08:01:41 -0400 From: "Michael W. Patrick" Reply-To: mpatrick@dma.isg.mot.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >>>>> "Ted" == Ted Lemon writes: >> After performing DHCP on one CMTS (and obtaining a lease on that >> CMTS's subnet), the CM may be instructed to switch to a different >> downstream channel, for the other CMTS. In effect, this is as if >> the DHCP client decided itself to switch to a different subnet, and >> needs to get a new IP address on that subnet. > Hm. Is it the case that before the switch, the client will only be > heard through one CMTS relay agent, and after the switch, the client > will only be heard through the other? If that's the case, then the > DHCP server should not be assigning IP addresses on one subnet to > the client when it is being relayed through a relay agent on another > subnet. > If the client is being heard through both relay agents all the time, > then you have a nasty problem to deal with. Can you clarify which > of these situations holds true? If the former situation is true, > then the DHCP server is probably misconfigured. The DHCP server > depends heavily on the administrator to describe the network layout, > and if the administrator makes a mistake, the sort of error that > you're talking about could easily happen, and does not represent a > server bug. > _MelloN_ Ted, thanx for responding. The DHCP server will see the modem only through one CMTS at a time. So the server sees an initial single DHCP-DISCOVER with CMTS1's giaddr, and a few seconds later it will see a second DHCP-DISCOVER with only CMTS2's giaddr. The first lease (via CMTS1) will not have expired. I agree that the server *should* discard the first lease and generate a second one with the different giaddr. It's just that RFC2131 says the server "SHOULD" keep the first one! -mike From owner-dhcp-v4@bucknell.edu Sat Apr 8 15:56:10 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13687 for ; Sat, 8 Apr 2000 15:56:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA17373; Sat, 8 Apr 2000 15:52:15 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id PAA19988 for ; Sat, 8 Apr 2000 15:52:00 -0400 (EDT) Received: from grosse.manhattan.fugue.com (a2.pm3-33.theriver.com [206.30.150.66]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id WAA27451; Fri, 7 Apr 2000 22:37:16 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id MAA00689; Sat, 8 Apr 2000 12:51:39 -0700 (MST) Message-Id: <200004081951.MAA00689@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: DHCP-DISCOVER on new subnet In-Reply-To: Message from "Michael W. Patrick" of "Sat, 08 Apr 2000 08:01:41 -0400." <200004081201.IAA27522@noah.dma.isg.mot.com> Date: Sat, 08 Apr 2000 12:51:39 -0700 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I agree that the server *should* discard the first lease and generate > a second one with the different giaddr. It's just that RFC2131 > says the server "SHOULD" keep the first one! 2. Each server may respond with a DHCPOFFER message that includes an available network address in the 'yiaddr' field (and other configuration parameters in DHCP options). I would say that a network address that is not on the subnet to which the client is connected is not available, but you're right that this isn't very explicit, and I can't find any other place in the RFC where it is more explicit, and in particular, as you point out, in the section on address allocation, it does not specifically say that the old address should only be reused if the client is on the right subnet. However, I am pretty sure that what you are actually experiencing is a misconfigured DHCP server, not a DHCP server that has been implemented with a misunderstanding of the intent of this section of the draft. While I think it's a good idea to clarify this section of the draft, I would suggest that you investigate your customer's problem further, to see if this is actually a protocol misunderstanding or a configuration error. I know it would be easy to misconfigure the ISC DHCP server to behave in the way you describe, and I have had users do it in the past. _MelloN_ From owner-dhcp-v4@bucknell.edu Sat Apr 8 16:51:48 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14543 for ; Sat, 8 Apr 2000 16:51:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA22679; Sat, 8 Apr 2000 16:48:56 -0400 (EDT) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id QAA19864 for ; Sat, 8 Apr 2000 16:48:42 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id <2CWQ3R4M>; Sat, 8 Apr 2000 16:48:26 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86023C96C8@lespaul.process.com> From: Steve Gonczi To: DHCPv4 discussion list Cc: "'dhcp-v4@bucknell.edu'" Subject: RE: DHCP-DISCOVER on new subnet Date: Sat, 8 Apr 2000 16:48:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Reply-To: Gonczi@process.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN The RFC is unclear on this point, but it makes no sense to perpetuate an address that is inappropriate for the subnet where the client is. For the first 3 pargrapsh you are quoting, the RFC it should make it clear it assumes that the stored/ requested address is on the 'correct' subnet. IMHO Anyt server that does not deal with this issue, is bkoken. /sG > o The client's current address as recorded in the client's current > binding, ELSE > > o The client's previous address as recorded in the client's (now > expired or released) binding, if that address is in the server's > pool of available addresses and not already allocated, ELSE > > o The address requested in the 'Requested IP Address' option, if > that > address is valid and not already allocated, ELSE > > o A new address allocated from the server's pool of available > addresses; the address is selected based on the subnet from which > the message was received (if 'giaddr' is 0) or on the address of > the relay agent that forwarded the message ('giaddr' when not 0). > > From owner-dhcp-v4@bucknell.edu Mon Apr 10 04:06:38 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03271 for ; Mon, 10 Apr 2000 04:06:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id EAA22062; Mon, 10 Apr 2000 04:00:39 -0400 (EDT) Received: from marvin.axion.bt.co.uk (marvin.axion.bt.co.uk [132.146.16.82]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id EAA04366 for ; Mon, 10 Apr 2000 04:00:30 -0400 (EDT) From: jerome.privat@bt.com Received: from cbtlipnt01.btlabs.bt.co.uk by marvin (local) with ESMTP; Mon, 10 Apr 2000 08:58:38 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id <2PGWGAQH>; Mon, 10 Apr 2000 08:58:27 +0100 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB204087489@mbtlipnt02.btlabs.bt.co.uk> To: DHCPv4 discussion list Subject: RE: Comments on draft-ietf-dhc-userclass-05.txt Date: Mon, 10 Apr 2000 08:58:41 +0100 X-Mailer: Internet Mail Service (5.5.2651.88) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Reply-To: jerome.privat@bt.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Thanks for your comments. See my answers below. > - Regarding the length fields, I am wondering if it is valid > to have the N field (total length of the option) being a 2-byte > field. If it's a DHCP option for RFC2131/2132, then the length has to be one byte. If it's for DHCPv4NG (the work Mike Carney has been doing) then it should be two bytes. Given that we don't have an RFC number to refer to for DHCPv4NG, it's probably reasonable to specify one byte. I'm not sure why you're asking this question, though - the draft currently specifies a one-byte length. I was asking this question to answer a proposition by Steve Gonczi to increase the length field to 2 bytes. In any case I agree with you, let's keep it 1 byte so that we can go to Proposed without waiting for DHCPv4NG to become an RFC. > Regarding using a start and end time subfields for each class: > I would prefer to keep the User class option as simple as > possible I would prefer this too. Indeed, unless we want to spend another year specifying how the start and end times should be used, I don't see that we have a choice. Since I'm looking at it, here are some additional comments: > If i is the number of User Classes carried in the option, > its total length N is equal to i + sum(Li). This use of mathematical notation is a bit questionable, because you don't have the wherewithal to do subscripting. I would suggest phrasing it in english: The length of the option as specified in Len must be the sum of the lengths of each of the class names, starting with Len1 through to the length of the last class. I'm not claiming this is any clearer - it's just that it doesn't assume people will guess that, for example, sum(Li) means the sum of all Len fields starting with Len1 and going to the last Len field. :') Fine. I will use your text. > Servers not equipped to interpret the user class specified by > a client MUST ignore it (although it may be reported). I'd rephrase this: A server that is not equiped to interpret any given user class specified by a client MUST ignore it (although it may be reported). If a server recognizes one or more user classes specified by the client, but does not recognize one or more other user classes specified by the client, the server MAY use the user classes it recognizes. > DHCP clients implementing this option SHOULD allow users to enter > their User Class. DHCP clients implementing this option SHOULD allow users to enter one or more user class values. These latter two changes come up because of the ability for this option to carry more than one class - I think the language in the draft is from a time when the user class option only specified one class. :'} You are right. I will make the changes you suggested. Thanks again for your comments. I will edit a new version of the draft with these changes. Jerome From owner-dhcp-v4@bucknell.edu Mon Apr 10 07:42:22 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05950 for ; Mon, 10 Apr 2000 07:42:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id HAA27880; Mon, 10 Apr 2000 07:35:55 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id HAA22145 for ; Mon, 10 Apr 2000 07:35:45 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05680; Mon, 10 Apr 2000 07:35:44 -0400 (EDT) Message-Id: <200004101135.HAA05680@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-subnet-option-04.txt Date: Mon, 10 Apr 2000 07:35:44 -0400 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The Subnet Selection Option for DHCP Author(s) : G. Waters Filename : draft-ietf-dhc-subnet-option-04.txt Pages : 6 Date : 07-Apr-00 This memo defines a new DHCP option for selecting the subnet on which to allocate an address. This option would override a DHCP server's normal methods of selecting which subnet on which to allocate an address for a client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-subnet-option-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-subnet-option-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-subnet-option-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000407123231.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-subnet-option-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-subnet-option-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000407123231.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Mon Apr 10 12:50:55 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24297 for ; Mon, 10 Apr 2000 12:50:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA02441; Mon, 10 Apr 2000 12:44:20 -0400 (EDT) Received: from fs-sd-exch2.coppermountain.com (fs-sd-exch1.coppermountain.com [209.246.224.234] (may be forged)) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA21531 for ; Mon, 10 Apr 2000 12:44:06 -0400 (EDT) Received: by FS-SD-EXCH2 with Internet Mail Service (5.5.2650.21) id <2L70F7R3>; Mon, 10 Apr 2000 09:45:59 -0700 Message-ID: <9FFFAB5D74FFD31191EA00D0B74178C808459D@FS-SD-EXCH2> From: Eric Michelsen To: DHCPv4 discussion list Subject: What is agent-information status? Date: Mon, 10 Apr 2000 09:45:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: emichelsen@coppermountain.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN What is the status of the agent-information draft? ------------------------------------------- Eric L. Michelsen, Copper Mountain Networks From owner-dhcp-v4@bucknell.edu Wed Apr 12 07:17:32 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15377 for ; Wed, 12 Apr 2000 07:17:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id HAA31797; Wed, 12 Apr 2000 07:11:23 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id HAA24551 for ; Wed, 12 Apr 2000 07:11:12 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15095; Wed, 12 Apr 2000 07:11:11 -0400 (EDT) Message-Id: <200004121111.HAA15095@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-userclass-06.txt Date: Wed, 12 Apr 2000 07:11:10 -0400 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The User Class Option for DHCP Author(s) : G. Stump, R. Droms, Y. Gu, A. Demirtjis, B. Beser, R. Vyaghrapuri, J. Privat Filename : draft-ietf-dhc-userclass-06.txt Pages : 5 Date : 11-Apr-00 This option is used by a DHCP client to optionally identify the type or category of user or applications it represents. The information contained in this option is an opaque field that represents the user class of which the client is a member. Based on this class, a DHCP server selects the appropriate address pool to assign an address to the client and the appropriate configuration parameters. This option should be configurable by a user. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-userclass-06.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-06.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-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000411095805.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-userclass-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-userclass-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000411095805.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Thu Apr 13 10:45:50 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03717 for ; Thu, 13 Apr 2000 10:45:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA30016; Thu, 13 Apr 2000 10:38:58 -0400 (EDT) Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id UAA20644 for ; Wed, 12 Apr 2000 20:57:21 -0400 (EDT) Received: from droms-mac (pm3mi3-43.uplink.net [209.173.86.140]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id UAA10096 for ; Wed, 12 Apr 2000 20:57:18 -0400 (EDT) Message-Id: <4.2.2.20000412204815.00a425f0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 12 Apr 2000 20:57:10 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: *DRAFT* minutes for WG meeting in Adelaide Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Below is a draft of minutes from the DHC WG meeting in Adelaide. If you have additions, corrections, deletions or other comments, please reply to me or to the list by Monday, 4/17. - Ralph Droms Use of DHCP for configuration of IPSEC tunnel mode Bernard Aboba ------------- Aboba presented draft-ietf-ipsec-dhcp-04.txt describing use of DHCP for client configuration through a VPN tunnel. Aboba requested WG input on format and contents of chaddr and client identifier in IPSEC tunnel mode. Use of DHCP for configuring multicast DNS behavior Bernard Aboba ------------- This work has been moved to DNSEXT. DHCP Next Server Option Mike Borella ------------ This option, specified in draft-ietf-dhc-nextserver-02.txt, is a generic option that can carry multiple servers; first two are SIP and DHCP. DHCP authentication Ralph Droms ----------- WG approved WG last call for draft-ietf-dhc-authentication-12.txt after minor editorial changes, including clarification that protocols 0 and 1 do not address inter-domain roaming but other protocols in the framework may support inter-domain romaing. Stuart Cheshire will provide input about modifications to protocol 1 to accommodate inter-domain roaming. Domain search option Ralph Droms ----------- Ted Lemon/Pratik Gupta will manage this draft. The current draft needs technical decision on the encoding format (perhaps change to "DNS wire format"?) and may need additional editorial changes. Ted and Pratik will exchange drafts and produce a new revision. Requirements for Extending DHCP into New Environments Subir Das --------- Droms will initiate conversation about how to proceed on mailing list. Authentication, Authorization, and Accounting Requirements for Roaming Nodes using DHCP Subir Das --------- Droms will initiate conversation about how to proceed on mailing list. Dynamic Configuration of IPv4 Link-local Addresses Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network Stuart Cheshire, Ralph Droms ---------------------------- The WG suggested that Cheshire submit his draft as an independent submission for review by zeroconf and dhc WGs. DHCP reconfigure option P.De Schrijver -------------- draft-ietf-dhc-pv4-reconfigure-00.txt is ready for WG last call. Classless Static Routes option Ted Lemon --------- Ted will publish revision based on input from Bernard Aboba. The revised draft will be ready for WG last call Report on Failover protocol Ralph Droms (for Kim Kinnear) ----------------------------- The authors of the failover protocol draft held a phone conference on December 7. Results of that phone conference have been incorporated into the most recent revision of the specification, draft-ietf-dhc-failover-06.txt. Another conference call will take place and a new revision of the specification will be published prior to the next WG meeting in Pittsburgh. Interaction between DHCP and DNS Ted Lemon --------- The current draft reflects the specification for DHCP-DNS interaction using a new DHCP option and a new DHCP RR. There was a suggestion from the WG to split the specification into four documents: 1) specification of the new DHCP option 2) specification of the new DHCP RR 3) semantics for use of the DHCP RR 4) policies for resolving name conflicts Droms will raise issue of splitting with draft with the author of the draft, Mark Stapp. DHCP lease query Rich Woundy ----------- Woundy presented a new option that can be used by relay agent to determine client hardware address and link attachment point. The purpose of the option is to avoid use of ARP in reconstruction of forwarding tables in a relay agent if the relay agent loses that information. The WG suggested considering SNMP or LDAP as alternatives to this new option. The WG agreed to take on the new option as WG action item. DHCP Option for PacketCable VoIP Client Configuration Burcak Beser ------------ This new option is used to hand out different configurations behind one IP address. The author will ask for review on WG mailing list. Guidelines and new format for DHCP options Mike Carney ----------- Carney discussed the latest revision of draft-ietf-dhc-new-options-05.txt. The WG suggested splitting the draft into two docs: a description of guidelines for new options and a new syntax for options. Carney will consider this suggestion. From owner-dhcp-v6@bucknell.edu Fri Apr 14 05:52:46 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04941 for ; Fri, 14 Apr 2000 05:52:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id FAA09610; Fri, 14 Apr 2000 05:49:57 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id FAA25707 for ; Fri, 14 Apr 2000 05:49:41 -0400 (EDT) Received: from localhost ([3ffe:501:100f:10c1:250:4ff:fffe:d85f]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id SAA12197; Fri, 14 Apr 2000 18:37:37 +0900 (JST) Date: Fri, 14 Apr 2000 18:48:57 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: DHCPv6 discussion list Cc: ipng@sunroof.eng.sun.com Subject: current status of DHCPv6 User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 14 Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hello, I'd like to know the current status of DHCPv6. As far as know, DHCPv6 has not been published as an RFC, but the latest draft draft-ietf-dhc-dhcpv6-15.txt has already expired. Which document should I refere to now? Thanks. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-dhcp-v6@bucknell.edu Fri Apr 14 06:17:48 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05118 for ; Fri, 14 Apr 2000 06:17:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA12867; Fri, 14 Apr 2000 06:16:50 -0400 (EDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id GAA07768 for ; Fri, 14 Apr 2000 06:16:35 -0400 (EDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e3EAGBF15818 for ; Fri, 14 Apr 2000 12:16:12 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA01615 for ; Fri, 14 Apr 2000 12:16:11 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id MAA27393 for ; Fri, 14 Apr 2000 12:16:26 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200004141016.MAA27393@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: DHCPv6 discussion list Subject: Re: current status of DHCPv6 In-reply-to: Your message of Fri, 14 Apr 2000 18:48:57 +0900. Date: Fri, 14 Apr 2000 12:16:26 +0200 Sender: owner-dhcp-v6@bucknell.edu Reply-To: dhcp-v6@bucknell.edu X-Sender: Francis.Dupont@enst-bretagne.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN In your previous mail you wrote: I'd like to know the current status of DHCPv6. As far as know, DHCPv6 has not been published as an RFC, but the latest draft draft-ietf-dhc-dhcpv6-15.txt has already expired. => I expect to get the new/final document (with its companion) ASAP... Which document should I refere to now? => the next one! Francis.Dupont@enst-bretagne.fr From owner-dhcp-v6@bucknell.edu Fri Apr 14 07:31:03 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05879 for ; Fri, 14 Apr 2000 07:31:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id HAA15823; Fri, 14 Apr 2000 07:27:16 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id HAA01167 for ; Fri, 14 Apr 2000 07:27:04 -0400 (EDT) Received: from localhost ([3ffe:501:100f:10c1:250:4ff:fffe:d85f]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id UAA12401 for ; Fri, 14 Apr 2000 20:14:58 +0900 (JST) Date: Fri, 14 Apr 2000 20:26:17 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: DHCPv6 discussion list Subject: Re: current status of DHCPv6 In-Reply-To: In your message of "Fri, 14 Apr 2000 12:16:26 +0200" <200004141016.MAA27393@givry.rennes.enst-bretagne.fr> References: <200004141016.MAA27393@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 13 Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >>>>> On Fri, 14 Apr 2000 12:16:26 +0200, >>>>> Francis Dupont said: > Which document should I refere to now? > => the next one! I see, thanks for the quick response. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-dhcp-v6@bucknell.edu Fri Apr 14 18:58:56 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15435 for ; Fri, 14 Apr 2000 18:58:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id SAA16239; Fri, 14 Apr 2000 18:55:14 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id SAA02772 for ; Fri, 14 Apr 2000 18:55:06 -0400 (EDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA27088; Fri, 14 Apr 2000 15:55:02 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.82.166]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id PAA22122; Fri, 14 Apr 2000 15:55:02 -0700 (PDT) Received: from dhcptest86-c (dhcptest86-c.Eng.Sun.COM [129.146.86.200]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with SMTP id e3EMt0w578557; Fri, 14 Apr 2000 15:55:00 -0700 (PDT) Date: Fri, 14 Apr 2000 15:54:10 -0700 (PDT) From: "Michael W. Carney" Reply-To: "Michael W. Carney" Subject: Re: current status of DHCPv6 To: DHCPv6 discussion list Cc: ipng@sunroof.eng.sun.com, dhcp-v6@bucknell.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi jinmei-san, Our plan (dhcpv6 authors) is to produce 3 drafts on the road to pittsburg. The roadmap is as follows: a) DHCPv6 protocol and extension drafts ready for review on May 5th. We'll collect input until May 19th. b) We'll release an updated set of drafts on June 2nd. We'll collect input on these drafts until June 16. c) We'll release another set of drafts on June 30th, collecting any input which we'll roll into what we hope would be the final draft by the July 14th pittsburg publishing deadline. Of course, if the initial drafts are so wonderful that we don't need b+c, that's fine too. ;^) I hope you'll participate in the review of the drafts! Thanks, Mike Carney SNT Internet Engineering Sun Microsystems, Inc. (650) 786-4171 Mailstop UMPK17-202 901 San Antonio Rd Palo Alto, CA 94303 From owner-dhcp-v6@bucknell.edu Mon Apr 17 03:50:48 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27242 for ; Mon, 17 Apr 2000 03:50:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id DAA03229; Mon, 17 Apr 2000 03:46:38 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id DAA15181 for ; Mon, 17 Apr 2000 03:46:19 -0400 (EDT) Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id QAA21694; Mon, 17 Apr 2000 16:34:04 +0900 (JST) Date: Mon, 17 Apr 2000 16:45:18 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: DHCPv6 discussion list Cc: ipng@sunroof.eng.sun.com, dhcp-v6@bucknell.edu Subject: Re: current status of DHCPv6 In-Reply-To: In your message of "Fri, 14 Apr 2000 15:54:10 -0700 (PDT)" References: User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 31 Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >>>>> On Fri, 14 Apr 2000 15:54:10 -0700 (PDT), >>>>> "Michael W. Carney" said: > Our plan (dhcpv6 authors) is to produce 3 drafts on the road to pittsburg. The > roadmap is as follows: > a) DHCPv6 protocol and extension drafts ready for review on May 5th. We'll > collect input until May 19th. Thanks for the information. Then I'm looking forward to the next version. > b) We'll release an updated set of drafts on June 2nd. We'll collect input on > these drafts until June 16. > c) We'll release another set of drafts on June 30th, collecting any input > which we'll roll into what we hope would be the final draft by the July 14th > pittsburg publishing deadline. > Of course, if the initial drafts are so wonderful that we don't need b+c, > that's fine too. ;^) > I hope you'll participate in the review of the drafts! Sure. Actually, I have some comments on the dhcpv6-14 draft (this is the only version that I can get), but I won't send them since they might now be meaningless. I'd just wait for the next version. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-dhcp-v4@bucknell.edu Mon Apr 24 17:16:49 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15249 for ; Mon, 24 Apr 2000 17:16:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA13491; Mon, 24 Apr 2000 17:12:10 -0400 (EDT) Received: from mail.sanlight.com (IDENT:root@mail.sanlight.com [208.184.100.76]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id RAA12217 for ; Mon, 24 Apr 2000 17:12:00 -0400 (EDT) Received: from sanlight.com (IDENT:medi@medi.sanlight.com [208.184.100.70]) by mail.sanlight.com (8.9.3/8.9.3) with ESMTP id OAA00665 for ; Mon, 24 Apr 2000 14:11:39 -0700 Sender: owner-dhcp-v4@bucknell.edu Message-ID: <3904B8C0.1440479B@sanlight.com> Date: Mon, 24 Apr 2000 14:12:32 -0700 From: Medi Montaseri X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: DHCP Client - I need one in source code Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: medi@sanlight.com X-Sender: medi@sanlight.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hi, I need to write a DHCP client and am wondering if I can reuse any previous work in this area. Does anyone has any in C/Perl/etc ? Thanks -- ===================================================================== Medi Montaseri, Software Eng, medi@sanlight.com ===================================================================== From owner-dhcp-v4@bucknell.edu Mon Apr 24 18:13:54 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16296 for ; Mon, 24 Apr 2000 18:13:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id SAA01879; Mon, 24 Apr 2000 18:10:35 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id SAA27037 for ; Mon, 24 Apr 2000 18:10:28 -0400 (EDT) Received: from grosse.manhattan.fugue.com (a5.pm3-29.theriver.com [206.102.195.69]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id XAA09455; Sun, 23 Apr 2000 23:30:37 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id PAA01471; Mon, 24 Apr 2000 15:09:52 -0700 (MST) Message-Id: <200004242209.PAA01471@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: DHCP Client - I need one in source code In-Reply-To: Message from Medi Montaseri of "Mon, 24 Apr 2000 14:12:32 MST." <3904B8C0.1440479B@sanlight.com> Date: Mon, 24 Apr 2000 15:09:52 -0700 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN The ISC has an open-source DHCP client, written in C - it's part of the ISC DHCP distribution. http://www.isc.org/ _MelloN_ From owner-dhcp-v4@bucknell.edu Mon Apr 24 20:14:45 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18237 for ; Mon, 24 Apr 2000 20:14:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id UAA12415; Mon, 24 Apr 2000 20:10:32 -0400 (EDT) Received: from repulse.cnchost.com (repulse.concentric.net [207.155.248.4]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id UAA13102 for ; Mon, 24 Apr 2000 20:10:23 -0400 (EDT) Received: from vovida.com ([209.237.8.98]) by repulse.cnchost.com id UAA13408; Mon, 24 Apr 2000 20:10:22 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Errors-To: Sender: owner-dhcp-v4@bucknell.edu Message-ID: <3904E26E.B1F43DAB@vovida.com> Date: Mon, 24 Apr 2000 17:10:22 -0700 From: Mallikarjun Organization: vovida networks X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: Question about destination address Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: mmedala@vovida.com X-Sender: mallik@cnchost.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hello, I am trying to configure a h/w box with uses Bootp on my linux system which runs dhcpd. I need to give the destination address for this h/w box. Is this possible in the dhcpd.conf file. rest everything is set fine like gateway address, own ip address, etc. I would appreciate any kind of help in this direction. Thanks, Sincerely, Mallik From owner-dhcp-v4@bucknell.edu Mon Apr 24 20:34:44 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18501 for ; Mon, 24 Apr 2000 20:34:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id UAA20803; Mon, 24 Apr 2000 20:33:27 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id UAA20813 for ; Mon, 24 Apr 2000 20:33:11 -0400 (EDT) Received: from grosse.manhattan.fugue.com (a26.pm3-28.theriver.com [206.102.195.42]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id BAA09709; Mon, 24 Apr 2000 01:53:55 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id RAA00355; Mon, 24 Apr 2000 17:33:13 -0700 (MST) Message-Id: <200004250033.RAA00355@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Question about destination address In-Reply-To: Message from Mallikarjun of "Mon, 24 Apr 2000 17:10:22 MST." <3904E26E.B1F43DAB@vovida.com> Date: Mon, 24 Apr 2000 17:33:13 -0700 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I am trying to configure a h/w box with uses Bootp on my linux > system which runs dhcpd. I need to give the destination address for this > h/w box. Is this possible in the dhcpd.conf file. rest everything is set > fine like gateway address, own ip address, etc. I would appreciate any > kind of help in this direction. You should probably be asking for help with the ISC DHCP server on the ISC mailing list - see http://www.isc.org for details. In answer to your question, you can write a host declaration that will assign a fixed address to a BOOTP client, and this is what I would recommend. It should look something like this: host foo { hardware ethernet 08:00:2b:4c:ed:a9; fixed-address 1.2.3.4; } The address that you assign to it should not be included in any range statement you may have in your dhcpd.conf file. _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Apr 26 21:15:46 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07599 for ; Wed, 26 Apr 2000 21:15:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id VAA16695; Wed, 26 Apr 2000 21:07:30 -0400 (EDT) Received: from monitor.internaut.com (mg-206253200-16.ricochet.net [206.253.200.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id VAA13064 for ; Wed, 26 Apr 2000 21:07:10 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id RAA74624 for ; Wed, 26 Apr 2000 17:52:23 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: DHCPv4 discussion list Subject: Mini-DHCP servers Date: Wed, 26 Apr 2000 18:07:31 -0700 Message-ID: <000901bfafe4$f82853e0$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <4.2.2.20000412204815.00a425f0@mail.bucknell.edu> Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Since many home gateways contain mini-DHCP servers and there is no spec for how these ought to work, I thought I would write one: http://www.drizzle.com/~aboba/IETF47/draft-aboba-dhc-mini-00.txt Comments welcome. From owner-dhcp-v4@bucknell.edu Thu Apr 27 13:11:25 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04028 for ; Thu, 27 Apr 2000 13:11:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA00773; Thu, 27 Apr 2000 13:06:29 -0400 (EDT) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id NAA23353 for ; Thu, 27 Apr 2000 13:06:23 -0400 (EDT) Received: (from bmanning@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id KAA25223; Thu, 27 Apr 2000 10:04:39 -0700 (PDT) From: Bill Manning Message-Id: <200004271704.KAA25223@zephyr.isi.edu> Subject: Re: Mini-DHCP servers To: DHCPv4 discussion list Date: Thu, 27 Apr 2000 10:04:38 -0700 (PDT) Cc: dhcp-v4@bucknell.edu (DHCPv4 discussion list) In-Reply-To: <000901bfafe4$f82853e0$428939cc@ntdev.microsoft.com> from "Bernard Aboba" at Apr 26, 2000 06:07:31 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: bmanning@ISI.EDU Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit % % Since many home gateways contain mini-DHCP servers and there % is no spec for how these ought to work, I thought I would % write one: % % http://www.drizzle.com/~aboba/IETF47/draft-aboba-dhc-mini-00.txt % % Comments welcome. % Why should these DHCP servers work any differently than any other DHCP servers? --bill From owner-dhcp-v4@bucknell.edu Thu Apr 27 15:40:16 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05814 for ; Thu, 27 Apr 2000 15:40:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA32238; Thu, 27 Apr 2000 15:35:34 -0400 (EDT) Received: from gateway.assuredaccess.com (gateway.assuredaccess.com [206.169.126.4]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id PAA13382 for ; Thu, 27 Apr 2000 15:34:25 -0400 (EDT) Received: from assuredaccess.com ([10.193.101.165]) by gateway.assuredaccess.com (Netscape Mail Server v2.0) with ESMTP id AAA154; Thu, 27 Apr 2000 12:36:13 -0700 Sender: owner-dhcp-v4@bucknell.edu Message-ID: <39089643.CC5A505E@assuredaccess.com> Date: Thu, 27 Apr 2000 12:34:27 -0700 From: Wim Janssen Organization: Alcatel Telecom X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: Relayed lease extension Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Reply-To: wjanssen@assuredaccess.com X-Sender: janssenw X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit All, I wanted to get some feedback from the group on the following: What should a DHCP server do when it receives a request to extend an existing lease, and with 'giaddr' filled in? Should it unicast to the client (ciaddr) or to the relay agent (giaddr)? The idea behind this is a client/relay agent in one big box, asking for leases on behalf of PPP users. In this case, lease extensions should not be sent back to the PPP user, but to the relay agent. Note that the RFC 'assumes' that lease extensions are unicasted between client and server, without any intervention from a relay agent. ("this message will be unicast ...") RFC 2131 tells us: 4.1 Constructing and sending DHCP messages (p. 21 & 22) ... If the 'giaddr' field in a DHCP message from a client is non-zero, the server sends any return messages to the 'DHCP server' port on the BOOTP relay agent whose address appears in 'giaddr'. ... But also on p. 30: Clients send DHCPREQUEST messages as follows: ... o DHCPREQUEST generated during RENEWING state: 'server identifier' MUST NOT be filled in, 'requested IP address' option MUST NOT be filled in, 'ciaddr' MUST be filled in with client's IP address. In this situation, the client is completely configured, and is trying to extend its lease. This message will be unicast, so no relay agents will be involved in its ^^^^ transmission. Because 'giaddr' is therefore not filled in, the DHCP server will trust the value in 'ciaddr', and use it when replying to the client. ... Thanks for any feedback, Wim -- Wim Janssen Alcatel Telecom http://www.alcatel.com Tel : 1 (408) 935 3130 Fax : 1 (408) 941 1818 Email : wim.janssen@assuredaccess.com || wim.janssen@alcatel.be From owner-dhcp-v4@bucknell.edu Thu Apr 27 15:48:32 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05877 for ; Thu, 27 Apr 2000 15:48:32 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA04354; Thu, 27 Apr 2000 15:46:42 -0400 (EDT) Received: from alcor.process.com (alcor.process.com [192.42.95.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id PAA04064 for ; Thu, 27 Apr 2000 15:46:09 -0400 (EDT) Received: by process.com (MX V5.1-X A2w8g) id 58; Thu, 27 Apr 2000 15:45:43 -0400 Sender: owner-dhcp-v4@bucknell.edu Date: Thu, 27 Apr 2000 15:45:43 -0400 From: Bernie Volz To: DHCPv4 discussion list CC: dhcp-v4@bucknell.edu Message-ID: <009E93E8.1BFE5ACA.58@process.com> Subject: RE: Relayed lease extension Reply-To: volz@process.com X-Sender: volz@process.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I wonder whether a solution to this is to send the response back to the sender's IP address. In other words, just use the "from" information in the recvfrom call in the sendto. In "normal" UDP applications, that is what is done (such as for DNS and NFS). One might consider a slight deviation of that for added security and that is to check that the from address is either (a) the ciaddr of the client or (b) the giaddr. If neither, drop the packet as it likely is spoofed (this doesn't really prevent spoofing as the sender could simply set giaddr to its address). - Bernie Volz Message-ID: <39089643.CC5A505E@assuredaccess.com> Date: Thu, 27 Apr 2000 12:34:27 -0700 From: Wim Janssen Organization: Alcatel Telecom To: DHCPv4 discussion list Subject: Relayed lease extension All, I wanted to get some feedback from the group on the following: What should a DHCP server do when it receives a request to extend an existing lease, and with 'giaddr' filled in? Should it unicast to the client (ciaddr) or to the relay agent (giaddr)? The idea behind this is a client/relay agent in one big box, asking for leases on behalf of PPP users. In this case, lease extensions should not be sent back to the PPP user, but to the relay agent. Note that the RFC 'assumes' that lease extensions are unicasted between client and server, without any intervention from a relay agent. ("this message will be unicast ...") RFC 2131 tells us: 4.1 Constructing and sending DHCP messages (p. 21 & 22) ... If the 'giaddr' field in a DHCP message from a client is non-zero, the server sends any return messages to the 'DHCP server' port on the BOOTP relay agent whose address appears in 'giaddr'. ... But also on p. 30: Clients send DHCPREQUEST messages as follows: ... o DHCPREQUEST generated during RENEWING state: 'server identifier' MUST NOT be filled in, 'requested IP address' option MUST NOT be filled in, 'ciaddr' MUST be filled in with client's IP address. In this situation, the client is completely configured, and is trying to extend its lease. This message will be unicast, so no relay agents will be involved in its ^^^^ transmission. Because 'giaddr' is therefore not filled in, the DHCP server will trust the value in 'ciaddr', and use it when replying to the client. ... Thanks for any feedback, Wim -- Wim Janssen Alcatel Telecom http://www.alcatel.com Tel : 1 (408) 935 3130 Fax : 1 (408) 941 1818 Email : wim.janssen@assuredaccess.com || wim.janssen@alcatel.be From owner-dhcp-v4@bucknell.edu Thu Apr 27 16:27:02 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06224 for ; Thu, 27 Apr 2000 16:27:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA10442; Thu, 27 Apr 2000 16:23:27 -0400 (EDT) Received: from gateway.assuredaccess.com (gateway.assuredaccess.com [206.169.126.4]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id QAA16350 for ; Thu, 27 Apr 2000 16:23:16 -0400 (EDT) Received: from assuredaccess.com ([10.193.101.165]) by gateway.assuredaccess.com (Netscape Mail Server v2.0) with ESMTP id AAA172; Thu, 27 Apr 2000 13:24:58 -0700 Sender: owner-dhcp-v4@bucknell.edu Message-ID: <3908A1B0.CE397444@assuredaccess.com> Date: Thu, 27 Apr 2000 13:23:12 -0700 From: Wim Janssen Organization: Alcatel Telecom X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list CC: dhcp-v4@bucknell.edu Subject: Re: Relayed lease extension References: <009E93E8.1BFE5ACA.58@process.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Reply-To: wjanssen@assuredaccess.com X-Sender: janssenw X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Bernie Volz wrote: > > I wonder whether a solution to this is to send the response back to the > sender's IP address. In other words, just use the "from" information in > the recvfrom call in the sendto. In "normal" UDP applications, that is > what is done (such as for DNS and NFS). This would be OK for me. The only problem perhaps is that there are lots of DHCP servers working differently ... > One might consider a slight deviation of that for added security ... and it may introduce a possible security leak. > and > that is to check that the from address is either (a) the ciaddr of the > client or (b) the giaddr. If neither, drop the packet as it likely is > spoofed (this doesn't really prevent spoofing as the sender could simply > set giaddr to its address). The added security check should not be done if you have a RAS with multiple network cards acting as a relay agent. The 'giaddr' could be a hint for the server to fetch IP addresses from its pools. But it doesn't need to be the source address of the packet, since the DHCP server could very well be sitting on another interface of the RAS. Usually an application should take the 'best' IP address to reach the server, no? Wim From owner-dhcp-v4@bucknell.edu Thu Apr 27 16:51:50 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06507 for ; Thu, 27 Apr 2000 16:51:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA21792; Thu, 27 Apr 2000 16:49:48 -0400 (EDT) Received: from alcor.process.com (alcor.process.com [192.42.95.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id QAA31989 for ; Thu, 27 Apr 2000 16:49:44 -0400 (EDT) Received: by process.com (MX V5.1-X A2w8g) id 313; Thu, 27 Apr 2000 16:49:24 -0400 Sender: owner-dhcp-v4@bucknell.edu Date: Thu, 27 Apr 2000 16:49:22 -0400 From: Bernie Volz To: DHCPv4 discussion list CC: dhcp-v4@bucknell.edu Message-ID: <009E93F1.009049BB.313@process.com> Subject: Re: Relayed lease extension Reply-To: volz@process.com X-Sender: volz@process.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Wim Janssen wrote: > >Bernie Volz wrote: >> >> I wonder whether a solution to this is to send the response back to the >> sender's IP address. In other words, just use the "from" information in >> the recvfrom call in the sendto. In "normal" UDP applications, that is >> what is done (such as for DNS and NFS). > >This would be OK for me. The only problem perhaps is that there are lots >of DHCP servers working differently ... That is true. Was your question HOW do most servers act today (do they explicit follow the standard or not)? > >> One might consider a slight deviation of that for added security > >... and it may introduce a possible security leak. > >> and >> that is to check that the from address is either (a) the ciaddr of the >> client or (b) the giaddr. If neither, drop the packet as it likely is >> spoofed (this doesn't really prevent spoofing as the sender could simply >> set giaddr to its address). > >The added security check should not be done if you have a RAS with multiple >network cards acting as a relay agent. The 'giaddr' could be a hint for >the server to fetch IP addresses from its pools. But it doesn't need >to be the source address of the packet, since the DHCP server could >very well be sitting on another interface of the RAS. Usually an >application should take the 'best' IP address to reach the server, no? Yes, in the simple socket model the sender doesn't specify the source address (the UDP/IP layer picks it based on the interface). Of course, one can always bind to a specific source address (the giaddr) before sending. So, it is possible (if care isn't used) that the giaddr and the source address could be different. But, it is usually easy to fix that behavoir (bind to the giaddr). > >Wim - Bernie From owner-dhcp-v4@bucknell.edu Thu Apr 27 17:16:41 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06980 for ; Thu, 27 Apr 2000 17:16:40 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA10174; Thu, 27 Apr 2000 17:13:24 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id RAA09256 for ; Thu, 27 Apr 2000 17:13:19 -0400 (EDT) Received: from grosse.manhattan.fugue.com (a41.pm3-30.theriver.com [206.102.195.153]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id WAA23293; Wed, 26 Apr 2000 22:33:54 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id OAA10429; Thu, 27 Apr 2000 14:13:16 -0700 (MST) Message-Id: <200004272113.OAA10429@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Relayed lease extension In-Reply-To: Message from Bernie Volz of "Thu, 27 Apr 2000 16:49:22 -0400." <009E93F1.009049BB.313@process.com> Date: Thu, 27 Apr 2000 14:13:16 -0700 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > So, it is possible (if care isn't used) that the giaddr and the source > address could be different. But, it is usually easy to fix that > behavoir (bind to the giaddr). If it doesn't say something in the spec, and you decide that you're going to be picky about that thing anyway, you're likely to have interoperability problems. I was actually bitten by this with the client and the server identifier option. Given that the spec is explicit about where to send DHCP messages, I think it would be a mistake to send them elsewhere. _MelloN_ From owner-dhcp-v4@bucknell.edu Thu Apr 27 17:22:11 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07035 for ; Thu, 27 Apr 2000 17:22:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA06788; Thu, 27 Apr 2000 17:21:07 -0400 (EDT) Received: from gateway.assuredaccess.com (gateway.assuredaccess.com [206.169.126.4]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id RAA24224 for ; Thu, 27 Apr 2000 17:20:48 -0400 (EDT) Received: from assuredaccess.com ([10.193.101.165]) by gateway.assuredaccess.com (Netscape Mail Server v2.0) with ESMTP id AAA172; Thu, 27 Apr 2000 14:22:41 -0700 Sender: owner-dhcp-v4@bucknell.edu Message-ID: <3908AF36.49AA4549@assuredaccess.com> Date: Thu, 27 Apr 2000 14:20:54 -0700 From: Wim Janssen Organization: Alcatel Telecom X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list CC: dhcp-v4@bucknell.edu Subject: Re: Relayed lease extension References: <009E93F1.009049BB.313@process.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Reply-To: wjanssen@assuredaccess.com X-Sender: janssenw X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Bernie Volz wrote: > > Wim Janssen wrote: > > > >Bernie Volz wrote: > >> > >This would be OK for me. The only problem perhaps is that there are lots > >of DHCP servers working differently ... > > That is true. Was your question HOW do most servers act today Actually, yes, that's what I was ultimately trying to figure out. And as well trying to get a guideline of how it is supposed to work. > (do they > explicit follow the standard or not)? > My question to get there, was: what _is_ the standard in this case? (looking at my quotes of the RFC). I currently tried to relay a lease extension with 'giaddr' filled in, with two different -respectable- servers, and they both handle this differently: one sends to 'ciaddr', the other one to 'giaddr'. Wim From owner-dhcp-v4@bucknell.edu Fri Apr 28 08:32:33 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29478 for ; Fri, 28 Apr 2000 08:32:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA24743; Fri, 28 Apr 2000 08:28:34 -0400 (EDT) Received: from monitor.internaut.com (mg-206253200-16.ricochet.net [206.253.200.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id IAA14980 for ; Fri, 28 Apr 2000 08:28:23 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id FAA76590; Fri, 28 Apr 2000 05:13:28 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: DHCPv4 discussion list Cc: "'DHCPv4 discussion list'" Subject: RE: Mini-DHCP servers Date: Fri, 28 Apr 2000 05:29:00 -0700 Message-ID: <002301bfb10d$55541c10$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <200004271704.KAA25223@zephyr.isi.edu> Importance: Normal Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit >Why should these DHCP servers work any differently than any other DHCP >servers? In general, they don't. But they do have additional mechanisms to provide for "no configuration" ease of use. From owner-dhcp-v4@bucknell.edu Fri Apr 28 08:40:37 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29700 for ; Fri, 28 Apr 2000 08:40:37 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA31199; Fri, 28 Apr 2000 08:39:05 -0400 (EDT) Received: from monitor.internaut.com (mg-206253200-16.ricochet.net [206.253.200.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id IAA28299 for ; Fri, 28 Apr 2000 08:38:58 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id FAA76601; Fri, 28 Apr 2000 05:24:12 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: DHCPv4 discussion list Subject: RE: Relayed lease extension Date: Fri, 28 Apr 2000 05:39:43 -0700 Message-ID: <002401bfb10e$d532adb0$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <39089643.CC5A505E@assuredaccess.com> Importance: Normal Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit >The idea behind this is a client/relay agent in one big box, >asking for leases on behalf of PPP users. In this case, lease extensions >should not be sent back to the PPP user, but to the relay agent. In most implementations that I've seen it is the big box that obtains the leases in the first place. So in effect it is not acting as a relay agent, but as a DHCP client. In that case, why forge a DHCPREQUEST on behalf of the PPP user? From owner-dhcp-v4@bucknell.edu Fri Apr 28 08:54:29 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29924 for ; Fri, 28 Apr 2000 08:54:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA15934; Fri, 28 Apr 2000 08:53:11 -0400 (EDT) Received: from alcor.process.com (alcor.process.com [192.42.95.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id IAA19251 for ; Fri, 28 Apr 2000 08:52:58 -0400 (EDT) Received: by process.com (MX V5.1-X A2w8g) id 18; Fri, 28 Apr 2000 08:50:55 -0400 Sender: owner-dhcp-v4@bucknell.edu Date: Fri, 28 Apr 2000 08:50:55 -0400 From: Bernie Volz To: DHCPv4 discussion list CC: DHCP-V4@bucknell.edu Message-ID: <009E9477.53F62537.18@process.com> Subject: RE: Relayed lease extension Reply-To: volz@process.com X-Sender: volz@process.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I think that perhaps the model of the relay agent means you don't have to have a DHCP "filter" in place. Since the big box is acting as a router, it would otherwise need to have code in it to filter off the DHCP packets to prevent them from being sent to the active client. But, I likely should let the original requestor answer that question. - Bernie From: "Bernard Aboba" To: DHCPv4 discussion list Subject: RE: Relayed lease extension Date: Fri, 28 Apr 2000 05:39:43 -0700 Message-ID: <002401bfb10e$d532adb0$428939cc@ntdev.microsoft.com> >The idea behind this is a client/relay agent in one big box, >asking for leases on behalf of PPP users. In this case, lease extensions >should not be sent back to the PPP user, but to the relay agent. In most implementations that I've seen it is the big box that obtains the leases in the first place. So in effect it is not acting as a relay agent, but as a DHCP client. In that case, why forge a DHCPREQUEST on behalf of the PPP user? From owner-dhcp-v4@bucknell.edu Fri Apr 28 13:09:05 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06393 for ; Fri, 28 Apr 2000 13:09:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA16700; Fri, 28 Apr 2000 13:03:15 -0400 (EDT) Received: from gateway.assuredaccess.com (gateway.assuredaccess.com [206.169.126.4]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id NAA21643 for ; Fri, 28 Apr 2000 13:03:09 -0400 (EDT) Received: from assuredaccess.com ([10.193.101.165]) by gateway.assuredaccess.com (Netscape Mail Server v2.0) with ESMTP id AAA204; Fri, 28 Apr 2000 10:04:54 -0700 Sender: owner-dhcp-v4@bucknell.edu Message-ID: <3909C44D.2D317FB2@assuredaccess.com> Date: Fri, 28 Apr 2000 17:03:09 +0000 From: Wim Janssen Organization: Alcatel Telecom X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list CC: DHCPv4 discussion list Subject: Re: Relayed lease extension References: <009E9477.53F62537.18@process.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: wjanssen@assuredaccess.com X-Sender: janssenw X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > In most implementations that I've seen it is the big box that > obtains the leases in the first place. So in effect it is not > acting as a relay agent, but as a DHCP client. In that case, > why forge a DHCPREQUEST on behalf of the PPP user? The big box is both a client and relay agent, which means that all packets are unicasted between client/relay agent and server. The PPP user comes in, asks for an IP address, which initiates DHCP. Once DHCP is finished, the obtained IP address is given to the PPP user. So, DHCPREQUESTs to extend the lease originate on the box, but are 'relayed' to the server. > I think that perhaps the model of the relay agent means you don't have > to have a DHCP "filter" in place. Right. > Since the big box is acting as a router, it would otherwise need to have > code in it to filter off the DHCP packets to prevent them from being > sent to the active client. Indeed, it's not a really good thing to filter such packets on a big box. It's not only about performance, but as a general rule, filtering on these packets is a BAD thing for a big box, especially when it can be prevented in the first place. And there's my original problem: I don't want to snoop for the DHCPACKs that are unicasted to the 'real' client, when the lease is being extended. Apparently, there may be some misunderstanding on what a server should do, when 'giaddr' is filled in. There may be servers that just ignore it, and send the DHCPACK back to 'ciaddr'. :-( Others send it to 'giaddr'. :-) Maybe others don't allow 'giaddr' to be filled in? :-(( So, what is the server supposed to do? Wim From owner-dhcp-v4@bucknell.edu Fri Apr 28 14:01:49 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07426 for ; Fri, 28 Apr 2000 14:01:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA18469; Fri, 28 Apr 2000 13:57:42 -0400 (EDT) Received: from monitor.internaut.com (mg-206253200-16.ricochet.net [206.253.200.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id NAA04893 for ; Fri, 28 Apr 2000 13:57:28 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id KAA76877; Fri, 28 Apr 2000 10:42:18 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: DHCPv4 discussion list Cc: Subject: RE: Relayed lease extension Date: Fri, 28 Apr 2000 10:57:51 -0700 Message-ID: <005101bfb13b$462f6040$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <009E9477.53F62537.18@process.com> Importance: Normal Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit >I think that perhaps the model of the relay agent means you don't have >to have a DHCP "filter" in place. The only reason you'd need a DHCP filter is if you didn't want to allow customers to request more addresses. An example would be where you charge customers more if they are attaching LANs and therefore may want extra addresses from your DHCP server. In this case, the first address is requested by the big box as a DHCP client and given to the customer gateway via PPP IPCP. Subsequent addresses are requested by customer hosts behind the customer gateway via DHCP. Here the customer gateway acts as a bridge (not a relay agent), forwarding received DHCPDISCOVER broadcasts down the link. The big box acts as both a DHCP client (for the initial set of addresses) and a DHCP relay (for subsequent addresses). In this case there is no need for the big box to prevent DHCPOFFERs from going back to the client. The big box just needs to plumb static routes for the addresses that it is relaying to, so that it can know which interface to forward packets on. >Since the big box is acting as a router, it would otherwise need to have >code in it to filter off the DHCP packets to prevent them from being >sent to the active client. Since the big box acts as a DHCP client for the initial set of addresses (which it typically manages out of a pool), DHCPREQUESTS relating to those addresses always originate at the big box IP address and so are not in danger of being sent to the active client, since the include the big box chaddr. For the relayed DHCP traffic, the big box needs to keep track of customer host chaddrs and interfaces. The issue of DHCP filtering and relay agent behavior therefore seem orthogonal to me. From owner-dhcp-v4@bucknell.edu Fri Apr 28 16:57:09 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11458 for ; Fri, 28 Apr 2000 16:57:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA04211; Fri, 28 Apr 2000 16:53:02 -0400 (EDT) Received: from gateway.assuredaccess.com (gateway.assuredaccess.com [206.169.126.4]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id QAA03632 for ; Fri, 28 Apr 2000 16:52:51 -0400 (EDT) Received: from assuredaccess.com ([10.193.101.165]) by gateway.assuredaccess.com (Netscape Mail Server v2.0) with ESMTP id AAA229; Fri, 28 Apr 2000 13:54:39 -0700 Sender: owner-dhcp-v4@bucknell.edu Message-ID: <3909FA62.619F8591@assuredaccess.com> Date: Fri, 28 Apr 2000 13:53:54 -0700 From: Wim Janssen Organization: Alcatel Telecom X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list CC: DHCPv4 discussion list Subject: Re: Relayed lease extension References: <005101bfb13b$462f6040$428939cc@ntdev.microsoft.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Reply-To: wjanssen@assuredaccess.com X-Sender: janssenw X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > The only reason you'd need a DHCP filter is if you didn't want to allow > customers to request more addresses. An example would be where you > charge customers more if they are attaching LANs and therefore may > want extra addresses from your DHCP server. When I said client/relay agent, I was talking about a relay agent that relays the client packets issued on the box itself. It is not supposed to relay packets coming from behind a customer gateway. The PPP user is just using PPP over AAL5 (or over whatever). He's not allowed to have DHCP clients asking for multiple addresses (that's may be another issue, if somebody would want this). BigBox +----------+ |-------|DHCP | DHCPd ------| |client/ | |relay P|---------PPP | P|--------PPP | P| | d|-----------PPP +----------+ > >Since the big box is acting as a router, it would otherwise need to have > >code in it to filter off the DHCP packets to prevent them from being > >sent to the active client. > > Since the big box acts as a DHCP client for the initial set of addresses > (which it typically manages out of a pool), DHCPREQUESTS relating to those > addresses always originate at the big box IP address and so are not in > danger of being sent to the active client, since the include the big box > chaddr. Don't know if I understand this correctly. My point is that DHCPREQUESTs indeed originate on the big box by the client, are relayed to the server, and sent back to ...(?) Note that a static route is set for the IP address that was retrieved by the DHCP client in the box, pointing to the PPP user. A DHCPACK coming from the server towards the client, will be forwarded to the PPP user, unless the server specifically targets 'giaddr'. Wim From owner-dhcp-v4@bucknell.edu Fri Apr 28 18:04:03 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12921 for ; Fri, 28 Apr 2000 18:04:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA14627; Fri, 28 Apr 2000 17:58:24 -0400 (EDT) Received: from alcor.process.com (alcor.process.com [192.42.95.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id RAA18945 for ; Fri, 28 Apr 2000 17:58:11 -0400 (EDT) Received: by process.com (MX V5.1-X A2w8g) id 15; Fri, 28 Apr 2000 17:57:54 -0400 Sender: owner-dhcp-v4@bucknell.edu Date: Fri, 28 Apr 2000 17:57:54 -0400 From: Bernie Volz To: DHCPv4 discussion list CC: dhcp-v4@bucknell.edu Message-ID: <009E94C3.BDA22C64.15@process.com> Subject: Re: Relayed lease extension Reply-To: volz@process.com X-Sender: volz@process.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >The PPP user is just using PPP over AAL5 (or over whatever). >He's not allowed to have DHCP clients asking >for multiple addresses (that's may be another issue, if >somebody would want this). > > > BigBox > +----------+ > |-------|DHCP | >DHCPd ------| |client/ | > |relay P|---------PPP > | P|--------PPP > | P| > | d|-----------PPP > +----------+ > This set-up might be used in other instances where the end-client never gets an address via DHCP itself (if I recall, PPP sends it in the inital negotiation to the client and thus the client isn't running DHCP at all). If the BigBox gets the lease on the address for a shorter time than the client is connected, it will need to renew the lease and hence the situation Wim is looking at. I do think this is a reasonable problem to solve and should be included on the list of issues for revisions to the DHCP RFC. The simply policy of sending the reply to the giaddr might be best and it is consistent with what's done on the initial lease. Note: In the above case, I'm not sure I'd call the "DHCP thing" on the "BigBox" a DHCP Relay. It really is more of a DHCP Client on behalf of the actual client. If it is a classic relay, then as Bernard says, the client is doing DHCP and thus there is no need for the relay to become involved in the renewals. - Bernie From owner-dhcp-v4@bucknell.edu Fri Apr 28 18:19:02 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13095 for ; Fri, 28 Apr 2000 18:19:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id SAA09127; Fri, 28 Apr 2000 18:17:56 -0400 (EDT) Received: from mail.sanlight.com (IDENT:root@mail.sanlight.com [208.184.100.76]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id SAA19425 for ; Fri, 28 Apr 2000 18:17:44 -0400 (EDT) Received: from sanlight.com (IDENT:medi@medi.sanlight.com [208.184.100.70]) by mail.sanlight.com (8.9.3/8.9.3) with ESMTP id PAA05418 for ; Fri, 28 Apr 2000 15:16:41 -0700 Sender: owner-dhcp-v4@bucknell.edu Message-ID: <390A0E02.E798A4F0@sanlight.com> Date: Fri, 28 Apr 2000 15:17:38 -0700 From: Medi Montaseri X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: Options in dhcpd.conf Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: medi@sanlight.com X-Sender: medi@sanlight.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hi, I'm experiementing with overloading a DHCP server to fetch not-so-normal data. In fact some arbitrary data, in fact a list of key-1 => value-1 key-2 => value-2 ... key-n => value-n and so forth. I have decided to use the "options" for this purpose, unless file is better (provide argument). Someone suggested to use Vendor Extensions. Question is "how do I specify Vendor Extensions Option in my dhcpd.conf(4)" I've read the man page on dhcp-2.0-3 (from RedHat 6.1 distribution) and I didn't see any references to Vendor extensions. Any ideas... -- ===================================================================== Medi Montaseri, Software Eng, medi@sanlight.com =====================================================================