In article <OFCFEE31E7.E8F27031-ON88256C65.00068E7B@xxxxxxxxxxxxxxx> (at Fri, 1
Nov 2002 17:15:09 -0800), "Krishna Kumar" <kumarkr@xxxxxxxxxx> 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
> 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
> 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
> kernel, atleast we need to move the support to kernel. If the HA
> 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
> 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.