|
The reason is that the client is already using the server and
the server is up and running and a REQUEST is the only message that can create
a new binding. While the client COULD return to SOLICIT, that requires more
time and processing than sending a REQUEST does. (It gets more complicated too
if the client has multiple bindings since it could end up communicating with
multiple servers for different bindings which is probably not as desirable.) The client is best to include the addresses it thinks it has in
the REQUEST – the server may or may not assign them to the client (it will
depend on what is in the REPLY). If the client does not include those
addresses, it would be unlikely to get them (as the server has no record of
them!) and that may cause problems because now the client may continue to use
those addresses until the valid lifetime expires but the server has no record
of those addresses being used (which means they could end up being allocated to
another client). This case is really when the server has lost information on the
bindings. -
Bernie From:
dhcwg-bounces at ietf.org [mailto:dhcwg-bounces at ietf.org] On Behalf Of ravi
kumar I need clarification regarding section 18.1.8 of RFC-
3315 : <Copy-paste from RFC> When the client receives a Reply message in response to a
Renew or Incase of Client's message containing only one IA, Is it not
enough that Client starts with Solicit, instead o Request message. Because, incase Client sends Request, then Server would
either respond with a Reply containing different Address (than
requested) / ignores Client's message, since address is not available with
Server. In that case, client finally falls back to Solicit to acquire address. Instead if Client sends Solicit in response to Server's
reply would quicken address acquisition. Please clarify me in this regard regards Ravi |