Subject: Re: [Dhcpv6bis] Handling unrecognized Vendor-specific Information Options

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 6 Mar 2015 03:11:47 +0000

I've CC'd the dhcpv6bis list to see if anyone feels this is necessary. While it may not be explicitly stated, it is assumed -- there's certainly nothing that would lead one to believe it shouldn't be silently ignored.

If anything, we might add something into RFC 3315bis section 16 that reads something like:

	Clients and servers MUST NOT discard messages that contain unknown options
	(or instances of vendor options with unknown enterprise-numbers). These
	should be ignored as if they weren't present.

As there was RFC 7283 (unknown messages) which was incorporated, perhaps this is acceptable. Though turns out there are some typos with incorporating that text:

   A client or server MUST silently discary and yreceived DHCPv6
   messages with an unknown message type.

I think this should be:

   A client or server MUST silently discard any received DHCPv6
   messages with an unknown message type.

I fixed that in the GITHUB version.

The next text, if added, might be added just before this RFC 7283 text - as the previous paragraph discusses options. Though the section is a bit weirdly ordered:
1st paragraph is about options that should not appear.
2nd is about unicast destination.
3rd is about auth.
4th is about options that should not appear (but just from server perspective). Not sure why this isn't closer to 1st paragraph?
5th is the 7283 text.

Perhaps we should rewrite as:

16.  Message Validation

   Clients and servers might get messages that contain options not
   allowed to appear in the received message.  For example, an IA option
   is not allowed to appear in an Information-request message.  Clients
   and servers MAY choose either to extract information from such a
   message if the information is of use to the recipient, or to ignore
   such message completely and just drop it.

   If a server receives a message that contains options it should not
   contain (such as an Information-request message with an IA option),
   is missing options that it should contain, or is otherwise not valid,
   it MAY send a Reply (or Advertise as appropriate) with a Server
   Identifier option, a Client Identifier option if one was included in
   the message and a Status Code option with status UnSpecFail.

   Clients and servers MUST NOT discard messages that contain
   unknown options (or instances of vendor options with unknown
   enterprise-numbers). These should be ignored as if they weren't
   present.

   A server MUST discard any Solicit, Confirm, Rebind or Information-
   request messages it receives with a unicast destination address.

   Message validation based on DHCP authentication is discussed in
   Section 22.4.2.

   A client or server MUST silently discard any received DHCPv6
   messages with an unknown message type.

- Bernie

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Thursday, March 05, 2015 6:39 PM
To: Bernie Volz (volz); Tomek Mrugalski ([email-masked])
Subject: RE: Handling unrecognized Vendor-specific Information Options

Thanks Bernie,

I want for the server to silently ignore any vendor-specific information options that it does not recognize. If that is common knowledge, then I am fine with leaving things as they are. If not, then maybe something should be said in RFC3315(bis)?

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: Bernie Volz (volz) [mailto:[email-masked]]
> Sent: Thursday, March 05, 2015 3:28 PM
> To: Templin, Fred L; Tomek Mrugalski ([email-masked])
> Subject: RE: Handling unrecognized Vendor-specific Information Options
> 
> I would expect a server to ignore what it doesn't "know" how to handle. That's what our server does.
> 
> I would think it a bug if a server dropped a packet because of an unknown option or an "unknown" vendor enterprise-id.
> 
> RFC 3315 Section 15 has the rules about what "valid" packets are. Any 
> other things present in packets should generally be silently ignored if not recognized or appropriate.
> 
> - Bernie
> 
> -----Original Message-----
> From: Templin, Fred L [mailto:[email-masked]]
> Sent: Thursday, March 05, 2015 6:24 PM
> To: Bernie Volz (volz); Tomek Mrugalski ([email-masked])
> Subject: Handling unrecognized Vendor-specific Information Options
> 
> Hi Bernie and Tomek,
> 
> What does a DHCPv6 server or client do when it receives a message that 
> includes an unrecognized Vendor-specific Information Option? Ignore the option silently? Ignore the option and log? Drop the DHCPv6 message altogether?
> 
> I didn't see this anywhere in the RFC3315 spec, but please let me know if I missed it.
> 
> Does this sound like something that should appear in RFC3315(bis)?
> 
> Thanks - Fred
> [email-masked]