[dhcwg] Rebind failure behavior

"Guja, ArturX" <ArturX.Guja@intel.com> Fri, 21 September 2001 14:04 UTC

Received: from optimus.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25879; Fri, 21 Sep 2001 10:04:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14512; Fri, 21 Sep 2001 10:03:39 -0400 (EDT)
Received: from ietf.org (odin []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14487 for <dhcwg@ns.ietf.org>; Fri, 21 Sep 2001 10:03:36 -0400 (EDT)
Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25846 for <dhcwg@ietf.org>; Fri, 21 Sep 2001 10:04:13 -0400 (EDT)
Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com []) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4, v 1.42 2001/09/04 16:24:19 root Exp $) with SMTP id OAA24185 for <dhcwg@ietf.org>; Fri, 21 Sep 2001 14:03:35 GMT
Received: from fmsmsx29.FM.INTEL.COM ([]) by fmsmsxvs042.fm.intel.com (NAVGW with SMTP id M2001092107030409746 for <dhcwg@ietf.org>; Fri, 21 Sep 2001 07:03:04 -0700
Received: from alpha.igk.intel.com ([]) by fmsmsx29.FM.INTEL.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T2T6YNRF; Fri, 21 Sep 2001 07:03:38 -0700
Received: by alpha.igk.intel.com with Internet Mail Service (5.5.2653.19) id <NMB581Z5>; Fri, 21 Sep 2001 16:03:30 +0200
Message-ID: <413FBB0BA5AED1119122000083234B1A0247B438@alpha.igk.intel.com>
From: "Guja, ArturX" <ArturX.Guja@intel.com>
To: "Dhcwg (E-mail)" <dhcwg@ietf.org>
Date: Fri, 21 Sep 2001 16:03:29 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-2"
Subject: [dhcwg] Rebind failure behavior
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org


I have encountered one totally counter-intuitive thing in the
draft 19.

The text reads as follows:
" The server will respond to the Rebind message with a Reply message.
   If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
   the client retransmits the Rebind with the same transaction-ID, and
   doubles the REP_MSG_TIMEOUT value, and waits again.  The client
   continues this process until a Reply is received "

So, basically, if the first server is down, and no other server
is willing to respond to a REBIND (they don't have to, if they do
not "feel" authoritative about this particular client's leases)
the client goes HANG and stays there.

I believe this will have to be changed to some timeout or

Artur Guja

dhcwg mailing list