[dhcp4relay] Implement RFC 6607 VSS-Control#122
Draft
Xichen96 wants to merge 2 commits into
Draft
Conversation
Emit zero-length VSS-Control whenever relay-assigned VSS is present. Validate server replies and drop retained VSS-Control or missing/mismatched VSS data. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 2b881aa9-3a3a-4aaf-b2ca-b941705b2438 Signed-off-by: Xichen96 <lukelin0907@gmail.com>
Collaborator
|
/azp run |
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
23 tasks
Contributor
There was a problem hiding this comment.
Pull request overview
Implements RFC 6607 VSS-Control handling for DHCPv4 relay VSS (Option 82 suboptions), so the relay can distinguish VSS-aware servers from servers that merely echo Option 82 and can safely reject unprocessed replies.
Changes:
- Appends zero-length VSS-Control Suboption 152 whenever VSS Suboption 151 is included in relay agent options.
- Adds server-reply validation for VSS-required configurations (require matching Type-0 Suboption 151 and absence of Suboption 152; otherwise drop and log).
- Fixes TLV encoding/decoding robustness and adds focused unit tests around zero-length TLVs and VSS validation.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| dhcp4relay/src/dhcp4relay.cpp | Adds VSS-Control encoding, reply validation logic, and fixes TLV boundary handling. |
| dhcp4relay/src/dhcp4relay.h | Introduces constant for VSS-Control suboption (152). |
| dhcp4relay/test/mock_relay.cpp | Extends unit tests for zero-length TLVs, VSS-Control presence, and reply validation paths. |
Collaborator
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
Validate the complete Option 82 suboption buffer before checking VSS acknowledgement so a truncated VSS-Control TLV cannot be treated as absent. Keep the unit-only helper declaration in the production header to avoid a duplicated test prototype. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 2b881aa9-3a3a-4aaf-b2ca-b941705b2438 Signed-off-by: Xichen96 <lukelin0907@gmail.com>
Xichen96
force-pushed
the
dev/xichenlin/fix-vss-control
branch
from
July 18, 2026 15:41
13ba166 to
9be6f60
Compare
Collaborator
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
This was referenced Jul 19, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of PR
Summary:
Implement RFC 6607 VSS-Control handling for relay-assigned DHCPv4 VSS.
The relay currently emits VSS Suboption 151 without the mandatory
VSS-Control Suboption 152. It therefore cannot distinguish a VSS-aware server
from a server such as Kea that merely echoes Option 82 without processing VSS.
Type of change
Approach
What is the motivation for this PR?
RFC 6607 requires a relay to include zero-length Suboption 152 whenever it
includes Suboption 151. A server that processes VSS removes 152 from its reply;
a server that does not process VSS returns both. Accepting an unprocessed reply
can deliver an address selected from the wrong VPN.
How did you do it?
Suboption 151.
matching Type-0 client VRF in Suboption 151 and do not contain Suboption 152.
VSS acknowledgement, retained 152, and missing/mismatched 151.
How did you verify/test it?
Focused unit coverage is included in
dhcp4relay/test/mock_relay.cpp.Compilation and unit execution are delegated to PR CI; no local SONiC build
was used.
Any platform specific information?
None.
Documentation
The behavior follows RFC 6607 Sections 3.3 and 5.