Re: [RFC] Mobile IPv6 introduction

[Masahide NAKAMURA <nakam@linux-ipv6.org>]

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