Add complete support of DHCP relay interface ID option #15329
Merged
Conversation
This file contains 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
RFC3315 specifies the following: "The relay agent MAY send the Interface-id option to identify the interface on which the client message was received. If a relay agent receives a Relay-reply message with an Interface-id option, the relay agent relays the message to the client through the interface identified by the option." The current implementation of the DHCP relay reply handling, the interface ID field from the server response is ignored. Managing the interface ID is very important especially as DHCP requests/replies use link-local addresses. The consequence of this is that the interface must always be specified because the routing layer cannot guess the correct interface. Moreover, Mbed provides a mechanism to enable/disable the interface ID option on a DHCP relay instance, so it is important to fully support it. The reason why this issue has not been discoverd until now is that the DHCP relay is mainly used on systems that use only one interface (such as Wi-SUN routers). By default, when no interface ID is specified for the socket, the latter will choose 6loWPAN interface by default. This means that if two interfaces are used on the same device, the 6loWPAN interface is always selected. The commit adds code to retrieve the interface-id value contained within the DHCP relay reply message and write it to a control message header that is added to the socket message. This tells the socket which interface to choose. If the interface-id option is not enabled on the relay, this procedure is simply ignored.
ciarmcom
added
the
release-type: patch
|
@YannCharbon, thank you for your changes. |
0xc0170
approved these changes
Sep 26, 2022
|
CI started |
Jenkins CI Test : ✔️ SUCCESSBuild Number: 1 | 🔒 Jenkins CI Job | 🌐 Logs & ArtifactsCLICK for Detailed Summary
|
mbedmain
removed
release-type: patch
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.
Summary of changes
RFC3315 specifies the following: "The relay agent MAY send the Interface-id
option to identify the interface on which the client message was received.
If a relay agent receives a Relay-reply message with an Interface-id
option, the relay agent relays the message to the client through the
interface identified by the option."
The current implementation of the DHCP relay reply handling, the interface
ID field from the server response is ignored. Managing the interface ID
is very important especially as DHCP requests/replies use link-local
addresses. The consequence of this is that the interface must always be
specified because the routing layer cannot guess the correct interface.
Moreover, Mbed provides a mechanism to enable/disable the interface ID
option on a DHCP relay instance, so it is important to fully support it.
The reason why this issue has not been discovered until now is that the DHCP
relay is mainly used on systems that use only one interface (such as Wi-SUN
routers). By default, when no interface ID is specified for the socket, the
latter will choose 6loWPAN interface by default. This means that if two
interfaces are used on the same device, the 6loWPAN interface is always
selected.
The PR adds code to retrieve the interface-id value contained within
the DHCP relay reply message and write it to a control message header
that is added to the socket message. This tells the socket which
interface to choose. If the interface-id option is not enabled on the
relay, this procedure is simply ignored.
Impact of changes
Migration actions required
Documentation
None
Pull request type
Test results
Reviewers