RE: [dhcwg] Questions about Invalid Option : I'd like clarification

Hideshi:

On the surface, your rewording does seem a bit better ...

>   Clients and servers MUST discard any messages that contain options
>which appearance (or lack of appearance) is a clear violation of the
>DHCPv6 protocol.

But, I feel that it too may be misinterpreted. Is sending a
"information-type" option (i.e., DNS Servers) that an RFC says MUST NOT
be sent in a specific message a "clear violation of the DHCPv6
protocol"?

I'm thinking that we might just want to drop the first paragraph of
Section 15. And, perhaps the second paragraph's requirements be moved
into the corresponding subsections for the messages. This makes it
easier to find all the hard rules for each message.

- Bernie

-----Original Message-----
From: Hideshi.Enokihara@jp.yokogawa.com
[mailto:Hideshi.Enokihara@jp.yokogawa.com] 
Sent: Monday, March 05, 2007 8:32 PM
To: Bernie Volz (volz); dhcwg@ietf.org
Subject: RE: [dhcwg] Questions about Invalid Option : I'd like
clarification 

Thank you so much for your response. 

I was confused about meaning of following Section 15.

RFC3315 section 15,
 ------------
    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. 
 ------------
I was believing that this "SHOULD" rule covered all of RFCs related to
DHCPv6.
Is this text focusing on only section 15.1 to 15.14?

If not, I think that this text should be,
 ------------
    Clients and servers MUST discard any messages that contain options
which appearance (or lack of appearance) is a clear violation of the
DHCPv6 protocol.
 ------------

What do you think?

Best regards,
...Hideshi
> -----Original Message-----
> From: Bernie Volz (volz) [mailto:volz@cisco.com] 
> Sent: Monday, March 05, 2007 11:47 PM
> To: Enokihara, Hideshi (Hideshi.Enokihara@jp.yokogawa.com); 
> dhcwg@ietf.org
> Subject: RE: [dhcwg] Questions about Invalid Option : I'd 
> like clarification 
> 
> The text in RFC 3646 (and likely other options RFCs) does not indicate
> what an entity should do if these options appear in messages that they
> shouldn't. I view this text as guidance for implementers of these
> options not to send them in these messages.
> 
> It is my opinion that an entity should *IGNORE* options that 
> don't make
> any sense in a particular message *EXCEPT* if the appearance 
> (or lack of
> appearance) is a clear violation of the DHCPv6 protocol. These are the
> conditions outlined in RFC 3315, Section 15.1 through 15.14. 
> 
> One major reason for ignoring "unexpected" options is that
> implementations need to be able to handle new options that 
> they may not
> yet implement. And, therefore it is impossible to expect existing
> implementations to act in certain ways for things that they 
> have not yet
> implemented. And, being too strict will cause interoperability issues
> for no real benefit.
> 
> The old Internet policy that implementations should be 
> flexible in what
> they receive but conservative in what they send applies.
> 
> Thus, section 15.1 - 15.14 in RFC 3315 are all that should be used in
> any Conformance check.
> 
> If you add checks to make sure that not allowed options are 
> ignored, you
> MUST support two possible outcomes as some implementations MAY act on
> the text in Section 15 and discard these messages whereas others will
> just ignore the options but otherwise respond.
> 
> - Bernie
> 
> -----Original Message-----
> From: Hideshi.Enokihara@jp.yokogawa.com
> [mailto:Hideshi.Enokihara@jp.yokogawa.com] 
> Sent: Monday, March 05, 2007 3:32 AM
> To: dhcwg@ietf.org
> Subject: [dhcwg] Questions about Invalid Option : I'd like 
> clarification
> 
> 
> Hello all,
> 
> I have some questions about Invalid Options that are not allowed to
> appear in the message.
> I'd like to clarify following things, because I have to finish writing
> the Conformance test specification for IPv6 Ready Logo Program for
> DHCPv6.
> Could you give me your thoughts, please?
> 
> 
> RFC3315 section 15 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 "A. Appearance of Options in Message Types" shows table that 
> indicates with a "*" the options are allowed in each DHCP 
> message type.
> 
> This mean that without a "*" the options are not allowed in 
> each message
> type, right?
> 
> I believe that this table information is too old( not correct ). 
> I think that we need to clarify which option(message with invalid
> option) should be discarded or should be ignored.
> 
> Following things are my thoughts. Are these things correct?
> ------------------
> For Server
> 	Receiving Solict message:
> 		A Server must discard the Solicit message including
> Server Identifier option.
> 		A Server must ignore all options that are not allowed to
> appear in the message except for Server Identifier option. 
> 
> 	Receiving Confirm message:
> 		A Server must discard the Confirm message including
> Server Identifier option.
> 		A Server must ignore all options that are not allowed to
> appear in the message except for Server Identifier option. 
> 		
> 	Receiving Rebind message:
> 		A Server must discard the Confirm message including
> Server Identifier option.
> 		A Server must ignore all options that are not allowed to
> appear in the message except for Server Identifier option. 
> 
> 	Receiving Information-request message:
> 		A Server must discard the Confirm message including
> Server Identifier option and/or IA_NA option.
> 		A Server must ignore all options that are not allowed to
> appear in the message except for Server Identifier option and IA_NA
> option. 
> 
> 	Other messages(Request/Renew/Release/Decline/Relay-forward):
> 		A Server must ignore all options that are not allowed to
> appear in the message.
> 
> 	*I'd like to confirm following things.
> 	RFC3646 section5 says,
> 	--------------------------
> 	   The DNS Recursive Name Server option MUST NOT appear in any
> other
> 	   than the following messages: Solicit, Advertise, Request,
> Renew,
> 	   Rebind, Information-Request, and Reply.
> 
> 	   The Domain Search List option MUST NOT appear in any other
> than the
> 	   following messages: Solicit, Advertise, Request, Renew,
> Rebind,
> 	   Information-Request, and Reply.
> 	--------------------------
> 	This means that servers should discard  the
> Confirm/Release/Decline/Relay-forward message 
> 	that including  DNS Recursive Name Server option and/or Domain
> Search List option, right?
> 	Or just ignore the option?
> 	
> For Client
> 	All messages(Advertise/Reply/Reconfigure).
> 		A Client must ignore all options that are not allowe to
> appear in the message.
> 
> For Relay Agent
> 	All messages
> 		A Relay Agent just relay the message.
> 		
> ---------------------
> 
> What do you think?
> 
> Best regards,
> ...Hideshi Enokihara
> 	
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg