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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Fri, 24 Jan 2003 09:01:24 -0600

Comments in line (I also deleted the items on which I have no comments)

My comments are prefixed by BV2> just to be clear.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Thursday, January 23, 2003 4:30 PM
To: [email-masked]
Subject: Re: [dhcwg] questions about dhcpv6-28

Comments in line...

- Ralph

At 04:22 PM 1/23/2003 +0900, JINMEI Tatuya / 
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
>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 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.
>
>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).

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.

BV2> Yes, agreed we should fix 18.2.3. (Perhaps we should even consider
BV2> whether additional rules should be added in section 15.10 on Replies
BV2> to specific messages? Such as Server Identifier must match that sent
BV2> in any "request".)

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.

BV2> What about just requiring all servers to respond but having the
BV2> client only take the NoBinding from the Server Identifier it last
BV2> used with that binding as being authoritative. I'm not sure how a
BV2> server could know whether it has (or had) authoritative information.
BV2> Placing this responsibility on the client is reasonable and means
BV2> that a complete loss of information at a server does not require
BV2> any special server processing to handle this.

> > 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.
>
>Okay.

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.

BV2> I agree with Ralph that dropping the entire message might make better
BV2> sense.

> > 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.
>
>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.

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.

BV2> Agreed. It is IA specific.

>                                         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

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

---

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

>>>>> On Fri, 24 Jan 2003 09:01:24 -0600, 

Hmm, I personally don't see the need for additional text in 15.10, but
it might be helpful if a client implementation identifies an
outstanding request by the pair of "server ID + transaction ID".

Ralph pointed out to me the possibility of some "magic" between a
primary server and a backup server, which allows those servers to be
synchronized in real time.  I'm not sure how this is realistic,
either, but I'd personally prefer to keep the possibility.

					JINMEI, Tatuya