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

Also, I should add that there are some options, such as relay agent option, that could be long (greater than 255 bytes) and I don’t think were explicitly called out as requiring this feature.

The text in 3396 was written to force implementations to support this for those new options that required it (since we didn’t want to break existing implementations). But it was not prohibited for other options to use it (though the client or server had to be reasonably sure the partner supported it).

If we changed this, then there would need to be a whole section on what options where allowed to use it (even though not required).

- Bernie (from iPad)

> On Oct 22, 2024, at 3:58 PM, Bernie Volz <[email protected]> wrote:
> 
> 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]