Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt)

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

>>>>> On Wed, 1 Sep 2004 14:30:29 +0200, 
>>>>> Stig Venaas <[e-mail]> said:

> What you write sounds reasonable, but I'm still not sure we should go
> into the details. The reason is that we don't know in general what
> the behaviour should be, and it's a generic issue. It's obviously a
> related issue though. We could as Ted suggests, specify this later
> when we have more information. That could either be as an update to
> the lifetime RFC, or IMO perhaps better, add some text if an update
> to RFC 3315 is done. There seems to be other reasons to update RFC
> 3315 too (draft-jinmei-dhc-dhcpv6-clarify-auth-00?).

I would first like to note that the suggestion by Ted of leaving it to
a later document was followed by his response to me where he agreed
(or at least seemed to agree) with my proposal.

Secondly, if I understand the sense in this list correctly, I believe
my proposal reflects some level of consensus here.

Third, I personally think we can reflect the proposal without making
the document unnecessarily long.  (If you want, I'll try to contribute
to some text.)

So, I personally think it makes sense to clarify the points at this
chance even though the points can be extended to general issues.

...but I don't want to delay this important work due to my pedantic
ego.  If others still want to leave those points to other documents,
I'll obey that decision (but at least I want the "lifetime" document
to mention those a bit and to say that those are beyond the scope of
the doc).

> In general I agree with your distinction between still and moving
> clients. What worries me though, is that it might not be possible for
> a client to distinguish between movement and renumbering. The fact
> that a new prefix is announced in RAs is not sufficient.

As I said in my previous message, I basically think we can concentrate
on the "still" clients in this document, and do not have to worry
too much about miscellaneous subtle cases of moving vs
not-actually-moving.  Movement detection is itself a difficult
challenge (we even have a dedicated wg on this!), so I think it is
enough in the scope of dhc wg to show some preliminary considerations
on the moving clients (e.g., as shown in Section 18.1.2 of RFC3315.).

Besides, I don't see an actual problem in that particular case you
raised above, along with my proposed approach.  If the client
misunderstands that it has moved to a different link while it
actually stays in the same link, the client will resend an
Information-request message immediately based on the proposed
scenario.  In this case, however, the legitimate DHCPv6 server should
still be there and will respond to the Information-request with valid
configuration information.  (request storm might be an issue, but
confusing events like renumbering should be rare).

On the other hand, if the client misunderstands that it stays in the
same link while it has actually moved, the client will perhaps have a
trouble.  Along with the proposed approach, however, I think we don't
have to worry about that within the scope of this document; we'll
basically note that issues regarding moving clients are difficult and
will need future analysis.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[e-mail]

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg