tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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


Thank you for the comments.

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


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.


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.


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.


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.


I could not find this file.

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


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.

Keiichi SHIMA
IIJ Research Laboratory <>
WIDE Project <>

Home | Main Index | Thread Index | Old Index