> On Jun 9, 2017, at 10:04 AM, Mikael Abrahamsson <[email protected]> wrote: > > On Fri, 9 Jun 2017, Tommy Pauly wrote: > >> The kernel is still responsible for managing the port namespace between >> applications, and demultiplexing incoming packets to the correct processes. >> Since that is part of the kernel, the port demultiplexing still needs to >> understand where to look for port numbers in known protocols. It seems like >> for the use-case you’re mentioning for new protocols, it could be useful to >> allow that logic to be extended, or ‘learn’ new protocols. This isn’t >> something we’re doing now, but definitely an interesting idea! > > Also sounds like a use-case for the work on "device should be handed multiple > addresses". If it were, you could multiple in a way that each process that > needed to have its own port space or run special protocols, could get unique > usage of a newly allocated IPv6 address. > > If this is something that would be useful, it would be good if this use-case > was brought to 6man and v6ops. It would probably be more credible if you > brought it than if I did.
Hi Mikael, A per-process IPv6 address is not something we’re doing at this time, but it’s certainly a natural extension of an in-process networking stack. If the device is being allocated multiple IPv6 address, and ideally a /64, as recommended by RFC 7934, then the host system could assign an address to each process, or at least each process that has beyond-ordinary networking needs. This could also have interesting implications for a device that’s dealing with multiple Provisioning Domains (PvDs). Processes could be grouped to share the address/port namespaces of a given PvD; for example, enterprise applications could be using a common address and set of ports, while personal applications could be sharing another set. The main open question I would have would be around how an application would express that it should be using a separate address-space, or how that would be indicated as some sort of TAPS parameters. Any ideas are welcome =) Thanks, Tommy > > -- > Mikael Abrahamsson email: [email protected] _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
