Mobile IPv6 patch for NetBSD-current (revised)

[Keiichi SHIMA]

Hello all,

Long time ago, I proposed Mobile IPv6 patch for NetBSD current. I
received several comments, but could not release revised patch until
now. Sorry for my long silence.

I'm now releasing the patch again with some updates. The modified
points from the previous patch are:

- less '#ifdef MOBILE_IPV6' especially in 'if' conditions
to improve code readability
- mip(4) manual (it is still very basic, though)

Some suggested me that the code should support FAST_IPSEC. I
completely understand the idea, however, the patch is not ready to
support it yet. I will support it once the patch is imported to the
repository.

Others suggested that it would be great if there was an implementation
document (like IP, IPv6, IPsec). I haven't written that kind of
documents yet.

The patch (and new files) is available from http://www.mobileip.jp/~keiichi/tmp/mobile-ipv6-20080125.tgz

The overview of the change is:

- the type 2 routing header processing
- the home address option (one of the destination options)
processing.
- some new ICMPv6 messages defined in Mobile IPv6
- the mobility header processing (the new extension header for
Mobile IPv6 signaling messages)
- the mip pseudo interface to represent a home network
- the mobility information message exchange mechanism between
the kernel and user space programs (PF_MOBILITY socket)
- new IPv6 address properties (e.g. the HOME flag,
the DEREGISTERING flag)
- the type 2 routing header socket API
- neighbor discovery extension (e.g. retuning home detection for
mobile nodes, packet intercept by home agents)
- source address selection extension (home addresses are preferred)
- IPsec SA/SP db update according to the movement of mobile nodes.

With this change, the following files are modified:
distrib/sets/lists/comp/mi
lib/libc/net/rthdr.c
sbin/ifconfig/af_inet6.c
sbin/ifconfig/ifconfig.c
sys/conf/files
sys/net/Makefile
sys/net/if_types.h
sys/net/pfkeyv2.h
sys/net/route.h
sys/net/rtsock.c
sys/netinet/Makefile
sys/netinet/icmp6.h
sys/netinet/in.h
sys/netinet/ip6.h
sys/netinet6/Makefile
sys/netinet6/dest6.c
sys/netinet6/files.netinet6
sys/netinet6/in6.c
sys/netinet6/in6.h
sys/netinet6/in6_proto.c
sys/netinet6/in6_src.c
sys/netinet6/in6_var.h
sys/netinet6/ip6_forward.c
sys/netinet6/ip6_input.c
sys/netinet6/ip6_output.c
sys/netinet6/ip6_var.h
sys/netinet6/ipsec.c
sys/netinet6/nd6.c
sys/netinet6/nd6.h
sys/netinet6/nd6_nbr.c
sys/netinet6/nd6_rtr.c
sys/netinet6/raw_ip6.c
sys/netinet6/route6.c
sys/netkey/key.c
sys/netkey/key.h
sys/sys/socket.h

The change introduces these new files
share/man/man4/mip.4
sys/net/if_mip.c
sys/net/if_mip.h
sys/net/mipsock.c
sys/net/mipsock.h
sys/netinet/ip6mh.h
sys/netinet6/mip6.c
sys/netinet6/mip6.h
sys/netinet6/mip6_var.h


Best Regards,

---
Keiichi SHIMA
IIJ Research Laboratory <***@iijlab.net>
WIDE Project <***@wide.ad.jp>



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Keiichi SHIMA
Hello all,
Long time ago, I proposed Mobile IPv6 patch for NetBSD current. I
received several comments, but could not release revised patch until
now. Sorry for my long silence.
I'm now releasing the patch again with some updates. The modified
- less '#ifdef MOBILE_IPV6' especially in 'if' conditions
to improve code readability

I think that you can reduce the #ifdefs a bit more by using
ntohs() or htons() in cases such as this,

+#if BYTE_ORDER == BIG_ENDIAN
+#define MIP6_HAINFO_FLAG_MR 0x8000
+#endif /* BIG_ENDIAN */
+#if BYTE_ORDER == LITTLE_ENDIAN
+#define MIP6_HAINFO_FLAG_MR 0x0080
+#endif /* LITTLE_ENDIAN */

Post by Keiichi SHIMA
- mip(4) manual (it is still very basic, though)
Some suggested me that the code should support FAST_IPSEC. I
completely understand the idea, however, the patch is not ready to
support it yet. I will support it once the patch is imported to the
repository.
Others suggested that it would be great if there was an implementation
document (like IP, IPv6, IPsec). I haven't written that kind of
documents yet.
The patch (and new files) is available from
http://www.mobileip.jp/~keiichi/tmp/mobile-ipv6-20080125.tgz
- the type 2 routing header processing
- the home address option (one of the destination options)
processing.
- some new ICMPv6 messages defined in Mobile IPv6
- the mobility header processing (the new extension header for
Mobile IPv6 signaling messages)
- the mip pseudo interface to represent a home network
- the mobility information message exchange mechanism between
the kernel and user space programs (PF_MOBILITY socket)
- new IPv6 address properties (e.g. the HOME flag,
the DEREGISTERING flag)
- the type 2 routing header socket API
- neighbor discovery extension (e.g. retuning home detection for
mobile nodes, packet intercept by home agents)
- source address selection extension (home addresses are preferred)
- IPsec SA/SP db update according to the movement of mobile nodes.
distrib/sets/lists/comp/mi
lib/libc/net/rthdr.c
sbin/ifconfig/af_inet6.c
sbin/ifconfig/ifconfig.c
sys/conf/files
sys/net/Makefile
sys/net/if_types.h
sys/net/pfkeyv2.h
sys/net/route.h
sys/net/rtsock.c
sys/netinet/Makefile
sys/netinet/icmp6.h
sys/netinet/in.h
sys/netinet/ip6.h
sys/netinet6/Makefile
sys/netinet6/dest6.c
sys/netinet6/files.netinet6
sys/netinet6/in6.c
sys/netinet6/in6.h
sys/netinet6/in6_proto.c
sys/netinet6/in6_src.c
sys/netinet6/in6_var.h
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.

Post by Keiichi SHIMA
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?

Post by Keiichi SHIMA
sys/netinet6/ip6_output.c

What is going on here?

Post by Keiichi SHIMA
sys/netinet6/ip6_var.h
sys/netinet6/ipsec.c
sys/netinet6/nd6.c

Tunnelling? In Neighbor Discovery code? What is going on here?

Post by Keiichi SHIMA
sys/netinet6/nd6.h
sys/netinet6/nd6_nbr.c
sys/netinet6/nd6_rtr.c
sys/netinet6/raw_ip6.c
sys/netinet6/route6.c
sys/netkey/key.c
sys/netkey/key.h
sys/sys/socket.h
The change introduces these new files
share/man/man4/mip.4

I could not find this file.

Post by Keiichi SHIMA
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?

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.

Dave

[Keiichi SHIMA]

Hi,

Thank you for the comments.

Post by David Young

Post by Keiichi SHIMA
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.

Post by David Young

Post by Keiichi SHIMA
sys/netinet6/ip6_input.c

+ 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.

Post by David Young

Post by Keiichi SHIMA
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.

Post by David Young

Post by Keiichi SHIMA
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.

Post by David Young

Post by Keiichi SHIMA
share/man/man4/mip.4

I could not find this file.

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

Post by David Young

Post by Keiichi SHIMA
sys/net/mipsock.c
sys/net/mipsock.h

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.

Post by David Young
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 <***@iijlab.net>
WIDE Project <***@wide.ad.jp>





--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Post by Keiichi SHIMA
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.

I agree - a branch in the NetBSD repository would be the easiest way
for everybody.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Keiichi SHIMA
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.

That sounds very good to me.

Dave

[Tsuyoshi MOMOSE]

Hello David,

I'm a co-developper of the MIP6 stack with keiichi.
Let me talk from the view point of the MIP6 design.

Post by David Young

Post by Keiichi SHIMA
sys/net/mipsock.c
sys/net/mipsock.h

simplicity,
delegation w/ chmod/chown/chgrp)? ioctls on the MIP pseudo-interface?

The function which uses the MIP pseudo interface is for mobile node
only. Other functions such as home agent and correspondent node
doesn't need touch the interface. As the design philosophy of the
Mobile IPv6, I think the all MIP6 behavior should be done in the
netinet6 as possible.

This is the analogy of router implementation that uses PF_ROUTE
socket. With introducing the socket, routing protocol such as RIP or
OSPF can be implemented on userland and actual packet forwarding is
done in the kernel.

And as keiichi mentioned in his second mail, the MIP6 implementation
needs both direction notification from kernel to userland and from
userland to kernel. We thought the newly introduced socket would be
best for the purpose. If the socket can't be applicable, the routing
socket would be the alternative, however, using the routing socket
might cause other side effects.

Post by David Young
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.

What should be done in the MIP6 are not only encapsulating/
decapsulating the packets. If MIP6 just only does capsulation, it
could be done on the pseudo interface.
but actually it requires packet modification such like inserting or
extracting extension headers based on the MIP6 specific database,
binding update list or binding cache.
Therefore a lot of modification of the IPv6 stack are needed rather
than putting it on the pseudo interface.

thanks,

--
Tsuyoshi MOMOSE



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Keiichi SHIMA]

Hello,

Post by Keiichi SHIMA
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.

I've setup a branch (keiichi-mipv6) for this work, and have committed
current code in the branch. We will start refining the code on this
branch to make it ready for merge.

Also, I've created a new sourceforge project to serve the user space
programs used with this mobility stack. The goal of the project is to
provide the user space programs to various BSD systems (currently it
works only on the above branch of NeBSD-current and old KAME stack).
The project page is:

https://sourceforge.net/projects/shisa

Thanks,
---
Keiichi SHIMA
IIJ Research Laboratory <***@iijlab.net>
WIDE Project <***@wide.ad.jp>


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Keiichi SHIMA]

Hello,

Post by Keiichi SHIMA
Also, I've created a new sourceforge project to serve the user space
programs used with this mobility stack. The goal of the project is
to provide the user space programs to various BSD systems (currently
it works only on the above branch of NeBSD-current and old KAME
https://sourceforge.net/projects/shisa

For those who are interested in this function, I've written simple
documents that explain how to install the software and how to
configure the programs. Please check the following page.

http://sourceforge.net/docman/?group_id=218406

Thanks,
---
Keiichi SHIMA
IIJ Research Laboratory <***@iijlab.net>
WIDE Project <***@wide.ad.jp>


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hubert Feyrer]

Post by Keiichi SHIMA
http://sourceforge.net/docman/?group_id=218406

There are no newlines in the INSTALL and the README file for me, which
makes it a hard to read online. The "supported operating systems" document
works fine.


- Hubert

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Keiichi SHIMA]

Post by Hubert Feyrer

Post by Keiichi SHIMA
http://sourceforge.net/docman/?group_id=218406

There are no newlines in the INSTALL and the README file for me,
which makes it a hard to read online. The "supported operating
systems" document works fine.

Umm, I think I did the same procedure to make all these documents...,
but apparently you are right. There is no newlines...

I'll update them soon.



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Keiichi SHIMA]

Post by Keiichi SHIMA

Post by Hubert Feyrer

Post by Keiichi SHIMA
http://sourceforge.net/docman/?group_id=218406

There are no newlines in the INSTALL and the README file for me,
which makes it a hard to read online. The "supported operating
systems" document works fine.

Umm, I think I did the same procedure to make all these
documents..., but apparently you are right. There is no newlines...

No. I was wrong. I should have uploaded these documents in html
format...

I removed these corrupted documents and added a new file instead that
points document files in the CVS repository.

---
Keiichi SHIMA
IIJ Research Laboratory <***@iijlab.net>
WIDE Project <***@wide.ad.jp>


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de