Skip to content

Support microsoft-conform user class option in DHCPv6 #559

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

damyan
Copy link

@damyan damyan commented Mar 26, 2025

This pull request addresses an issue in the DHCPv6 User Class option (OptUserClass) where the FromBytes method failed to parse data in the Microsoft-compatible format. The existing implementation adhered strictly to the RFC 8415 specification, which requires each user class to be preceded by a 16-bit length field. However, Microsoft DHCPv6 implementations deviate from this by providing a single user class as raw bytes without a length prefix. This mismatch caused a "buffer too short" error when parsing Microsoft-formatted data, as observed in the otherwise failing test TestOptUserClassBroken.

Changes Made

  • Updated FromBytes Method:
    • The method now attempts to parse the data as multiple user classes with length prefixes (per RFC standards).
    • If a length field exceeds the remaining buffer size, parsing halts at that point.
    • If no valid user classes are parsed (e.g., due to missing or invalid length prefixes), the entire data buffer is treated as a single user class, aligning with Microsoft’s format.
    • This dual-parsing approach ensures compatibility with both RFC-compliant and Microsoft-specific inputs without raising errors.

Why This Fix Is Necessary

  • Interoperability: Supporting both RFC and Microsoft formats is essential for seamless interaction with a wide range of DHCPv6 clients, including those in Microsoft environments.
  • Test Reliability: The previous implementation caused TestOptUserClassBroken to fail unnecessarily. This change eliminates the error while maintaining functionality for standard inputs.

@damyan damyan force-pushed the fix/fix-non-rfc-conform-optusrclass-v6 branch from 9738b62 to a882567 Compare March 26, 2025 18:16
@damyan damyan force-pushed the fix/fix-non-rfc-conform-optusrclass-v6 branch from a882567 to 7980a6f Compare March 27, 2025 07:37
@pmazzini
Copy link
Collaborator

Related for DHCPv4: #114

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants