Hugo Santos wrote:

   Although the ICMP-filter approach would be better, it is not flexible
 enough to handle this situation. We must also send ICMPv6 Parameter
 Problems when ip6mh_proto isn't IPPROTO_NONE. I don't think it is too

I don't think IPPROTO_NONE case is a suitable example here
(it is also supported by our kernel patch).
We don't have any problem about who checks next header field since its
offset of mobility header never changes then its value
can be checked as the same way for all type number.

But anyway,

 much of a burthen to handle ICMPv6 in the control daemon because you
 should already do so to react to ICMPv6 error messages from peers
 concerning MIPv6 signalling. I'm strongly against doing these checks in
 the kernel for the simple reason that it is not easily extendable.  You
 wouldn't be able to deploy a new daemon version over an existing kernel
 with these changes if it supported a new control protocol with new
 messages. I think we should follow a different path here and i propose
 either have a hdrinc=1 mode (for reception only) for protocol raw
 sockets, possibly adding with control on reception which specifies the
 offset of the UPL header; or have a control message to obtain the
 network headers. For instance:

      put_cmsg(msg, SOL_IPV6, ..., (skb->h.raw - skb->nh.raw),
               skb->nh.raw);

I can agree such suggestion as new kernel feature but I'm not sure
MIPv6 stuff should depend on it just for new message type to extend later.
On our design MIPv6 signaling itself is almost done by user-space daemon.
When developer wants to add new or original type number, it is enough for
kernel to be added the number and its length. All other things can be modified at
user-space application. If there is much requirement to add new type number
without any modification of kernel code at all I would support ICMPv6 filter approach,
too.

-- 
Masahide NAKAMURA