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
On Sat, Jul 29, 2006 at 06:23:32PM +0900, Masahide NAKAMURA wrote:
> 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
>
>
>
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
signature.asc
Description: Digital signature
