Mobile IPv6 introduction

Hello,

Let me introduce Mobile IPv6(RFC3775) patch and its outline.

We USAGI project and HUT Go/Core project have developed for Mobile IPv6(MIPv6) stack on 2.6 tree as MIPL2 for several years. Our aim is to make kernel patch smaller (than MIPL1 which is for 2.4 kernel).

We find out we have 4 categories for the patch:

1. IPv6 policy routing
2. IPsec MIGRATE
3. Advanced XFRM for Correspondent Node(CN)
4. MISC

3, 4 are MIPv6 specific feature but 1, 2 are not. It can be discussed in parallel about 1, 2, 3 because they don't depend on others.

1. IPv6 policy routing
Thomas and Yoshifuji have already started to discuss and work for it. This is required by Mobile Node(MN) and used by Home Agent(HA).

2. IPsec MIGRATE
This is an interface to update IPsec end-point address of SAD/SPD. (there is an IETF draft: draft-sugimoto-mip6-pfkey-migrate-XX) This is required by MN and HA to use IPsec tunnel.

3. Advanced XFRM for CN
"Route optimization" defined MIPv6 specification
is designed as XFRM extension. IPv6 extension headers handling is included, too.
This feature is required by all MIPv6 nodes(CN, MN, HA) then it can be said MIPv6 platform.

4. MISC
This is a set of small patches but works with the above categories since they are finally confirmed as the MIPv6 node behavior; e.g. home addressing for MN, proxy forwarding for HA.

At first I'll send patches about category "3" very soon, just for review. Can you check them?

Thanks,

Masahide NAKAMURA

Please see patches about "Avanced XFRM for CN", following this mail. These are just for review, and it is against 2.6.17.

"Avanced XFRM for CN" tree is consists of:

A. XFRM extension for route optimization
B. IPv6 extension headers:
new type (2) of routing header
new TLV option for destination options header: home address option new header for signaling: mobility header

Part B patches depend on A. Let me start part A first.

Part A is also available as mip6cn-20060716-review branch at:

git://git.skbuff.net:9419/gitroot/nakam/linux-2.6-mip6cn-xfrm

Masahide NAKAMURA

Here is Part B patches, following this mail.

Part B is also available as mip6cn-20060716-review branch at:

git://git.skbuff.net:9419/gitroot/nakam/linux-2.6-mip6cn

This tree includes part A, then it has all patches about "Advanced XFRM for CN".

[snip]

Thanks,

Masahide NAKAMURA

From: Masahide NAKAMURA <[email protected]>
Date: Sat, 29 Jul 2006 18:37:04 +0900

These patches mainly deal with the specifics of ipv6 mobility processing, they look mostly fine to me and I could not spot any obvious errors.

Thank you for reviewing.

Next time I prepare the patch for the latest tree
with fixes about comments.

Thanks,

Masahide NAKAMURA

Hi,

First of all and to be fair let me introduce my bias -- i'm also
developing a mobility framework, which although not MIPv6-specific, does support it (we'll be running a large set of tests during the following month, hopefully culminating in an initial public release in september). In general, i'm all for integrating mobility required code into the kernel, however i have some comments regarding your approaches. Due to the large amount of small patches which are difficult to comment (please send an e-mail with a list of them next time please) i'll just leave a couple of high level comments:

- In general, lot's of places in the IPv6 stack don't take the source address into consideration and generically only use destination as key, i think this is a major setback that should be approached individually.

- I don't like having the individual MIPv6-specific messages checking in the kernel because feature-wise this is not scalable. Only data-path specific processing should be done in the kernel IMO (RT2 hdr processing, HOA DSTopt processing with address swapping, etc) Introducing new mobility header message type would involve modify- ing the kernel when there would be no other reason to do so (you would then need NEMO-specific code in the kernel, FMIPv6-specific code, etc). Taking the error reporting as an example, what i would prefer would be a way of either signaling the kernel ICMPv6 component to send ParamProb or other types of errors (difficult to support), or instead introducing a new datagram control message that would enable the control application to retrieve the original network headers (although possibly modified) and send the ICMPv6 message itself (which was my choice).

- Maybe others disagree, but i don't like having a "Route optimization" mode in XFRM. From my POV, "Route optimization" is one kind of transformation specific to MIPv6. Other protocols require other kind of transformations. I think XFRM should be instead extended to support generic transformations, where the Mobile IPv6-specific one would implement a RO transform in order to support it's binding cache. Also, these new modes are not "advanced" but instead "Mobile IPv6 specific".

Best regards,

Hugo

From: Hugo Santos <[email protected]>
Date: Sat, 29 Jul 2006 15:12:44 +0100

This is partly why the multiple routing table code is being added as the initial infrastrucutre, so that source based things are possible.

Such a scheme would need provisions for handling the case where the user eats the message, but never tells us what to do. In such a case we'd need to emit some kind of ICMPv6 message, even if it would be just a timeout generated parameter problem.

Such a layer would be needed if we ever put some kernel level components of Mobile IPv4 into the tree, which I see no reason not to, since it has this route optimization as well.

David,

There have been other approaches for partial source-based stuff. For
instance, in my tree i brought Subtrees back to a point of being usable. But what i was refering to was route-caching (some places only check cookies based on dst because we "don't support source routing"), APIs, etc. A few mails back you pointed the extension of a public structure to include a "source" attribute -- this is the kind of stuff we must add and that i think it's an independent work (read: even if the rest isn't merged, this should).

Still regarding Subtrees, is there any interest in revitalizing that
code? I have a couple patches that i could submit.

As i see it, the moment there is a raw socket open for dealing with a
particular protocol, whoever opened that socket (handling the protocol) is responsible of generating any error messages associated with the protocol running. Which is the case, the kernel shouldn't need to know whether any of the Mobile IPv6 specific messages have problems. The particular patch i was refering to does partial MIPv6 message processing inside the kernel before handing it to the socket as you only have access to the full received headers there.

Yes, the functionality is needed. My only problem is with exposing
MODE_ROUTEOPTIMIZATION, it isn't modular. But it's something i can live with.

Hugo

From: Hugo Santos <[email protected]>
Date: Wed, 2 Aug 2006 01:58:49 +0100

I'm not sure. If we implement a routing cache front end for the ipv6 FIB, which is very likely, the backend data structures aren't so important any longer.

In article <[email protected]> (at Wed, 2 Aug 2006 01:58:49 +0100), Hugo Santos <[email protected]> says:

I also have several patches which are being sent.

--yoshfuji

Hi Hugo,

I don't want to be dismissive towards your patches, but I've been working with the subtree routing stuff for several years now. And let me tell you: it has provided us with some nasty little surprises every now and then. I'm only saying it's surprisingly difficult to get right on the first try.

To name just one issue: the chicken and egg problem of source address selection and source address based routing. I solved this problem by letting policy rules (with a source prefix) add additional constraints to the address selection. This did however mean the source address selection had to be moved inside the routing code.

This is just one example; trust me, there are several more.

My latest incarnation of source address routing is against my previous version of policy routing, which luckily isn't that different from current the version by Thomas. Unless Yoshifuji-san has already ported my code to Thomas'es policy routing code, I'll start working on it.

But route optimization is just one form of packet transform; it just adds a Routing Header type 2 and/or Home Address Option Destination Header to the outgoing packet. Isn't xfrm just the right place for this?

You are right that we (HUT and USAGI) have mostly just looked at the xfrm framework from a MIPv6+IPsec perspective, but even this has helped us pinpoint several shortcomings in the current only IPsec specific framework.

IMO, this doesn't hinder, but rather helps change xfrm into the generic packet transform framework it was originally envisioned to be.

Regards,
Ville

Hi Ville,

To tell you the truth i don't know what MIPL does in terms of policy
management. In my implementation, all routing policies go into Subtrees without any kind of extra routing tables. I also had the problem you describe, but i opted for what i think is a simpler solution:

- Access router default routes are installed with a source-address, the address that was generated from the announced prefix (which to be fair degenerates to several entries if a single router announces multiple prefixes). This is based on the assumption that access routers do perform source-based ingress filtering so you may only use a particular access router for global connectivity using a particular address.
- The default home route is installed without a source-address for the "default" Home address (i may have several).

This means Linux's source address selection works without
modifications: if no address is specified, it will pick the default home route and then the Home address (which has a preference as well). In this sense, subtrees have worked fine for me.

XFRM is indeed the right place for this; i just would rather not have
the mode exposed and prefer wrapping any mode-specific stuff into optional callbacks. It might not be as performant but would allow adding new modes more easily.

Hugo

Hi Hugo,

Please fine my comment inline:

Hugo Santos wrote:
[snip]

As David answered, the policy routing is it.

Our patch is similar as you said. Our design is that kernel does nothing as possible about validation which can be done by user-space.
As you mentioned ICMPv6 error is hard to be sent by user-space because it carries original packet causing error. MIPv6 RFC says when mobility header length is too short ICMPv6 error (parameter problem) is sent. We also discussed about design like your choice. but we have not taken it because ICMPv6 sending mechanism is already in kernel then it is reasonable to use it. We MIPL developers concluded that kernel should know mobility header types and their minimum length at least. I guess when we would support NEMO and FMIPv6, we just add their defines at that time.
(Actually, their implementations based on MIPL2 exists.)
If somebody would feel that such defines should be removed from kernel we have another idea to make new socket interface like ICMP filter to store mobility header type and its minimum length to kernel by user-space.

I agree XFRM should be generic transformation.

XFRM_ADVANCED will be removed from my patch because some comments are sent.

Masahide NAKAMURA

Hi,

Thanks for the reply, however:

Although the ICMP-filter approach would be better, it is not flexible
enough to handle this situation. We must also send ICMPv6 Parameter Problems when ip6mh_proto isn't IPPROTO_NONE. I don't think it is too much of a burthen to handle ICMPv6 in the control daemon because you should already do so to react to ICMPv6 error messages from peers concerning MIPv6 signalling. I'm strongly against doing these checks in the kernel for the simple reason that it is not easily extendable. You wouldn't be able to deploy a new daemon version over an existing kernel with these changes if it supported a new control protocol with new messages. I think we should follow a different path here and i propose either have a hdrinc=1 mode (for reception only) for protocol raw sockets, possibly adding with control on reception which specifies the offset of the UPL header; or have a control message to obtain the network headers. For instance:

      put_cmsg(msg, SOL_IPV6, ..., (skb->h.raw - skb->nh.raw),
               skb->nh.raw);

Hugo

I don't think IPPROTO_NONE case is a suitable example here (it is also supported by our kernel patch).
We don't have any problem about who checks next header field since its offset of mobility header never changes then its value
can be checked as the same way for all type number.

But anyway,

I can agree such suggestion as new kernel feature but I'm not sure
MIPv6 stuff should depend on it just for new message type to extend later. On our design MIPv6 signaling itself is almost done by user-space daemon. When developer wants to add new or original type number, it is enough for kernel to be added the number and its length. All other things can be modified at user-space application. If there is much requirement to add new type number without any modification of kernel code at all I would support ICMPv6 filter approach, too.

Masahide NAKAMURA

From: Masahide NAKAMURA <[email protected]>
Date: Wed, 02 Aug 2006 22:03:16 +0900

There is no such requirement, please just continue to prepare your current patches for inclusion.

There is a limit to how much nit-picking we can do for such a large body of work, and we should thus take evolutionary approach to this work. We can make all kinds of refinements later to improve the implementation.