[dhcwg] additional comments on dhcpv6-24

JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp> Wed, 15 May 2002 18:19 UTC

Received: from optimus.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16527 for <dhcwg-archive@odin.ietf.org>; Wed, 15 May 2002 14:19:19 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA18670 for dhcwg-archive@odin.ietf.org; Wed, 15 May 2002 14:19:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18523; Wed, 15 May 2002 14:17:47 -0400 (EDT)
Received: from ietf.org (odin []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18395 for <dhcwg@ns.ietf.org>; Wed, 15 May 2002 14:16:09 -0400 (EDT)
Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16419 for <dhcwg@ietf.org>; Wed, 15 May 2002 14:15:53 -0400 (EDT)
Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g4FIG2801378 for <dhcwg@ietf.org>; Thu, 16 May 2002 03:16:02 +0900 (JST)
Date: Thu, 16 May 2002 03:16:39 +0900
Message-ID: <y7vk7q5mg3c.wl@ocean.jinmei.org>
From: JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp>
To: dhcwg@ietf.org
User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset="US-ASCII"
X-Dispatcher: imput version 20000228(IM140)
Lines: 54
Subject: [dhcwg] additional comments on dhcpv6-24
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 some additional comments (and questions) on dhcpv6-24,
particularly about server solicitation.

(1) If the client sent a solicit message with a rapid commit option
    but the server responds to the solicitation with an advertise
    message, what should the client do?  Should it ignore the
    advertise, should it accept the advertise and send a request, or
    others?  Section 17.1.4 says

     ...If the client does not
     receive a Reply message, the client restarts the server solicitation
     process by sending a Solicit message that does not include a Rapid
     Commit option.

   So, the client should probably ignore the advertise (and keep
   waiting for a reply.)  But I'm not 100% sure about this.

(2) Section 17.1.2 says:

   If the client is waiting for an Advertise message, the mechanism in
   section 14 is modified as follows for use in the transmission of
   Solicit messages.  The message exchange is not terminated by the
   receipt of an Advertise before IRT has elapsed.  Rather, the client
   collects Advertise messages until IRT has elapsed.

Should this rule apply if the client is retransmitting solicit
messages?  For example, suppose that there is no advertise in response
to the first solicit, and so the client retransmit the solicit.  If
the client then receives a first advertise, should it still wait until
IRT elapses?

(3) The paragraph above then says:
   Also, the first
   RT MUST be selected to be strictly greater than IRT by choosing RAND
   to be strictly greater than 0.

However, according to Section 13, the first RT should be

      RT = 2*IRT + RAND*IRT

where  RAND is a random number chosen with a uniform distribution
between -0.1 and +0.1.  Thus,

      RT >= 2*IRT - 0.1*IRT = 1.9 * IRT >= IRT
      (the rightmost '=' is satisfied only when IRT is 0)

So the RT should always be greater than IRT regardless of the value of
RAND, and "by choosing RAND to be strictly greater than 0" seems to be
redundant.  Is my understanding correct?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.

dhcwg mailing list