From: Masahide NAKAMURA <[EMAIL PROTECTED]>
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
you
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
(
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
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 b
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 sou
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
> indiv
In article <[EMAIL PROTECTED]> (at Wed, 2 Aug 2006 01:58:49 +0100), Hugo Santos
<[EMAIL PROTECTED]> 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
From: Hugo Santos <[EMAIL PROTECTED]>
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 likel
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,
From: Hugo Santos <[EMAIL PROTECTED]>
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
>
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 ge
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
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 cat
13 matches
Mail list logo
