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

From: <[email-masked]>
Date: Mon, 5 Mar 2007 17:32:25 +0900

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 5 Mar 2007 09:46:43 -0500

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: [email-masked]
[mailto:[email-masked]] 
Sent: Monday, March 05, 2007 3:32 AM
To: [email-masked]
Subject: [dhcwg] Questions about Invalid Option : I'd like clarification

Hello all,

RFC3315 section 15 says,
------------

		

	
For Client

For Relay Agent
	All messages
		
---------------------

What do you think?

Best regards,
...Hideshi Enokihara

---

From: <[email-masked]>
Date: Tue, 6 Mar 2007 10:32:06 +0900

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
> From: Bernie Volz (volz) [mailto:[email-masked]] 
> Sent: Monday, March 05, 2007 11:47 PM
> To: Enokihara, Hideshi ([email-masked]); 
> [email-masked]
> Subject: RE: [dhcwg] Questions about Invalid Option : I'd 
> like clarification 
>

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 5 Mar 2007 20:43:44 -0500

Hideshi:

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

>which appearance (or lack of appearance) is a clear violation of the
 
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: [email-masked]
[mailto:[email-masked]] 
Sent: Monday, March 05, 2007 8:32 PM
To: Bernie Volz (volz); [email-masked]
Subject: RE: [dhcwg] Questions about Invalid Option : I'd like
clarification 

RFC3315 section 15,
 ------------

What do you think?

Best regards,
...Hideshi
> For example,

---

From: <[email-masked]>
Date: Tue, 6 Mar 2007 10:54:41 +0900

Hello Berine,
 
> 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.

I agree with your opinion.

Thanks,
> Sent: Tuesday, March 06, 2007 10:44 AM
> "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
> 
>     Clients and servers SHOULD discard any messages that 
> contain options that are not allowed to appear in the 
> received message.  
> I was believing that this "SHOULD" rule covered all of RFCs 
> related to DHCPv6.
>     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
> > 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
> > 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.
> > 
> > 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
> > 
> > This mean that without a "*" the options are not allowed in each 
> > message type, right?
> > 
> > 		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.
> > 
> > 		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.
> > 		
> > 		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.
> > 
> > 		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.
> > 
> > 		A Server must ignore all options that are not 
> allowed to appear in 
> > the message.
> > 
> > 	   The DNS Recursive Name Server option MUST NOT appear 
> in any other
> > 	   than the following messages: Solicit, Advertise, 
> Request, Renew,
> > 	   The Domain Search List option MUST NOT appear in any 
> other than 
> > the
> > 	   following messages: Solicit, Advertise, Request, 
> Renew, Rebind,
> > 	that including  DNS Recursive Name Server option and/or 
> Domain Search 
> > List option, right?
> > 		A Client must ignore all options that are not 
> allowe to appear in 
> > the message.
> > 
> > For Relay Agent
> > 	All messages

---

From: Damien Neil <[email-masked]>
Date: Mon, 5 Mar 2007 23:54:03 -0800

> easier to find all the hard rules for each message.

I agree strongly.  As you pointed out earlier, there is little reason  
for recommending that implementations perform additional work simply  
to cause potential interoperability issues.  I suspect that few  
implementations would (or should) choose to implement the checks  
described in that paragraph.

               - Damien

---

From: Ralph Droms <[email-masked]>
Date: Thu, 08 Mar 2007 16:30:58 -0500

Is this clarification important enough to move forward as an errata at this
point?

- Ralph

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Thu, 8 Mar 2007 23:56:16 -0500

Sure. I think it would also help the Tahi folks with the DHCPv6 Logo
Ready program to remove those tests that send unexpected, but otherwise
insignificant, options to test this.

- Bernie 

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Thursday, March 08, 2007 4:31 PM
To: Damien Neil; Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: [dhcwg] Questions about Invalid Option : I'd like
clarification 

Is this clarification important enough to move forward as an errata at
this
point?

- Ralph