snet.Conn support for roaming use cases

[semcodech]

Binding the snet.UDPConn to an unspecified address is not possible (prevented by SCIONNetwork.OpenRaw and SCIONNetwork.NewCookedConn, would be supported by the underlying net.UDPConn.ListenUDP though.

• Is the reason for this restriction related to the packet reception?
• What is the recommended way of handling roaming use cases?
  Should the interface's IP addresses continuously be monitored, the connection closed and a new connection opened, or is there a better way to handle such a scenario?

[JordiSubira]

Hello Simon, I copy-paste part of the discussion I had offline with Juan:

This is because there's some overhead finding out what should be the underlay address based on the next_hop information. This was forbidden before (for the old-dispatcher endhost stack). After considering it, we decided to follow that same behavior on the last endhost stack change.

We also discussed that if this is really paramount we could use "netlink" on Linux for "mirroring" the system routing tables and monitor them (potentially investigating other mechanisms for other platforms).

This would work for the roaming case. In this case, you do not have to reopen the "connection" because the underlay UDP could still be bound to the wildcard address. The information you need to monitor is the next hop IP you need your underlay to send the SCION packet (based on the first hop and your system routing table).