Re: [RFC] Mobile IPv6 introduction

[Hugo Santos <hsantos@av.it.pt>]

[-- Attachment #1: Type: text/plain, Size: 4320 bytes --]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]