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

Rest assured broken servers are not being left alone :)

> You are asking a lot of change to other software because of one (?) broken implementation.

Actually, our intention is to do the opposite: bring the RFC to where existing implementations already are. If software needed to change to honor our proposed text for options it already supports, it would be broken in some cases already and would know about it.

What I'm saying is we have over the years already all deviated from RFC and this is an attempt to describe what we believe the industry is already doing so other implementors can take advantage of that knowledge before implementing 3396 as written and wonder why they are running into problems (and be transparent with the world at large how option concatenation is really working in practice). The normatives make it sound more overhaul-y than it really is.

Thanks,
Tommy

Oct 21, 2024 20:56:21 Bernie Volz <[email protected]>:

> 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]