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

[Ralph Droms <[e-mail]>]

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:

>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:[e-mail]>mailto:[e-mail]]
>Sent: Wednesday, May 08, 2002 11:07 AM
>To: [e-mail]
>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
>[e-mail]
><https://www1.ietf.org/mailman/listinfo/dhcwg>https://www1.ietf.org/mailman/listinfo/dhcwg 
>


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