[e2e] TCP Option Negotiation

[Bob Braden]

  *> 
  *> Ralph,
  *> 
  *> I thought a moment about this while I was writing the previous note. 
  *> It seems to me that it's in fact less desirable to put this at the 
  *> server end, because of difficulty in perfectly identifying when a 
  *> client is "new", and perhaps because it's silly to add more dynamic 
  *> state to a server when you don't need to.
  *> 
  *> it seems better to put the function at the client. Only the client 
  *> knows for sure whether it has enough retained state to safely ignore 
  *> a possible quiet time. Implementationally, it should be trivial for 
  *> any client that implements quiet times at all to add "new DHCP 
  *> address" to the list of things that trigger one.
  *> 
  *> John
  *> 

John,

Your objection seems to be met if the DHCP server simply sequesters
a released IP address for the TCP quiet time before reassigning it
to ANY host.  That seems to be the conservative approach to fixing
the problem we just stumbled into.

Anyway, doesn't the potential for old duplicates exist no matter
whether the client is "new" or "old"?  If any host dynamically
receives an IP address that is still "warm", there is in theory
the potential for old duplicates confusing a new TCP connection,
yes?

Bob