[RFC] Mobile IPv6 introduction

[RFC] Mobile IPv6 introduction

[Masahide NAKAMURA]

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

[PATCH 0/23][XFRM] MIPv6 CN introduction (part A) (Re: [RFC] Mobile IPv6 introduction)

[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


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


-- 
Masahide NAKAMURA

[PATCH 0/20][IPV6/XFRM] MIPv6 CN (part B)

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



> 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
> 
[snip]

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

Thanks,


-- 
Masahide NAKAMURA

Re: [PATCH 0/20][IPV6/XFRM] MIPv6 CN (part B)

[David Miller]

From: Masahide NAKAMURA <nakam@linux-ipv6.org>
Date: Sat, 29 Jul 2006 18:37:04 +0900

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

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.

Re: [PATCH 0/20][IPV6/XFRM] MIPv6 CN (part B)

[Masahide NAKAMURA]

David Miller wrote:
> From: Masahide NAKAMURA <nakam@linux-ipv6.org>
> Date: Sat, 29 Jul 2006 18:37:04 +0900
> 
>> 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".
> 
> 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

Re: [RFC] Mobile IPv6 introduction

[Hugo Santos]

[-- 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 --]

Re: [RFC] Mobile IPv6 introduction

[David Miller]

From: Hugo Santos <hsantos@av.it.pt>
Date: Sat, 29 Jul 2006 15:12:44 +0100

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

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

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

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.

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

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.

Re: [RFC] Mobile IPv6 introduction

[Hugo Santos]

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

David,

On Tue, Aug 01, 2006 at 05:35:35PM -0700, David Miller wrote:
> This is partly why the multiple routing table code is being
> added as the initial infrastrucutre, so that source based
> things are possible.

   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.

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

   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.

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

   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

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

Re: [RFC] Mobile IPv6 introduction

[David Miller]

From: Hugo Santos <hsantos@av.it.pt>
Date: Wed, 2 Aug 2006 01:58:49 +0100

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

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.

Re: [RFC] Mobile IPv6 introduction

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20060802005849.GK8334@innerghost.net> (at Wed, 2 Aug 2006 01:58:49 +0100), Hugo Santos <hsantos@av.it.pt> says:

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

I also have several patches which are being sent.

--yoshfuji

Re: [RFC] Mobile IPv6 introduction

[Ville Nuorvala]

Hugo Santos wrote:
> David,
> 
> On Tue, Aug 01, 2006 at 05:35:35PM -0700, David Miller wrote:
>> This is partly why the multiple routing table code is being
>> added as the initial infrastrucutre, so that source based
>> things are possible.
> 
>    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.

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.

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

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

Re: [RFC] Mobile IPv6 introduction

[Hugo Santos]

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

Hi Ville,

On Wed, Aug 02, 2006 at 10:58:49AM +0300, Ville Nuorvala wrote:
> 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.

   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.

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

   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

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

Re: [RFC] Mobile IPv6 introduction

[Masahide NAKAMURA]

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

Re: [RFC] Mobile IPv6 introduction

[Hugo Santos]

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

Hi,

   Thanks for the reply, however:

On Wed, Aug 02, 2006 at 12:24:30PM +0900, Masahide NAKAMURA wrote:
> 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.

   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

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

Re: [RFC] Mobile IPv6 introduction

[Masahide NAKAMURA]

Hugo Santos wrote:
>    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

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,

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

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

Re: [RFC] Mobile IPv6 introduction

[David Miller]

From: Masahide NAKAMURA <nakam@linux-ipv6.org>
Date: Wed, 02 Aug 2006 22:03:16 +0900

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

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.