Re: [PATCHSET] Mobile IPv6 for 2.5.45

[Pekka Savola]

I believe there could be more hooks in the kernel to let userspace do 
certain tasks, for example, sending router solicitations and processing 
the responses -- sure, this can be done in the userspace but means code 
duplication.  If the code in the kernel could also be called from the 
userspace, there might be less need for duplication (though this would 
result in portability issues of course).

Similar would appear to be the case some other features listed here.

On Sat, 2 Nov 2002, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote:
> In article <[e-mail]> (at Fri, 1 Nov 2002 17:15:09 -0800), "Krishna Kumar" <[e-mail]> says:
> 
> > When the HA gets a registration request, it needs to perform the following
> > actions :
> >         1. perform DAD
> >         2. get the list of prefixes supported on the home link of the MN.
> >         3. create a tunnel between the HA and the MN
> >         4. join the solicited node multicast group of the MN's home
> > address.
> >         5. add the MN's home address to the list of proxy neigh cache entry
> > for the HA.
> >         6. Send NA on behalf of the MN
> >         7. add the new location of the MN in the binding cache.
> >         8. and finally send the Binding Registration Success/Failure
> > message.
> > 
> > In the above list, the only activities which can be done in userspace are
> > #7 and #8 (that I am aware of). The rest of the items can only be done in
> > the
> > kernel, atleast we need to move the support to kernel. If the HA
> > registration
> > is completely moved to userspace, it would still need these facilities (#1
> > to #6) in the kernel to perform the actions for registration. So even with
> > netlink
> > we still need the infrastructure in the kernel.
> 
> 1:     True:  we need some interface (and small code)
> 2:     FALSE: you CAN listen icmp6 message via raw socket.
> 3:     FALSE: you CAN create tunnel using raw socket;
>               however, we think this is implemented in kernel.
> 4,5,6: True:  we need some interface to generate proxy ND.
>               (proxy ND is already in kernel.)
> 
> For 1,4,5,6: "proxy address" on a device would be a solution.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords