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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 8 May 2002 11:15:52 -0500

I don't have a major issue if we dropped Confirm.

It is just one of the ways a client could determine whether it moved; it really isn't a requirement to have within the DHCP specification.

Do note however that since RAs don't have a unique link ID (yet?) and a RA might contain no prefixes (just have the "M" flag set), and in this case Confirm could be useful.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Wednesday, May 08, 2002 11:07 AM
To: [email-masked]
Subject: [dhcwg] dhcpv6-24: movement detection and Confirm message

> 18.1.2. Creation and transmission of Confirm messages
> 
>    Whenever a client may have moved to a new link, its IPv6 addresses
>    and other configuration information may no longer be valid.  Examples
>    of times when a client may have moved to a new link include:
> 
>      o The client reboots
> 
>      o The client is physically disconnected from a wired connection
> 
>      o The client returns from sleep mode
> 
>      o The client using a wireless technology changes access points
> 
>    In any situation when a client may have moved to a new link, the
>    client MUST initiate a Confirm/Reply message exchange.  The client

Hmm. I wonder if movement detection should just be dropped from
DHC. The problem of determining whether you have reconnected to a new
link is a generic problem, not just one that DHC has. If you have
routers, for example, you could use RAs to determine that you have
moved, which would then retrigger DHC (as appropriate). I could
imagine an RA option that included a unique identifier for the link
(this might be useful for mobility in general). Or, you could just see
of the router you were using has changed (its link-local address is an
identifier). Or, use the set of on-link prefixes on the RA. If they
are the same as before, you presumably haven't moved. Having the
client send DHC messages to the server to determine whether it has
moved seems like a fair amount of overhead and sub optimal.

Also, if one dropped the movement detection from DHC, would this allow
you to do away with the Confirm? I.e., if a client detects that it has
moved, then just have it redo the normal DHC exchanges. That would
seem simpler. Plus, if a node has actually moved, the confirm will
fail, and the normal DHC exchanges have to be used anyway.

Thomas

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

---

From: Ralph Droms <[email-masked]>
Date: Wed, 08 May 2002 19:26:34 -0400

We have three different messages that are used in three different situations:

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

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 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"?  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.

Perhaps Confirm overlaps with Rapid Commit?

- Ralph

At 11:15 AM 5/8/2002 -0500, Bernie Volz (EUD) wrote:

>It is just one of the ways a client could determine whether it moved; it 
>really isn't a requirement to have within the DHCP specification.
>
>Do note however that since RAs don't have a unique link ID (yet?) and a RA 
>might contain no prefixes (just have the "M" flag set), and in this case 
>Confirm could be useful.
>
>- Bernie
>
>From: Thomas Narten [<mailto:[email-masked]>mailto:[email-masked]]
><https://www1.ietf.org/mailman/listinfo/dhcwg>https://www1.ietf.org/mailman/listinfo/dhcwg 
>

---

From: Thomas Narten <[email-masked]>
Date: Thu, 09 May 2002 08:42:09 -0400

> It is just one of the ways a client could determine whether it
> moved; it really isn't a requirement to have within the DHCP
> specification.

Right.

> Do note however that since RAs don't have a unique link ID (yet?)
> and a RA might contain no prefixes (just have the "M" flag set), and
> in this case Confirm could be useful.

I think that future work might better handle this.

One approach might be to leave the Confirm stuff in for now, and if
better or more general ways of detecting movement are defined, drop
the config stuff in a revision. On the other hand, once its in the
spec, servers will have to implement it forever, so taking it out only
effects clients...

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Thu, 09 May 2002 08:59:35 -0400

> Rebind  - client sends to any available server to extend

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.

> or if it use a Renew instead of a Rebind when it detects it may have moved 

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:

>    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?

> what did you have in mind for "normal DHCP exchange"?

Renew, Rebind and or just restarting with solicit.

> The idea behind 

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