Re: State of play with Shim6 documents

[Sébastien Barré <sbarre@info.ucl.ac.be>]

Hi,

Henderson, Thomas R wrote:
> from the current draft:
>   
> > The shim6 control messages use the same extension
> > header formats so that a single "protocol number" needs to be allowed
> > through firewalls in order for shim6 to function across the firewall.
> >     
>
> 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't
> an easy way, should we consider to separate the protocol numbers?  
>   
In the Linux Kernel, the packets are first delivered to the raw sockets, 
then processed by the kernel, if some protocol is implemented to handle 
this. This implies that if we want to have a user space raw socket that 
receives only the shim6 control messages, we need to have some shim6 
specific code inside the raw delivery kernel function, which is of 
course possible, but probably not the cleanest way to do things.

So I think I agree with Thomas : It would be helpful to have a separate 
protocol number for control and  payload messages.

Sébastien.
> Tom
>
>
>   


--
Sébastien Barré
Researcher,
CSE department, UCLouvain, Belgium