Subject: RE: [dhcwg] questions about dhcpv6-28

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Tue, 14 Jan 2003 08:32:29 -0600

Here's my take on these questions ... I don't see anything that would require any
corrective text in the draft, though as always anything one writes is subject to
interpretation! Writing the drafts (RFCs) is really much more complicated then it
looks at first! I think your interpretation was correct which is good news!

See below, prefixed by "BV>".

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, January 14, 2003 2:32 AM
To: [email-masked]
Subject: [dhcwg] questions about dhcpv6-28

I have several questions on draft-ietf-dhc-dhcpv6-28.txt from my
implementation experiences.  (It is probably too late to reflect the
points to the spec before it becomes an RFC, though.)

I'd apologize in advance if some (or all) of them were addressed in
the draft, but I could not find the answers.

1. Section 18.1.8 says:

   When the client receives a NoBinding status in an IA from the server
   in response to a Renew message or a Rebind message, the client sends
   a Request to reestablish an IA with the server.

does this imply that the client must remove the IA before sending the
request?  (I guess the answer is YES, but I'm asking this to be sure.)

BV> No. As long as the address has a valid lifetime left, the client
BV> should be able to use that address. NoBinding just means that the
BV> server has no record of that binding (perhaps it is a new server
BV> or a server that losts its stable storage). While this situation
BV> is not desireable, it is possible and should work out OK.

2. What should a client do if it receives an IA_NA in a reply message
   where T1 > T2 > 0?
   a) the client must ignore the option (or the entire reply message)
   b) the client must treat as if T1 = T2
   c) the client must choose appropriate alternatives for T1 and T2.
    (this cannot be an option, though, because Section 22.4 says the
     client MUST use T1 and T2 if they are non-0)
   d) others

   FYI: Our implementation currently takes the option a).

BV> (a) is probably a fine action as it really is invalid. T1 <= T2.

3. What should a server do when it receives a request message and
   already has a binding required in the request?  (this can happen if
   the first reply was lost and the client resend the request
   message.)

  FYI: Our implementation currently updates parameters
  (e.g. lifetimes) of the binding and sends a reply with the
  parameters, just like the server receives a renew message for the
  binding.

BV> A retransmitted Request (because the client failed to receive the
BV> Reply) can either be treated as you describe or you can send the
BV> current values (if they are still valid). A server might, for
BV> example, have a cache of recently sent Replies and in this case it
BV> may resend what it sent the first time.

4. Section 18.1.8 says

   When the client receives a NoAddrsAvail status from the server in
   response to a Request, the client can either try another server
   (perhaps restarting the DHCP server discovery process) or use the
   Information-Request to obtain configuration parameters only.

This sentence is not very clear to me.  I interpreted this sentence
corresponds to the following part of Section 18.2.1:

   If the server cannot assign any addresses to an IA in the message
   from the client, the server MUST include the IA in the Reply message
   with no addresses in the IA and a Status Code option in the IA
   containing status code NoAddrsAvail.

If so, there may be other IAs that do not contain NoAddrsAvail status
code.  In this case, what should the client do for the other IAs?

BV> It should use those addresses or Release them.

Or, does Section 18.1.8 mean a NoAddrsAvail code in the DHCPv6 options
field (i.e. not in an IA)?

BV> It is the status code option in the IA option.

5. Section 18.1.3 says:

   ...The
   client includes an IA option with all addresses currently assigned to
   the IA in its Renew message.

and Section 18.2.3 has corresponding sentences:

   If the server finds that any of the addresses are not appropriate
   to 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.

That is, (in my understanding)

- the client sends all addresses for an IA to be renewed.
- (if the binding is still valid) the server returns all the addresses
  for the IA with 0 or larger lifetimes.

Now, what if the client finds a lack of addresses in the reply message
for the IA?

  a) the client should ignore the entire IA (or the entire reply)
  b) the client should let the dropped address expire (unless there's
     no more update)
  c) others

FYI: Our implementation currently takes the option b), though we do
this for prefixes in an IA_PD option, not for addresses.

BV> Option b is correct. The lifetime controls the when addresses on the
BV> client expire. Thus, if a server stops Replying with that address,
BV> the lifetimes will not be updated and eventually the address expires.

6. there seems to be a corner case about handling the Rapid Commit
   option.  Section 17.1.3 says:

   ... If it does
   not receive such a Reply message and does receive a valid Advertise
   message, the client processes the Advertise message as described in
   section 17.1.3.

But what should the client do if it receives a reply message for a
solicit message with a Rapid Commit option after receiving an
advertise message?  Should the client ignore or accept it?  In the
latter case, what if the client has already sent a request message
(then it will receive a different reply)?

BV> The client must wait for a time period after sending a Solicit for
BV> replies from servers. I assume you are saying what happens if after
BV> this initial wait time (described in 17.1.2) the client receives
BV> (or has received) an Advertise and uses it. But then while waiting
BV> for the Reply (to the Request), it receives a (much delayed) Reply
BV> with Rapid Commit? In that case, I think it is really implementation
BV> dependent on what the client does. In my mind, I think it is easier
BV> for the client to continue processing the Advertise / Request / Reply
BV> procedure that it started. But, the client COULD use the Reply with
BV> Rapid Commit if it wanted and it has an acceptable response (ie,
BV> addresses). In either case, one set of server assigned addresses will
BV> not end up being used by the client and the server will reclaim them
BV> once the lifetimes expire. I think dropping the Reply w/Rapid Commit
BV> is easier and better from an implementation standpoint (the reason
BV> is that the client only needs to remember one thing - the Reply it
BV> is waiting for and discards all others).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 23 Jan 2003 16:22:07 +0900

Hello, thanks for the quick response, and sorry for not responding
sooner.

>>>>> On Tue, 14 Jan 2003 08:32:29 -0600, 
>>>>> "Bernie Volz (EUD)" <[email-masked]> said:

I see.  Then I have a related question.  Does the client continue or
stop sending Renew or Rebind in this case?

Also, I happened to have a chance to discuss this case with Ralph,
and, according to the discussion, I have an impression that the
wording could be a bit clearer.  Sections 18.2.3 and 18.2.4 have
exactly the same sentence:

   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.

according to Ralph, however, the semantics of "the server cannot find
a client entry" is slightly different between the case of renew and
the case of rebind.  For the case of renew, the message is only
accepted by the responsible server, so the semantics should have a
"relaxed" sense.  For the case of rebind, however, the message is
accepted by all possible servers.  Thus, in this case, the semantics
should have a "strict" sense, that is, the server should not send the
NoBinding unless it has an explicit knowledge that the binding has
been invalidated.

So, for example, suppose a server has rebooted and has lost all
bindings.  When the server receives a Renew or Rebind message after it
reboots, the appropriate behavior depends on the message type:
  - for Renew, the server must reply with a NoBinding code.
  - for Rebind, the server must ignores the message (not to confuse
    the recipient).

It seems to me the current text does not express the sense, and it
could be a source of interoperability problems.  (I've actually seen
some interoperability issues among several implementations).

Okay.

Okay.

Okay, but it would be good if Section 18.1.8 is more clear on this, like:

    When the client receives a NoAddrsAvail status for an IA from the
    server in response to a Request, the client can either try another
    server (perhaps restarting the DHCP server discovery process) or
    use the Information-Request to obtain configuration parameters
    only.

Okay.

I concur.  Thanks for the detailed explanation.

					JINMEI, Tatuya

---

From: Ralph Droms <[email-masked]>
Date: Thu, 23 Jan 2003 16:29:55 -0500

Comments in line...

- Ralph

At 04:22 PM 1/23/2003 +0900, JINMEI Tatuya / 
>some interoperability issues among several implementations).

As Jinmei-san and I discussed, the Renew and Rebind cases are different.
In the case of Renew, the server from which the client obtained the IA
is identified by the Server Identifier option, so the server can
authoritatively respond with NoBinding.

The specification is ambiguous about the use of the Server
Identitifier option.  Section 18.1.3, "Creation and Transmission of
Renew Messages" of draft-ietf-dhc-dhcpv6-28.txt requires that the
client include "the identifier of the destination server in a Server
Identifier option."  However, section 18.2.3, "Receipt of Renew
Messages", does *not* require that a server discard any Renew messages
in which the contents of the Server Identifier option does not match
the DUID of the receiving server.  I think the specification needs to
be corrected.

The specification may also require clarification in the case of Rebind,
when the server should respond with NoBinding only if it has
authoritative information that there is no binding for the client.
There may be another alternative, which would  be to allow the client
to ignore Reply messages (ins response to a Rebind message )with
NoBinding status, if the client receives another Reply message
from a server that does find the binding.

>BV> (a) is probably a fine action as it really is invalid. T1 <= T2.

Jinmei-san, which choice does your implementation make?  Ignore the
option or the entire message?  And, does it ignore the entire IA_NA
option?  I worry about ignoring just the option, which might lead
to unexpected and hard-to-diagnose behavior.  Ignoring the entire
message would be easier to recognize as incorrect behavior.

>BV> may resend what it sent the first time.

Agreed.

>     use the Information-Request to obtain configuration parameters

Is the situation more complicated in the case when the client sends more
than one IA, and receives NoAddrsAvail status in one IA and addresses
in another IA?  I think the client should make a decision about each IA
individually, (potentially) accepting each IA that has been assigned
addresses, and (potentially) retrying each IA that has status
NoAddrsAvail.  So the text should be clarified, perhaps:

    The client examines the status code in each IA individually.  If
    the status code is NoAddrsAvail, the client has received no usable
    addresses in the IA and may choose to try obtaining addresses for
    the IA from another server.  The client uses addresses and other
    information from any IAs that do not contain a Status Code option.
    If the client receives no addresses in any of the IAs, it may
    choose to use the Information-request message to obtain other
    configuration information.

>BV> the lifetimes will not be updated and eventually the address expires.

Agreed.

>I concur.  Thanks for the detailed explanation.

Agreed.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sun, 26 Jan 2003 15:06:49 +0900

>>>>> On Thu, 23 Jan 2003 16:29:55 -0500, 
>>>>> Ralph Droms <[email-masked]> said:

> the DUID of the receiving server.  I think the specification needs to

Actually, Section 15.6 *seems to* address the case.  It says:

   Servers MUST discard any received Renew message that meets any of the
   following conditions:

    -  the message MUST include a Server Identifier option

    -  the contents of the Server Identifier option MUST match the
       server's identifier
   ...

However, there should be a wording problem.  I guess the sentence
actually intended to be:

   Servers MUST discard any received Renew message that fails to meet
                                                        ^^^^^^^^
   any of the following conditions:

As for wording, the policy of choosing the word is not consistent
throughout Section 15, which may be the source of this kind of error.

There are in fact four variations:

Sections 15.3 and 15.4 say
   XXX MUST discard any YYY message that meets any of the following
   conditions:
     (conditions of invalid cases)
Section 15.16 says:
   XXX MUST discard any YYY message that meets any of the following
   conditions:
     (conditions of valid cases)
Section 15.8, 15.9, 15.10 and 15.12 say:
   XXX MUST discard any YYY message that fails to meet any of the
   following conditions:
     (conditions of valid cases)
Section 15.11 says:
   XXX MUST discard any YYY messages that fails any of the following
   conditions:
     (conditions of valid cases)

Fortunately, all sections except 15.6 look correct (though there may
be some grammatical errors.)

> from a server that does find the binding.

I'd like to see clarification for the Rebind case.  I personally
prefer the first one, because the second one would require additional
parameters for the client of how long the client should wait until it
receives Reply messages.

> message would be easier to recognize as incorrect behavior.

Sorry, I was not specific enough.  Our implementation ignores the
erroneous IA_NA option only, and processes other part of the message
just like the normal case.  (More precisely, we apply the rule to the
IA_PD option, not the IA_NA option, which we have not supported yet.
However, we'd apply the same logic to IA_NA if we supported it.)

I'm not sure what you meant by "ignore the entire IA_NA option", but
our implementation does not use any information of the IA_NA option
including sub-options if T1 > T2 > 0.

We adopted this approach as an analogy to the case of invalid prefixes
described in Section 5.5.3 of RFC 2462.  The RFC specifies the host to
ignore the invalid prefix, not the entire router advertisement.

However, I don't stick to our choice.  Since such invalid parameters
may indicate a bug of the server or even an attack from a malicious
node, it may also make sense to ignore the entire message.

>> > 4. Section 18.1.8 says

(snip)

>     configuration information.

I agree.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sun, 26 Jan 2003 15:32:19 +0900

>>>>> On Thu, 23 Jan 2003 16:22:07 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> stop sending Renew or Rebind in this case?

I may have been asking too many things at one time, but I did not get
an answer to this.  Could anyone clarify this?

					JINMEI, Tatuya

---

From: Ralph Droms <[email-masked]>
Date: Wed, 29 Jan 2003 11:23:07 -0500

(responses in line...)

At 03:06 PM 1/26/2003 +0900, JINMEI Tatuya / 
>    any of the following conditions:

Excellent point; thanks for catching that goof.

While this check is defined in section 15.6, would it be helpful
to add a reference in section 18.1.3 explaining the reason for
that constraint?

>be some grammatical errors.)

Thanks, again, for reviewing all of section 15.

>parameters for the client of how long the client should wait until it

I prefer the first case, as well.  Any opposing opinions?

>However, we'd apply the same logic to IA_NA if we supported it.)

OK.

>including sub-options if T1 > T2 > 0.

Yes, I was asking if you use any of the information from the IA_NA
option.  Not using any of the information from the option sounds like
the right thing to do.

> >     configuration information.

OK....