Subject: [Dhcpv6bis] [dhcpv6bis] #144 (XML 3315): Clarify unknown option handling

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Tue, 17 Mar 2015 17:19:02 -0000

#144: Clarify unknown option handling

 There appear to be cases where servers are not "ignoring" unknown options
 (or at least enterprise-ids) - perhaps we should clarify this in RFC
 3315bis.

 -----Original Message-----
 From: Dan Seibel [mailto:[email-masked]]
 Sent: Tuesday, March 17, 2015 9:34 AM
 To: Bernie Volz (volz)
 Subject: Re: [Dhcpv6bis] Handling unrecognized Vendor-specific Information
 Options

 I am not sure the best way to give feedback on this since this is my first
 time joining a rfc mailing listŠ

 For what it is worth coming from a service provider, I really like the
 idea to not just drop a dhcp message if it has an unknown option.  Working
 with a variety of vendors I have usually seen issues arise when the router
 vendor is extremely strict with an access protocol rfc implementation.  I
 know both Juniper and Alcatel-Lucent have relaxed some of these
 interpretations at our request so that CPE devices out in the wild that
 aren¹t quite perfect still function.

 So the ability to ignore these things would be welcome from me.

 Thanks

 Dan Seibel

 On 2015-03-05, 8:11 PM, "Bernie Volz (volz)" <[email-masked]> wrote:

 >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]
 >
 >_______________________________________________
 >Dhcpv6bis mailing list
 >[email-masked]
 >https://www.ietf.org/mailman/listinfo/dhcpv6bis

-- 
----------------------------+----------------------------------
 Reporter:  [email-masked]  |      Owner:
     Type:  task            |     Status:  new
 Priority:  P1 blocker      |  Milestone:  C awaiting consensus
Component:  XML 3315        |   Keywords:
 Due Date:  30/04/2015      |
----------------------------+----------------------------------

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/144>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>