jiceatscion
commented
8 months ago For the data plane, I think we have the following IANA considerations to address:
- Informational: The fact that we mirror the UDP port space into the SCION/UDP port space; so inherit all assignments and reservations; so no IANA action required to manage the SCION/UDP port space itself.
- The dispatcher/shim SCION/UDP port at 30041, which by virtue of the mirroring needs that the UDP port 30041 be a reserved port.
- The assignment of ISD and AS numbers.
- The registration of Service Numbers (for Service addresses). --> #13
- The registration of Transport Protocols over SCION.
All other port numbers are supposedly configurable by peer-peer agreement or are AS internal concerns, so I think they do not need any IANA arbitration. However, I would prefer some IETF expert advice on that because I do not know how acceptable it is is to assume agreed-upon ports in the User range without reservation as part of an RFC published protocol.
Regarding port 30041, it is a dependency of our UDP/IP underlay network. Technically that's not part of the dataplane spec, however, the spec does mention the underlay network and it is rather hypocritical to pretend that it is out of scope. There's no interoperability between two ASes without a common underlay implementation. Nico: should we not add a section to the spec that explicitly describes the current UDP/IP encapsulation as one standard link layer for SCION?
Regarding the ISD/AS numbers, I am unsure how much IANA needs to be involved, given that we plan for the association to manage the registry. I found RFC 8126 quite obscure on that topic, so I would welcome some IETF input on that too before I start writing the section.
Regarding a Service Number registry. I am not sure we should rush to define one as there are ongoing discussions to eliminate service resolution. Nevertheless, there would likely be some alternate mechanism to designate "anycast addressed" services so some kind of registry would be needed. Opinions?
Regarding protocol numbers, we do mention that we attempt to mirror the assigned protocol numbers for IP. I think we must make a clearer statement: inherit and extend the IP assignments, and create our own registry. This would enable a seamless transition if we ever manage to deploy SCION as an IP alternative/extension. What that requires is that the 200-2003 protocols be registered in the IP protocol space as well, to ensure they remain available for such usage.
nicorusti
See RFC 8126
(Copied from https://github.com/scionassociation/standards/issues/100)