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

But a Renew is only directed to the one server and it is down or not on the network, the client gets no response. What should it do?

If it gets a Reply, it does know it is on the same network as before.

If it gets no Reply, it knows only that it may not be on the same network OR that the original server is down.

There, I think Renew isn't as useful as Confirm.

- Bernie

-----Original Message-----
From: Bound, Jim [mailto:Jim.Bound@hp.com]
Sent: Sunday, May 12, 2002 12:58 AM
To: Thomas Narten; Bernie Volz (EUD)
Cc: dhcwg@ietf.org
Subject: RE: [dhcwg] dhcpv6-24: movement detection and Confirm message 

How about we drop it and permit Renew to to confirm if it wants to?

/jim

> -----Original Message-----
> From: Thomas Narten [mailto:narten@us.ibm.com]
> Sent: Thursday, May 09, 2002 8:42 AM
> To: Bernie Volz (EUD)
> Cc: dhcwg@ietf.org
> Subject: Re: [dhcwg] dhcpv6-24: movement detection and 
> Confirm message 
> 
> 
> > 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
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

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