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

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]