Henderson, Thomas R wrote:
Besides the fragmentation issue, the way it is defined now, it seems burdensome to implementations that want to implement the shim6 control plane as a user-space daemon (as opposed to defining a separate protocol number for shim6 control messages). My reading of IPv6 raw sockets semantics suggests that they cannot be used. from RFC 3542: "With IPv6 raw sockets will be used for ICMPv6 and to read and write IPv6 datagrams containing a Next Header field that the kernel does not process." This is not the case for shim6 since the kernel does process the payload extension header in the data plane. Under current definition, how should a user-space shim6 implementation use IPv6 sockets API to get only the control messages? If there isn'tan easy way, should we consider to separate the protocol numbers?
Thomas,Are you saying that the *only* thing that prevents a complete shim6 user-space implementation using standard APIs is the fact that shim6 uses a single protocol number? I find that very hard to believe since I don't know of any standard APIs that allow me to insert the transmit side data plane of shim6 in the transmit path. The API RFCs clearly don't have such a mechanism, nor does the socket standard from the open group. Thus a user space shim6 implementation would require some non-standard extensions and/or modifications to the stack. Given that, I suspect one can figure out how to handle the above issue as well.
The reason for using a single protocol number for shim6 is to increase the probability of uniform handling by existing firewalls. With a single protocol number existing firewalls would probably either let all such packets through, or block all of them. If we chose to instead use multiple protocol numbers there is the danger that some packets (such as the context establishment packets) make it through the firewall while others (such as the payload packets) are blocked. That possibility adds a new failure mode which is hard to deal with, especially if the probe messages get the same firewall treatment as the context establishment packets.
Erik