Skip to content

doc: documentation of SCMP source port#4901

Open
tzaeschke wants to merge 3 commits into
masterfrom
tzaeschke-doc-scmp-info-port
Open

doc: documentation of SCMP source port#4901
tzaeschke wants to merge 3 commits into
masterfrom
tzaeschke-doc-scmp-info-port

Conversation

@tzaeschke
Copy link
Copy Markdown
Contributor

Update documentation to explain that the former ID field of SCMP info messages now contains the source port.

@tzaeschke tzaeschke self-assigned this Mar 9, 2026
@tzaeschke tzaeschke changed the title SCMP source port documentation. doc: SCMP source port documentation. Mar 9, 2026
@tzaeschke tzaeschke changed the title doc: SCMP source port documentation. doc: documentation of SCMP source port Mar 9, 2026
Comment thread doc/protocols/scmp.rst
+--------------+---------------------------------------------------------------+
| Code | 0 |
+--------------+---------------------------------------------------------------+
| Identifier | A 16-bit identifier to aid matching replies with requests |
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to know other people's opinion on renaming a protocol field, since it is a normative change that requires bigger consensus. This field mirrors the ICMP Echo Identfier field. Some implementations use PID to populate this field https://man7.org/linux/man-pages/man8/ping.8.html#ID_COLLISIONS, but the field still keeps the generic name. I understand it is useful to reflect the current implementation convention, but still I do not think we need to restrict future implementations making the field keep the source port a protocol requirement. Additionally, we have several implementations already using the "Identifier" field. My suggestion is having something like: "Implementations SHOULD set the Identifier to the source port of the sending application to enable proper demultiplexing of replies by the router." and keeping the current name

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, that's exactly the feedback I wanted to have. And yes, of course this needs proper approval, I just wanted to start small. However, in the ends this is just about aligning the doc with the implementation.

I now moved the text to a single paragraph in the SCMP Information section.

@oncilla @lukedirtwalker @romshark @FR4NK-W Thoughts? Should this go to one of the TCs?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is good to document this behavior, since this is as far as I understand implemented. This is a trick that routers use to map SCMP to the UDP/IP underlay, so perhaps this could also be mentioned in #4895 besides here.

Regarding the IETF draft, it says:

A 16-bit identifier to aid matching replies with requests

I think this wording does not conflict with the behavior that you are trying to document. So I think we can leave the draft unchanged.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P.S. @JordiSubira what is the reason of this behavior? Couldn't end-host implementations just use 40031 as a src port too?
Then traffic could just go to that port, where they are listening for SCMP anyways. Why use dynamic source ports?

Copy link
Copy Markdown
Contributor

@JordiSubira JordiSubira Mar 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess you mean 30041. Basically not, because that port is in most of the cases (although not necessarily) occupied by the scmp daemon (as it is implemented the shim dispatcher, right now). Client applications open underlay UDP/IPs when sending SCMP informational messages. One application can open multiple underlays, and more in general, many applications may open many underlays. This is the mechanism for demux the replies to the correct application that originated the SCMP request. The discussion of why exactly this solution and ruling out other ones (e.g., ab/re-using FlowID in the IP underlay) may be found here: #4280.

Copy link
Copy Markdown
Contributor

@nicorusti nicorusti Mar 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your clarification, sounds good to me that we document it.

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.

3 participants