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