Re: Mobile IPv6 patch for NetBSD-current (revised)

[Keiichi SHIMA <keiichi%iijlab.net@localhost>]

Hi,

Thank you for the comments.


On 2008/02/19, at 2:12, David Young wrote:

> >    sys/netinet6/ip6_forward.c
>
> Why is there a special case for home addresses?  It seems that you can
> avoid the special case by putting a route to each home address in  
> the IPv6
> forwarding table; route through a Mobile IP pseudo-interface that adds
> the encapsulation.  You may benefit from the IPv6 fast-forwarding code
> in this way.  It may make it easier for you to get FAST_IPSEC to work.
>
> Strive for zero modifications to the IPv6 forwarding code.

The reason why we add the special handling for home addresses is  
because the current design doesn't use pseudo tunnel interface on the  
home agent side.  I don't remember the exact reason of this design  
(since the code was introduced in the very early stage of the stack)  
but one of the reasons is we didn't want to create many pseudo  
interfaces.  If we use a pseudo tunnel interface, we need the same  
number of interfaces as that of mobile nodes.


> >    sys/netinet6/ip6_input.c
>
> Be careful, rtcache_validate() can return NULL:
>
> +               if ((rtcache_validate(&ip6_forward_rt)->rt_flags &  
> RTF_ANNOUNCE) != 0) {
>
> What is this processing in ip6_input.c all about?  Perhaps you can do
> this processing after the protocol switch?

The code is used on a home agent when it receives a neighbor  
solicitation message to one of the mobile nodes that the home agent is  
serving.  The home agent need to receive and process the solicitation  
message on behalf of the mobile node.  If the input packet isn't a NS  
packet to the mobile node, the code goes to the mip6_forwarding label  
and the packet is finally passed to ip6_forward() function (and  
tunneled to the mobile node). Otherwise, the pcaket (a NS packet) is  
marked as 'ours' in line 513 (or around) and processed by the home  
agent.


> >    sys/netinet6/ip6_output.c
>
> What is going on here?

The code in ip6_output.c is extended to construct extension headers  
for Mobile IPv6.  A mobile node may use a Home Address option (one of  
the destination options) if the correspondent node supports Mobile  
IPv6 route optimization mechanism.  In that case, the outgoing packet  
to the peer node will have a Home Address option.

Also, a correspondent node may add a Type 2 Routing Header when it is  
communicating with a mobile node with route optimized.  In this case,  
the ouging packet will have that routing header.

The extended code in ip6_output.c handles these two extension headers.


> >    sys/netinet6/nd6.c
>
> Tunnelling?  In Neighbor Discovery code?  What is going on here?

The code is used by a mobile node, when it is going to send a packet  
whose source address is its home address.  Such a packet is not a  
topologycally correct, it is tunneled to its home agent and forwarded  
from there as if it is sent from the home network.

The problem is, a mobile node may send a direct packet to the  
destination node, that means it is not always send packets using  
tunneling.  The route optimized case is the case.  In this case, the  
packet must not tunneled even if the destination address is the same.   
That measn we need a kind of source address based routing.  We, for  
now, handle this case in the entry of nd6_output() before if_output()  
is called.


> >    share/man/man4/mip.4
>
> I could not find this file.

Oops, sorry, my bad.  I will include it on the next time.



> >    sys/net/mipsock.c
> >    sys/net/mipsock.h
>
> Why a socket here?  Why not a character device (advantages:  
> simplicity,
> delegation w/ chmod/chown/chgrp)?  ioctls on the MIP pseudo-interface?

Hum, maybe a charactor device may be ok.  Let us consider this. ioctl  
is not suitable because we need to send some notifiation messages from  
kernel side to user space programs.



> The general feeling I get by reading the patch is that it touches much
> more code than is necessary or desirable.  I think that more of the
> Mobile IPv6 functions can be put into the MIP pseudo-interface, with
> the nice side-effect that you can probably use MIPv6 with the existing
> fast-forwarding code, you can tap and filter MIPv6 packets before and
> after encapsulation, and you keep clutter out of the IPv6 stack.

OK, I understand your feeling.  Actually, the way you are suggesting  
(put more MIPv6 specific code in the pseudo interface part) is one of  
our todo items to refine the code.

I understand your comments as follows.

- tunneling code is not very clean
- kernel API (socket API) is too complicated

What is the best way to move forward on this code?  One way is to keep  
working on it on my local working directory, but in this case it is  
hard for me to share my work with my  colleagues and other NetBSD  
developers who are interested in this work.  The other way is to  
create a branch on the repository and work on enhancing the code on  
the branch.  If the latter is acceptable, then it would be great.

Regards,
---
Keiichi SHIMA
IIJ Research Laboratory <keiichi%iijlab.net@localhost>
WIDE Project <shima%wide.ad.jp@localhost>