RE: [dhcwg] dhcpv6-24: movement detection and Confirm message

"Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> Thu, 09 May 2002 13:27 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 JAA20236 for <dhcwg-archive@odin.ietf.org>; Thu, 9 May 2002 09:27:15 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA25525 for dhcwg-archive@odin.ietf.org; Thu, 9 May 2002 09:27:24 -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 JAA25320; Thu, 9 May 2002 09:24:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25289 for <dhcwg@optimus.ietf.org>; Thu, 9 May 2002 09:24:28 -0400 (EDT)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20001 for <dhcwg@ietf.org>; Thu, 9 May 2002 09:24:19 -0400 (EDT)
Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g49DORl09110 for <dhcwg@ietf.org>; Thu, 9 May 2002 08:24:27 -0500 (CDT)
Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g49DOR517901 for <dhcwg@ietf.org>; Thu, 9 May 2002 08:24:27 -0500 (CDT)
Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Thu May 09 08:24:26 2002 -0500
Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <KRTWARWL>; Thu, 9 May 2002 08:24:26 -0500
Message-ID: <66F66129A77AD411B76200508B65AC69B4D3D7@EAMBUNT705>
From: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
To: "'Thomas Narten'" <narten@us.ibm.com>, Ralph Droms <rdroms@cisco.com>
Cc: dhcwg@ietf.org
Subject: RE: [dhcwg] dhcpv6-24: movement detection and Confirm message
Date: Thu, 9 May 2002 08:24:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F75C.D6E135A0"
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

Thomas:

My desire for the Confirm would be as follows:

- Client can send a Confirm to help in movement detection. It shouldn't be required for the client to do this since it may have other means of doing this.

- A server that does implement Confirm handles the message in three ways:
1. If it has the binding for the client and the addresses are valid, it can send a Reply with the success indication. This would be the case if the client hasn't really moved.

2. If it doesn't have a binding but in comparing the addresses provided in the Confirm, the server can determine that the prefixes for the addresses are NOT valid for the link, the server can Reply to the client that the addresses are bad.

3. The server discards the Confirm since it can not verify that the addresses are truely valid for the client.

(We could allow another Reply from the server that would indicate to the client that the prefixes appear to be valid, but it can't confirm the actual addresses. However, this isn't really necessary since no response to the Confirm essentially means that and it could give false information at times; that is why it would be best not to have servers do this.)

- While I think servers SHOULD implement Confirm, they don't have to. If they don't, they won't enhance movement detection but since there are other mechanisms that can help with this, it is not required.

- Confirm processing is much different than a Renew/Rebind. There is much less work involved on the server - it is only verifying the information. A Confirm can NOT be used to extend address lifetimes/leases. IMHO, it should only be used to help the client determine whether it moved.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Thursday, May 09, 2002 9:00 AM
To: Ralph Droms
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6-24: movement detection and Confirm message 



> Confirm - client has detected it may have moved, sends
>            Confirm to any available server to determine
>            if configuration is still valid
> Renew   - client unicasts to assigning server to extend
>            lease on IA
> Rebind  - client sends to any available server to extend
>            lease on IA

Including the above in the overview would be very helpful. It's not
clearly described there, and the above description really helps me to
understand why/how the messages differ.

> Thomas - rereading your original question, I'm not sure if you're 
> suggesting that a client not try to detect if it has moved to a new link, 
> or if it use a Renew instead of a Rebind when it detects it may have moved 
> to a new link.

I believe a client should definitely try to detect when it has
moved. What I was wondering about is whether DHC should be specifying
*how* it does movement detection (since this is a general topic), and
whether DHC should provide explicit mechanisms (beyond other existing
message types) that help the client determine if it has moved.

Seems to me the Confirm is (maybe?) just an optimization. Couldn't the
client just send a Renew to the assigning server?

I gather that one advantage of the Confirm is that it is sent to all
servers, so one will respond quickly. If the client sends a Renew to a
specific server, but the client has moved, the Renew will presumably
time out, which takes a lot longer. But in terms of the amount of work
a server has to do when processing Confirm vs. Renew, the work is
pretty much the same, I would think.  I assume that this is the
motivation for Confirm.

Question: when one sends a confirm, does only the server that has that
information respond, or are all servers expected to respond?

The text says:

>    In any situation when a client may have moved to a new link, the
>    client MUST initiate a Confirm/Reply message exchange.  The client
>    includes any IAs, along with the addresses associated with those IAs,
>    in its Confirm message.  Any responding servers will indicate the
>    acceptability of the addresses with the status in the Reply message
>    it returns to the client.


But how do other servers know that they are to respond positively? I
would expect that only server that originally allocated the addresses
to be able to respond positively that the config is valid. Maybe the
text isn't explicit enough about what a server does when it gets a
Confirm. Does it just check that the  addresses are on the link as
indicated by the link-address field in the relayed packet? This would
be sufficient to verify that client hasn't moved. If it needs to
verify that the actual addresses have been assigned  it's not clear
that any server can do that. This makes me wonder if this is really
very much better than just  using Renew (if only one server can
respond anyway).

The text says (under server processing):

>    If the server finds that the information for the client does not
>    match what is in the binding for that client or the configuration
>    information is not valid, the server sends a Reply message containing
>    a Status Code option with the value ConfNoMatch.

I think more text would be good to make it clear that a server can also
respond positively even if it can't verify the actual
binding. Likewise, a positive response in that case DOSE NOT actually
confirm the binding, just that the node hasn't moved.

Make sense?

> I think from:

> >if a client detects that it has
> >moved, then just have it redo the normal DHC exchanges.

> you mean keep movement detection but use different DHCP messages.  Exactly 
> what did you have in mind for "normal DHCP exchange"?

Renew, Rebind and or just restarting with solicit.

> The idea behind 
> Confirm is (as is the case in DHCPv4) if the client has not moved (e.g., 
> the client has been power cycled), the client uses a two message exchange 
> with any available server rather than a four message exchange.

This assumes that *any* server is in a position to respond
definitively. This is not immediately clear to me per above.

> Perhaps Confirm overlaps with Rapid Commit?

Hmm.

Thomas

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