[dhcwg] Re: comments on draft-ietf-dhc-lifetime-01.txt

Stig Venaas <Stig.Venaas@uninett.no> Tue, 03 August 2004 03:44 UTC

Received: from megatron.ietf.org (megatron.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26938; Mon, 2 Aug 2004 23:44:24 -0400 (EDT)
Received: from localhost.localdomain ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrqAb-0003R2-JJ; Mon, 02 Aug 2004 23:40:57 -0400
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brq4Y-0008L5-FJ for dhcwg@megatron.ietf.org; Mon, 02 Aug 2004 23:34:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26328 for <dhcwg@ietf.org>; Mon, 2 Aug 2004 23:34:40 -0400 (EDT)
Received: from tyholt.uninett.no ([]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brq7W-0001wJ-Jc for dhcwg@ietf.org; Mon, 02 Aug 2004 23:37:48 -0400
Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i733XwV0016523; Tue, 3 Aug 2004 05:33:58 +0200
Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i733XvvE020604; Tue, 3 Aug 2004 05:33:57 +0200
X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f
Date: Tue, 03 Aug 2004 05:33:57 +0200
From: Stig Venaas <Stig.Venaas@uninett.no>
To: "JINMEI Tatuya / ?$B?@L@C#:H" <jinmei@isl.rdc.toshiba.co.jp>
Message-ID: <20040803033357.GA20506@sverresborg.uninett.no>
References: <y7vhdrl56ol.wl@ocean.jinmei.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <y7vhdrl56ol.wl@ocean.jinmei.org>
User-Agent: Mutt/1.4.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk
Subject: [dhcwg] Re: comments on draft-ietf-dhc-lifetime-01.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org

On Tue, Aug 03, 2004 at 10:52:42AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> Hoping it's not too late, here a couple of comments (or questions,
> actually) on the draft.
> 1. I'm still not really sure what the client should do for information
>    when a lifetime expires.
>    For example, the draft says in Section 3.1 that
>      If client has received a lifetime with this option, and contacts
>      server to receive new or update any existing data prior to its
>      expiration, it SHOULD also update data covered by this option.  If no
>      new lifetime is received, it MUST behave as if no value was ever
>      provided.
>   I don't understand the scenario.  Does this mean the following case?
>   - The client sends an Information-request message, and gets a reply
>     with a DNS server address (call it X) with lifetime of 1 hour.
>   - 30 minutes later, the client happens to resend an
>     Information-request message.  This time, it gets a response, but
>     the response does not contain either DNS server address X or a new
>     lifetime.
>   If this is an intended scenario, then what does "behave as if no
>   value was ever provided"?  Does it mean the client MUST treat
>   address X as if it had infinite lifetime?  Or does this mean the
>   client MUST regard address X expired immediately?  Or something
>   else?

I'm open for anything. But my intention is that client behaves as if
it didn't get a lifetime in the first place. That is, just like it would
behave if it doesn't know a specific lifetime. Whether it's infinite or
not, depends on the client.

I don't think this scenario will be common anyway, but we should say
something. My thinking is that the last response is the authoritative
one, so new lifetime value overrides the old, and no lifetime means
ignore the old and behave like you haven't ever seen one.

Another option would be to keep using the last seen lifetime until
expiry, but I'm not sure that's better.

Very happy to see suggestions for alternative behaviour, or for text
changes that makes it more clear.

>   Also, I don't understand what the client should do with DNS server
>   address X when the lifetime expires and the client does not get any
>   reply for the try to update the information.  Should the client
>   invalidate address X?  Can/should it continue to use it?

I think it can be left to the client. The client will retry for a long
period of time, and would usually get updated info; the lifetime simply
says when to start this process. So you're talking about a rare failure
case. I think it's sensible to keep using the info, at least if there
is nothing to fall back to.

I'm thinking of the option as a hint to the client when it should try
to update the info. I'm not sure if we need to specify the failure
modes in detail.

>   Even if the client can update the information of address X with a
>   new lifetime, how can we regard the period from the time when the
>   previous lifetime expires and the time when the client gets the new
>   information?  Should we temporarily invalidate the address during
>   the update period?  Or Can we continue to use it?  Probably the
>   latter makes sense when the client can update the information, but
>   it does not really match my intuition of "expiration"...

My intention is definitely that you should continue using it. I guess
that should be made clear.

> 2. the usage of the lifetime option for other exchanges than
>    Info-req/Reply exchanges.
>    I'm even not 100% sure if the lifetime can be used for the other
>    types of exchanges.  Probably it can according to the draft, but
>    then I'll have several questions on how to use it.
>    For example, the draft says:
>      Before making the request it MUST wait for a random amount of time
>      between 0 and INF_MAX_DELAY.  INF_MAX_DELAY is defined in [RFC 3315].
>   Is this also applies to the other cases even if INF_MAX_DELAY is a
>   dedicated parameter for Info-req?  If so, is it really valid?
>   Also, how does the client exactly react to the expiration event for
>   the other cases?  For example, consider the following scenario:
>   - the client performs Solicit->Advertise->Request->Reply exchanges,
>     and gets an IPv6 address allocated, a DNS server address X, and an
>     associated lifetime T.
>   - before the timeout "T1" for the allocated address passes, lifetime
>     T expires.  In this case, should the client restart the entire
>     session from Solicit?  Or should the client send a renew message?
>     If so, the renew message also tries to update the allocated
>     address even if it's too early?  Or should the client even start
>     Information-request/Reply exchanges just to update the DNS address
>     information?

I agree, this needs more thought. So first question is whether we should
support stateless only. Stateless is what I'm focusing on, but when I
wrote it I thought it could also be of use for stateful case. As it says,
the option only specifies a lifetime for options that don't have an
associated lifetime. I think doing Information-request/Reply exchange just
to update the DNS address information is fine, but would it be a problem
to renew everything?

> As an implementor, it's very hard to implement this option with
> confidence just from this specification...

Right. I think this is very good input. I would like to get more input
on which behaviour people think is best. Then I'll try to make the text


dhcwg mailing list