Re: [dhcwg] additional comments on dhcpv6-24

Ted Lemon <Ted.Lemon@nominum.com> Wed, 15 May 2002 20:05 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20782 for <dhcwg-archive@odin.ietf.org>; Wed, 15 May 2002 16:05:54 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA27957 for dhcwg-archive@odin.ietf.org; Wed, 15 May 2002 16:06:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27826; Wed, 15 May 2002 16:04:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27800 for <dhcwg@ns.ietf.org>; Wed, 15 May 2002 16:04:41 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20720 for <dhcwg@ietf.org>; Wed, 15 May 2002 16:04:24 -0400 (EDT)
Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g4FK1VS07754; Wed, 15 May 2002 13:01:31 -0700 (PDT)
Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g4FK2kd02002; Wed, 15 May 2002 15:02:46 -0500 (CDT)
Date: Wed, 15 May 2002 15:02:45 -0500
Subject: Re: [dhcwg] additional comments on dhcpv6-24
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v481)
Cc: dhcwg@ietf.org, "'JINMEI Tatuya / ????'" <jinmei@isl.rdc.toshiba.co.jp>
To: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D428@EAMBUNT705>
Message-Id: <B8DAEA4E-683E-11D6-B998-00039367340A@nominum.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.481)
Content-Transfer-Encoding: 7bit
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
Content-Transfer-Encoding: 7bit

> Regarding (2), good question ... I would say it should. The logic might 
> simply be send a Solicit, wait IRT, check if any Advertises received ... 
> if so, go use them otherwise send Solicit again.

I think it makes more sense to say that if IRT has elapsed since the first 
Solicit was sent, the client just takes the first Advertise it gets.   This 
is how I implemented the ISC DHCPv4 client, and it seems to work pretty 
nicely.


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg