Subject: [dhcwg] Issues related to Status code option

From: Maverick <[email-masked]>
Date: Mon, 8 Oct 2007 17:02:04 +0530

Hi All,
Here are a few doubts regarding sending status code option in various
scenario listed below:

Scenario 1::
Server has one (last) IP address remaining to be leased and the client sends
a solicit with request for 2 IANA Address.
Now how should the response look like, where and what status code should be
present in the advertise message:

Will the following be correct?

Message (Advetise)
-----> Status Code (Blank/Success)

        IA
         -----> Status Code (Blanks or success)

              IAaddr 1
              -----> Status Code (Blank or success)

              IAaddr 1
              -----> Status Code (NoAddrsAvail)

Scenario 2::
The client sends a renew or rebind for an address for which the server has
no lease information.

Will the following status code options in reply message be considered
correct?

Message (reply)
-----> Status Code (Blank/Success)

         IA
         -----> Status Code (Blanks or success)

                IAaddr 1
                 -----> Status Code (NoBinding)

The reason being there could be a possibility for 2 addresses being sent for
renew or rebind in the same renew message.

Scenario 3:

For scenario's where life times are set to 0 to indicate a faliure scenario.
(eg: an address is not on link, for a renew)
Do we need to send and explicit Status code, if so then what should be
retured and where is it mentioned in the RFC.
Else is 0 sufficient.

Thanks,

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 9 Oct 2007 07:52:16 -0400

My interpretation of RFC 3315 is:
 
For Scenario 1:
 
There is no status code message option in the returned Advertise.
 
Technically there is no way for a client to "request 2 IA_NA addresses"
in a Solicit. And, RFC 3315 states: "If the client has included
addresses in the IAs in the Solicit message, the server uses those
addresses as hints about the addresses the client would like to
receive." Note that the server would not return a 2nd IAADDR and the
first IAADDR may not be the client requested address. (If the server
will not honor the client's requested addresses, it simply leaves the
OUT of the Advertise.)
 
I think a more interesting scenario might be if there are TWO IA_NA
options and the server can assign only one address (to the first IA_NA)
but not to the second (because the server hits some limit). Again, there
is no status code option and the resulting response has BOTH IA_NA
options, but only one has an IAADDR option under it.
 
I take the paragraph:
"If the server will not assign any addresses to any IAs in a subsequent
Request from the client, the server MUST send an Advertise message to
the client that includes only a Status Code option with code
NoAddrsAvail and a status message for the user, a Server Identifier
option with the server's DUID, and a Client Identifier option with the
client's DUID."

To mean that a NoAddrsAvail is ONLY returned if the server will not
assign ANY addresses at all.

For Scenario 2:

The NoBinding status is ONLY returned if the binding doesn't exist --
not if the server does not know about that address. By binding, this is
the IA_* type and IAID. This is based on the following text:
When the server receives a Renew message that contains an IA option from
a client, it locates the client's binding and verifies that the
information in the IA from the client matches the information stored for
that client. If the server cannot find a client entry for the IA the
server returns the IA containing no addresses with a Status Code option
set to NoBinding in the Reply message.

So, now lets assume the server knows about the binding (IA_* type and
IAID value). Then:
If the server finds that any of the addresses are not appropriate for
the link to which the client is attached, the server returns the address
to the client with lifetimes of 0.

If the server finds the addresses in the IA for the client then the
server sends back the IA to the client with new lifetimes and T1/T2
times. The server may choose to change the list of addresses and the
lifetimes of addresses in IAs that are returned to the client.

This covers the case about "not appropriate" addresses and for found
addresses, but not for addresses not found in the binding that might
have been sent by the client. We presently treat those as "not
appropriate" and send lifetimes of 0 back to the client.
 
The REBIND case is a bit less clear as the text doesn't state what
should happen if the server can NOT find the binding, but the addresses
are on-link. It never says to send "NoBinding", for example. The text
states:
When the server receives a Rebind message that contains an IA option
from a client, it locates the client's binding and verifies that the
information in the IA from the client matches the information stored for
that client.

If the server cannot find a client entry for the IA and the server
determines that the addresses in the IA are not appropriate for the link
to which the client's interface is attached according to theserver's
explicit configuration information, the server MAY send a Reply message
to the client containing the client's IA, with the lifetimes for the
addresses in the IA set to zero. This Reply constitutes an explicit
notification to the client that the addresses in the IA are no longer
valid. In this situation, if the server does not send a Reply message it
silently discards the Rebind message.

I'm not sure what was intended here if an unknown binding is received,
but we just ignore bindings that are in the REBIND for which we have no
record and for which the addresses are all on-link. [The other option is
to treat this much like a Request and create the bindings and attempt to
assign the leases if possible or create new ones, but I don't think that
was the point of a REBIND.]

For Scenario 3, no you do NOT send a status code per RFC 3315.

Note that while the text in RFC 3315 could be more explicit about what
to do for each case, I think the general rules are:

- New bindings are created only by Solicit and Request messages (they
MUST be created for Request).

- When a binding exists (Renew/Rebind) and an addresse received is not
on-link, this doesn't invalidate the client but instead is used to
gracefully transition the client out of that address by sending 0
lifetimes instead of NotOnLink. This, for example, handles a renumbering
event more gracefully by telling the client to stop using the old
address and a new address can be provided (or other addresses it has can
continue to be used).

- For a REBIND, a client should not respond if it has no binding
information. This allows OTHER servers that do have this information to
respond. Hence, the "In this situation" text quoted above, I think this
applied to "If the server cannot find a client entry for the IA".

Perhaps this is more information than you wanted. Hopefully I've answer
those that you asked. Hopefully others agree with my responses.

- Bernie

________________________________

From: Maverick [mailto:[email-masked]] 
Sent: Monday, October 08, 2007 7:32 AM
To: DHC WG
Subject: [dhcwg] Issues related to Status code option

Hi All,

Scenario 1:: 
Server has one (last) IP address remaining to be leased and the client
sends a solicit with request for 2 IANA Address.
Now how should the response look like, where and what status code should
be present in the advertise message: 

Message (Advetise)
 
        IA
 
              IAaddr 1
  
              IAaddr 1

Scenario 2::
The client sends a renew or rebind for an address for which the server
has no lease information.

Message (reply)
 
         IA
 
                IAaddr 1
  
The reason being there could be a possibility for 2 addresses being sent
for renew or rebind in the same renew message.

Scenario 3:

For scenario's where life times are set to 0 to indicate a faliure
scenario. (eg: an address is not on link, for a renew)
Do we need to send and explicit Status code, if so then what should be
retured and where is it mentioned in the RFC. 
Else is 0 sufficient.

Thanks,

-Maverick