Subject: [dhcwg] Issues raised in 65th IETF from TAHI Project

From: <[email-masked]>
Date: Thu, 27 Apr 2006 14:38:21 +0900

Hi all,

In last IETF, TAHI Project raised  issues in RFCs.
So I'd like to hear your opinions and I'd like to make the consensus.

I raised following 3 issues.

1.How to treat invalid option that does not influence interoperability?

RFC3315 15. Message Validation says,
---------------------------------------
   Clients and servers SHOULD discard any messages that contain options
   that are not allowed to appear in the received message.  For example,
   an IA option is not allowed to appear in an Information-request
   message. 
----------------------------------------
And also says,
----------------------------------------
A. Appearance of Options in Message Types

   The following table indicates with a "*" the options are allowed in
   each DHCP message type:

           Client Server IA_NA  Option Pref  Time Relay Auth. Server
             ID     ID   IA_TA  Request            Msg.       Unica.
   Solicit   *             *      *           *           *
   Advert.   *      *      *            *                 *
   Request   *      *      *      *           *           *
   Confirm   *             *      *           *           *
   Renew     *      *      *      *           *           *
   Rebind    *             *      *           *           *
   Decline   *      *      *      *           *           *
   Release   *      *      *      *           *           *
   Reply     *      *      *            *                 *     *
   Reconf.   *      *             *                       *
   Inform.   * (see note)         *           *           *
   R-forw.                                          *     *
   R-repl.                                          *     *

   NOTE:

      Only included in Information-Request messages that are sent
      in response to a Reconfigure (see section 19.4.3).

            Status  Rap. User  Vendor Vendor Inter. Recon. Recon.
             Code  Comm. Class Class  Spec.    ID    Msg.  Accept
   Solicit           *     *     *      *                    *
   Advert.    *            *     *      *                    *
   Request                 *     *      *                    *
   Confirm                 *     *      *
   Renew                   *     *      *                    *
   Rebind                  *     *      *                    *
   Decline                 *     *      *
   Release                 *     *      *
   Reply      *      *     *     *      *                    *
   Reconf.                                            *
   Inform.                 *     *      *                    *
   R-forw.                 *     *      *      *
   R-repl.                 *     *      *      *
----------------------------------------

For example, Preference Option, this option is not allowed in Solicit,
Request and Confirm etc... message.
But, Most implementations ignore only such option rather than discarding
the entire message.

Now, our test tool follows the RFC.
Which behavior is correct? Ddiscard message or ignore option?

2.Where is the correct opsition of NotOnLink Status Code option for
Reply to a Request message?

RFC3315 18.2.1. Receipt of Request Messages  says,
---------------------------------------
   If the server finds that the prefix on one or more IP addresses in
   any IA in the message from the client is not appropriate for the link
   to which the client is connected, the server MUST return the IA to
   the client with a Status Code option with the value NotOnLink.
---------------------------------------

I think that this description "the server MUST return the IA to the
client with a ...." is unclear.
This "with" means that "in main part of message" or "in IA option" or in
"IA_address option" ?
Some implementations include this Status code option in main part of
massage, some others in IA_option or IA_Address option. 

Mr Bernie Volz says,
For Reply to a Request, it should be in IA option.

Can it be consensus?

And I also worry that some other Status Code option's position is
unclear.

3. Is the coexistence of Success and NoBinding Status Code option in
Reply to a Renew acceptable?

Regarding this issue, RFC has no description.

But some implementations include Success Status Code option in main part
of messge and include NoBinding Status Code option in IA opiton.

Is this implementation's behavior  acceptable or not?

If this behavior is acceptable, what is the meaning of Success Status
Code?

What do you think?

Best Regards,
*****************************
Hideshi Enokihara
IPv6 Business
Network & Software Development Dept.
Yokogawa Electric Corporation

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

---

From: Joe Quanaim <[email-masked]>
Date: Fri, 28 Apr 2006 15:27:52 -0400

Hi Hideshi...

> Which behavior is correct? Ddiscard message or ignore option?

Since the statement is a SHOULD, I think both are correct.  I would caution 
that if the an implementation is too aggressive in discarding an otherwise 
valid message, it may make it more difficult in the future to deploy new 
options.

> RFC3315 18.2.1. Receipt of Request Messages  says,

I agree with this assessment.  I think the rfc does not make it clear where 
an arbitrary status code option should be.  Is it valid on the ia_address 
options, ia_na options, or the message options?  A client probably needs 
to check all three, especially since new status codes can appear in the 
future (prefix delegation added a status code).

In a hypothetical example, what if a client made a request with two ia_na 
options, but a server could only fulfill one of them.  Where would the 
status code(s) be placed?

> If this behavior is acceptable, what is the meaning of Success Status

I think this question and your second question require some clarification 
to the status code option.

Thanks,
Joe Quanaim.