doc: document UDP underlay and ports by nicorusti · Pull Request #4895 · scionproto/scion

nicorusti · 2026-03-03T12:46:44Z

This PR contains a description of the IP/UDP underlay. This page will be added as an informative reference in the SCION dataplane RFC.

During the IETF review process, it emerged that we need to document the behavior of default port UDP 30041, which is required to be unique so that endhosts (endpoints in the drafts) can receive SCMP informational messages.
The UDP/IP underlay behavior in the nearly final version draft-dekater-scion-dataplane-11 is not well specified.

We discussed wether to include this in the draft, and we decided that it is best to leave it out to an external reference. Mian reasons were:

this is currently an evolving topic (dispatcherless, STUN, etc...) and we don't want behaviors set in stone in the RFC
this document would better fit an Internet Draft of its own (e.g. SCION on top of IP behavior)

For the record, discussions happened in:

Clarify SCMP processing rules scionassociation/scion-cp_I-D#213
slack (SCMP, underlay)
Write IANA Considerations Section scionassociation/scion-dp_I-D#4 (where we'll attempt to register port 30041 with IANA)

JordiSubira · 2026-03-03T14:29:59Z

+-----------------------------------------+------------+-----------------+----------------------+-----------------------------------------------------------------------------------------------------------------------------------+
+| Router Internal Interfaces              | any        | UDP 30100-30199 | Router-wide          | :doc:`topology.json <../manuals/common>`                                                                                          |
+-----------------------------------------+------------+-----------------+----------------------+-----------------------------------------------------------------------------------------------------------------------------------+
+| Router External Interfaces              | any        | UDP 31000-39999 | Link                 | :doc:`topology.json <../manuals/common>`                                                                                          |


What are we describing ports that are not relevant for the intra-AS UDP/IP underlay here?

I think the idea is that inter-AS traffic may also some an underlay?

But I agree with Jordi, this document should probably focus on intra AS underlays.

More specifically, on communication between BR<->endhost and BR<->BR

My idea was that this page generally describes how SCION is stacked over IP/UDP. This should IMHO include inter-AS links. I reworded to clarify that inter-AS links are independent from intra-AS links.

tzaeschke

LGTM % SCMP handling

tzaeschke · 2026-03-03T14:33:42Z

+Control plane components require service ports for topology synchronization, beaconing, and PKI tasks:
+
+* **Control Plane Intra-AS**: Control services typically communicate over TCP/IP and UDP/SCION on ports **40000-40099**.
+* **Control Plane Inter-AS**: Control plane traffic across AS boundaries relies on QUIC/SCION, with the exact ports dynamically chosen by the service.


Should we mention service addresses here?

Absolutely, this is a missing point and we could take some text from the draft or from the design docs to this page

Co-authored-by: Tilmann <tilmann_dev@gmx.de>

nicorusti · 2026-03-04T22:26:01Z

@tzaeschke @JordiSubira I made some changes based on your feedback. How does it look now?
Feel free to edit directly.
It would be great if we can merge it by March 16 so that I can have the link ready for the reference in the draft. We can always fine tune it later.

tzaeschke

LGTM

JordiSubira · 2026-03-06T11:10:19Z

+* **SCMP**: For SCMP informational messages, the router forwards the packet to the default end-host port: **30041**. For SCMP error messages, the router tries to extract the end-host port and sends the packet to the endhost, subject to dispatched port settings and the default underlay port. If the port cannot be extracted, the packet is dropped.
+
+.. note::
+   Historically, SCION end hosts relied on a user-space "dispatcher" process listening on the default port UDP 30041 to route incoming packets to the correct application socket. For more details, see the :doc:`Dispatcher Manual <../manuals/dispatcher>`.


This is incomplete if it intends to refer the current behaviour. This is true for requests, for replies the ID field is inspected to dispatched the port directly to the underlay client port (if within the dispatched range)

I proposed an update, what do you think?

Also, I could not find this behavior described here: https://docs.scion.org/en/latest/protocols/scmp.html, so we probably need to update the doc.

I don't see the update.

for replies the ID field is inspected to dispatched the port directly to the underlay client port

~~What ID? And~~ how do rotuers map this ID to a port?

Identifier field in SCMP information messages. It's a direct mapping.

Does the identifier include a port directly? Or is the router supposed to stare state containing mappings of identifiers to source endpoint underlay ports?

No state, the field just contains the port number.

Co-authored-by: Tilmann <tilmann_dev@gmx.de>

nicorusti · 2026-03-09T11:01:31Z

+Control plane components of different ASes communicate with each other through RPC messages that are transported via Connect RPC. This protocol carries messages over HTTP/3, that uses a QUIC transport layer.  Identification of the relevant addresses and ports for inter-domain queries is provided by  `Service discovery <https://datatracker.ietf.org/doc/html/draft-dekater-scion-controlplane-15#name-control-service-discovery>`_.
+
+For intra-domain communication of endpoints with service instances, the operator may use arbitrary ports, that have to be communicated to endpoints. For a comprehensive list of ports used by this implementation, refer to the `Control Port Table <../manuals/control.html#port-table>`_.


Suggested change

Control plane components of different ASes communicate with each other through RPC messages that are transported via Connect RPC. This protocol carries messages over HTTP/3, that uses a QUIC transport layer. Identification of the relevant addresses and ports for inter-domain queries is provided by `Service discovery <https://datatracker.ietf.org/doc/html/draft-dekater-scion-controlplane-15#name-control-service-discovery>`_.

For intra-domain communication of endpoints with service instances, the operator may use arbitrary ports, that have to be communicated to endpoints. For a comprehensive list of ports used by this implementation, refer to the `Control Port Table <../manuals/control.html#port-table>`_.

Control plane components communicate with each other and with end-hosts through RPC messages transported via Connect RPC. This protocol carries messages over HTTP/3, that uses a QUIC transport layer. They therefore do not communicate directly on top of the UDP/IP underlay.

For inter-AS communication, traffic is transported on top of UDP/SCION between control service instances. Identification of the relevant control service addresses and ports is provided by `Service discovery <https://datatracker.ietf.org/doc/html/draft-dekater-scion-controlplane-15#name-control-service-discovery>`_.

For intra-AS communication, traffic is transported on top of IP between end-hosts and control service instances. The port used by control service instances is configured by operators, and configured on end-hosts. For a comprehensive list of ports used by this implementation, refer to the `Control Port Table <../manuals/control.html#port-table>`_.

How about this @JordiSubira ?

It seems we have a contradiction:

This protocol carries messages over HTTP/3, that uses a QUIC transport layer

But port-table says:

QUIC + gRPC with HTTP/2

https://github.com/nicorusti/scion/blob/9fdeabdc157194ece544c56d5aa8d556d60e151b/doc/manuals/control/port-table.rst?plain=1#L6

The port-table should probably say "Connect RPC over HTTP/3"

My point is that inter-AS traffic is SCION/UDP/IP and intra-AS traffic is TCP/IP (no SCION), if you still believe you have to mention it here, I would make clear this (gRPC/HTTP/TCP/IP or ConnectRPC/HTTP/TCP/IP) (no SCION) whatever the client implements or will implement in the future.

I think now I understand the problem.
If we discuss non-SCION traffic (e.g. endpoint<->control server), then we should add that to the introduction (the introduction currently says we are discussing SCION/UDP/IP traffic).
I guess my summary:

inter-domain traffic: SCION/UDP/IP (dataplane + control plane)

intra-domain:

SCION/UDP/IP (dataplane) (for simplicity let's assume intra-AS dataplane uses SCION)

TCP/IP (control plane)

Right?

This was my point, indeed.

I updated the intro, does that help?

How about this:

Suggested change

Control plane components of different ASes communicate with each other through RPC messages that are transported via Connect RPC. This protocol carries messages over HTTP/3, that uses a QUIC transport layer. Identification of the relevant addresses and ports for inter-domain queries is provided by `Service discovery <https://datatracker.ietf.org/doc/html/draft-dekater-scion-controlplane-15#name-control-service-discovery>`_.

For intra-domain communication of endpoints with service instances, the operator may use arbitrary ports, that have to be communicated to endpoints. For a comprehensive list of ports used by this implementation, refer to the `Control Port Table <../manuals/control.html#port-table>`_.

Control plane components communicate with each other and with end-hosts through RPC messages transported via Connect RPC.

For inter-AS communication, traffic is transported over ConnectRPC/HTTP3/QUIC/UDP/SCION/UDP/IP between control service instances. Identification of the relevant control service addresses and ports is provided by `Service discovery <https://datatracker.ietf.org/doc/html/draft-dekater-scion-controlplane-15#name-control-service-discovery>`_.

For intra-AS communication, traffic is transported over ConnectRPC/HTTP/TCP/IP between end-hosts and control service instances. The port used by control service instances is configured by operators, and configured on end-hosts. For a comprehensive list of ports used by this implementation, refer to the `Control Port Table <../manuals/control.html#port-table>`_.

Co-authored-by: Tilmann <tilmann_dev@gmx.de>

tzaeschke · 2026-03-13T09:34:20Z

+Control plane components of different ASes communicate with each other through RPC messages that are transported via Connect RPC. This protocol carries messages over HTTP/3, that uses a QUIC transport layer.  Identification of the relevant addresses and ports for inter-domain queries is provided by  `Service discovery <https://datatracker.ietf.org/doc/html/draft-dekater-scion-controlplane-15#name-control-service-discovery>`_.
+
+For intra-domain communication of endpoints with service instances, the operator may use arbitrary ports, that have to be communicated to endpoints. For a comprehensive list of ports used by this implementation, refer to the `Control Port Table <../manuals/control.html#port-table>`_.


How about this:

Suggested change

Control plane components of different ASes communicate with each other through RPC messages that are transported via Connect RPC. This protocol carries messages over HTTP/3, that uses a QUIC transport layer. Identification of the relevant addresses and ports for inter-domain queries is provided by `Service discovery <https://datatracker.ietf.org/doc/html/draft-dekater-scion-controlplane-15#name-control-service-discovery>`_.

For intra-domain communication of endpoints with service instances, the operator may use arbitrary ports, that have to be communicated to endpoints. For a comprehensive list of ports used by this implementation, refer to the `Control Port Table <../manuals/control.html#port-table>`_.

Control plane components communicate with each other and with end-hosts through RPC messages transported via Connect RPC.

For inter-AS communication, traffic is transported over ConnectRPC/HTTP3/QUIC/UDP/SCION/UDP/IP between control service instances. Identification of the relevant control service addresses and ports is provided by `Service discovery <https://datatracker.ietf.org/doc/html/draft-dekater-scion-controlplane-15#name-control-service-discovery>`_.

For intra-AS communication, traffic is transported over ConnectRPC/HTTP/TCP/IP between end-hosts and control service instances. The port used by control service instances is configured by operators, and configured on end-hosts. For a comprehensive list of ports used by this implementation, refer to the `Control Port Table <../manuals/control.html#port-table>`_.

JordiSubira

LGTM content-wise now.

romshark

LGTM

nicorusti · 2026-03-14T12:06:43Z

Thank you all for contributing! I think it looks great and it can be merged.
@tzaeschke I left some minor edits on NAT traversal, if you agree could you add them?
If not, could you merge anyways and then we polish it in another PR?
I need the link up on Monday so that I can also upload the last DP draft version :)

Co-authored-by: Nicola Rustignoli <nicorusti@users.noreply.github.com>

tzaeschke

LGTM

romshark

LGTM

Document UDP underlay and ports

736f3d9

nicorusti changed the title ~~Document UDP underlay and ports~~ doc: document UDP underlay and ports Mar 3, 2026

nicorusti added 2 commits March 3, 2026 14:47

rearrange content

c58b16e

polish

70b70cb

nicorusti marked this pull request as ready for review March 3, 2026 13:50

nicorusti requested review from JordiSubira and tzaeschke March 3, 2026 13:53

Fix table

e857ff4

tzaeschke reviewed Mar 3, 2026

View reviewed changes