Re: [RFC] Mobile IPv6 introduction

[Hugo Santos <hsantos@av.it.pt>]

[-- Attachment #1: Type: text/plain, Size: 2161 bytes --]

Hi,

   Thanks for the reply, however:

On Wed, Aug 02, 2006 at 12:24:30PM +0900, Masahide NAKAMURA wrote:
> Our patch is similar as you said.  Our design is that kernel does nothing
> as possible about validation which can be done by user-space.
> As you mentioned ICMPv6 error is hard to be sent by user-space because it carries
> original packet causing error. MIPv6 RFC says when mobility header length is too short
> ICMPv6 error (parameter problem) is sent. We also discussed about design like your choice.
> but we have not taken it because ICMPv6 sending mechanism is already in kernel
> then it is reasonable to use it. We MIPL developers concluded that kernel should
> know mobility header types and their minimum length at least. I guess when we would
> support NEMO and FMIPv6, we just add their defines at that time.
> (Actually, their implementations based on MIPL2 exists.)
> If somebody would feel that such defines should be removed from kernel we have another
> idea to make new socket interface like ICMP filter to store mobility header type and its
> minimum length to kernel by user-space.

   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
 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);

   Hugo

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]