[dhcwg] Re: New Version Notification for draft-tojens-dhcp-o ption-concat-considerations-00.txt

The problem with this approach is that the original RFC didn't make it
illegal to for example send two lease time options. And so it's actually
not out of spec for this to happen. How to handle it is not covered by the
spec, but we can't actually assert that the server sending this message is
violating the specification.

And so it makes sense to document this, and not just go "fix" the "out of
spec" server, which isn't out of spec, even though I agree that what it's
doing doesn't make sense.

Also speaking as someone who works for an O.S. vendor, we have to write
code that works in the real world. It's not enough to say "this is
operationally incorrect" if it's happening to millions of users. So we are
pretty much forced to write code to handle these situations, and it also
makes sense from that perspective to document what we did.

None of which is to disagree with your basic point that the server in
question is broken and should be fixed!

On Tue, Oct 22, 2024 at 4:56 AM Bernie Volz <[email protected]> wrote:

> I think your energy should be focused on getting the broken server fixed.
> You are asking a lot of change to other software because of one (?) broken
> implementation. That just seems wrong way to correct things.
>
> - Bernie (from iPad)
>
> On Oct 22, 2024, at 4:29 PM, Tommy Jensen <[email protected]> wrote:
>
>  Hey Bernie,
>
> Thank you for reading our proposal. You are correct that the server in the
> duplicate Option 51 case is in the wrong. Giving guidance for clients to
> survive broken servers is the primary purpose of this draft.
>
> > Do you have a valid real world example where this is a problem?
>
> I do not think that one protocol peer is misbehaving makes the scenario
> invalid. The problem is in real life, when an ISP or router does something
> like this, it seems easy to call it a protocol failure until doing so
> prevents IPv4 at scale (insert joke about being a good thing for IPv6).
> This situation is unfortunately not a hypothetical, even if uncommon.
>
> In this case, Windows will pick one of the instances, breaking the RFC in
> favor of staying connected. That is essentially what this draft says: be
> defensive against unexpected duplicates when they are supposed to be fixed
> length. This is an unwritten rule in industry today, so this writes it down.
>
> The main point of the draft is to give implementors something more than
> 3396 to tell them "no, you actually don't need to try merging split
> non-concatenation-requiring options (3396 requires you to)" and "yes, you
> are OK to try avoiding merges in these cases because it probably wasn't
> intended". We just don't want to leave "nobody implements it as written,
> you just have to know when to do what" unspoken.
>
> Does this help?
>
> Thanks,
> Tommy
>
> Oct 21, 2024 19:59:14 Bernie Volz <[email protected]>:
>
> Hi:
>
> For this draft, you used the example of presumably two address options
> (51) in the same packet. Why would this occur? Seems to me that the server
> is broken already if it is doing this and the outcome is unpredictable
> anyway:
> 1) some clients use first instance
> 2) some clients use second (which could be same as first)
> 3) some clients concat and end up with invalid option (or use first 4
> octets).
>
> Do you have a valid real world example where this is a problem?  V4
> options were designed to carry single value, except for newer options where
> lists are allowed and handled correctly (length, data, length, data, …).
>
> If you do, it could add more weight to this draft. Otherwise, not yet
> convinced the problem is real?
>
> - Bernie (from iPad)
>
> On Oct 22, 2024, at 12:24 PM, [email protected] wrote:
>
> Good day dhc!
>
> Milan and I submitted a draft today that revisits RFC 3396, which talks
> about how DHCP options are concatenated, in the context of current
> deployments. Unfortunately, we have seen issues with interpreting 3396
> strictly that major implementors have had to work around in non-standard
> ways. RFC 3396 continues to be referenced as new DHCP options are defined
> to make the new options concatenation-requiring. Therefore, we believe some
> deployment considerations are needed to clarify when concatenation is
> appropriate and if/how a peer can recover from non-standard behavior.
>
> Feedback is welcome! I know we are not meeting at IETF 121, but if anyone
> wants to also discuss this in the hallway in addition to the list, I will
> be there.
>
> Thanks,
> Tommy
>
> -----Original Message-----
> From: [email protected] <[email protected]>
> Sent: Monday, October 21, 2024 4:06 PM
> To: Milan Justel <[email protected]>; Tommy Jensen
> <[email protected]>
> Subject: New Version Notification for draft-tojens-dhcp-option-concat-
> considerations-00.txt
>
> A new version of Internet-Draft
> draft-tojens-dhcp-option-concat-considerations-00.txt has been
> successfully
> submitted by Tommy Jensen and posted to the IETF repository.
>
> Name:     draft-tojens-dhcp-option-concat-considerations
> Revision: 00
> Title:    DHCP Option Concatenation Considerations
> Date:     2024-10-21
> Group:    Individual Submission
> Pages:    7
> URL:      https://www.ietf.org/archive/id/draft-tojens-dhcp-option-concat-
> considerations-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-tojens-dhcp-option-concat-
> considerations/
> HTML:     https://www.ietf.org/archive/id/draft-tojens-dhcp-option-concat-
> considerations-00.html
> HTMLized: https://datatracker.ietf.org/doc/html/draft-tojens-dhcp-option-
> concat-considerations
>
>
> Abstract:
>
>   DHCP has a length limit of 255 on individual options because of its
>   one-byte length field for options.  To accommodate longer options,
>   splitting option data across multiple instances of the same Option
>   Type is defined by [RFC3396].  However, this mechanism is required to
>   be supported for all options.  This leads to real-world
>   implementations in the years since the RFC was published to deviate
>   from these requirements to avoid breaking basic functionality.  This
>   document updates RFC 3396 to be more flexible regarding when DHCP
>   agents are required to concatenate options to reflect deployement
>   experiences.
>
>
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> dhcwg mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
> _______________________________________________
> dhcwg mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

_______________________________________________
dhcwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]