Okay, I now see what Scott meant by pointing out the limit of 128 (sic!) nodes. I assumed we were talking about Cyphal/UDP exclusively, not a bridged architecture. I will have to return to his question now then: is it acceptable to limit the total number of CAN nodes across all CAN segments in a given logical network to 128 (extra nodes are possible if certain conditions are satisfied, see below)? If yes, then the resulting network topology will be entirely flat across all segments, with the CAN-addressable node-IDs being limited to [0, 128), while the presumably more complex Cyphal/UDP nodes will be able to address the entire range of node-IDs.
I don’t immediately see how an automatic NAT-like/masquerading solution can be implemented because the node-ID addressing used in Cyphal is flat, unlike IP addressing which is hierarchical. If I understand the proposed idea correctly, masquerading requires that a node on a given segment is able to express its intent to address a peer outside of its segment explicitly. With a hierarchical address, this is done by directing traffic towards an endpoint whose address lies outside of the local subnet (defined by its mask). There is no similar mechanism in Cyphal. We could perhaps define an extension here but it comes with drawbacks such as a further increase in complexity of the transport layer.
A mapping between CAN frames and UDP frames does not exist (mostly because of the different transfer-ID management: it is cyclic in CAN and monotonic in UDP) so it does not appear to be possible to forward traffic between different networks without full transfer reassembly/segmentation at the bridge node. This will create complications when forwarding service calls because a service request and its response are matched with the help of the transfer-ID yet this information is lost when the transfer crosses a bridge. Perhaps some local state will have to be kept at the bridge to address this case (it is one aspect that seems similar to NAT).
If we were to accept the limit of 128 nodes across all CAN segments (but note once again that this limit does not affect non-CAN nodes, so the network itself may be far larger), then we could explore one obvious solution: a CAN-UDP bridge would simply absorb all traffic on one side and re-emit it on the other side. Downlink traffic (UDP->CAN) will have to be filtered by source node-ID since anything above 127 is not representable in Cyphal/CAN. The bridge will also have to rely on the uavcan.node.port.List announcements emitted by the CAN nodes to configure its own subscriptions. This is necessary because the UDP node needs to subscribe to the relevant multicast groups (send IGMP membership announcements) such that the network router would forward the required multicast traffic to it.
The special condition I mentioned earlier is that if the bridge detects that a certain node-ID is present on both downlink (CAN side) and uplink (the other side) segments, then such traffic needs not to be forwarded because it would constitute a collision. This should enable the architect to expand the set of CAN nodes beyond 128 assuming that there is a subset of them that need not communicate across IP.
There is also an option of static routing but it does come with undesirable side effects as Scott has highlighted so should we focus our attention on the (virtually) zero-configuration solutions for now?