Re: [RFC] Mobile IPv6 introduction

[Masahide NAKAMURA <nakam@linux-ipv6.org>]

Hi Hugo,

Please fine my comment inline:

Hugo Santos wrote:
[snip]
>    - 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.

As David answered, the policy routing is it.


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

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.


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

I agree XFRM should be generic transformation.

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


-- 
Masahide NAKAMURA