netdev - Aw: Re: Route exceptions for IPv6 routes?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <trinity-6d5496d3-c58c-4b56-a0a8-777473467042-1389788725698@3capp-gmx-bs13>
Date:	Wed, 15 Jan 2014 13:25:25 +0100 (CET)
From:	"Simon Schneider" <simon-schneider@....net>
To:	"Hannes Frederic Sowa" <hannes@...essinduktion.org>
Cc:	netdev@...r.kernel.org
Subject: Aw: Re: Route exceptions for IPv6 routes?

Hello Hannes,
thanks for the answer.

Sorry, I'm not so familiar with the implementation details.

What are nh-exceptions?

I understand the current IPv6 implementation has some performance drawbacks. Correct?

I'm especially interested in 
a) support for path MTUs
b) IPv6 policy-based routing (can I expect the same results from "ip -6 rule" commands that I get from "ip rule" commands?)

Are these basically supported (maybe not with optimal performance) ?

best regards, Simon 

Gesendet: Mittwoch, 15. Januar 2014 um 12:51 Uhr
Von: "Hannes Frederic Sowa" <hannes@...essinduktion.org>
An: "Simon Schneider" <simon-schneider@....net>
Cc: netdev@...r.kernel.org
Betreff: Re: Route exceptions for IPv6 routes?
Hi!

On Wed, Jan 15, 2014 at 09:01:22AM +0100, Simon Schneider wrote:
> I learned that the routing cache was removed from the kernel for several reasons.
>
> Some functions have been replaced with the route exceptions, e.g. storing the path MTU.
>
> My question: is this valid for both IPv4 as well as IPv6 routing, i.e. do the route exceptions work in the same way for IPv6 routes as they work for IPv4 routes?

No, situation in IPv6 land is not so good.

Currently as soon as a destination (or destination + source in case of
subtrees are in use) is resolved the routing entry is cloned and stored back
into the same trie with RTF_CACHE flag.

There are no nh-exceptions and there is no aggressive sharing taking place to
try to reduce the number of exceptions. This is especially bad for forwarding
setups, but seems to work fine for most people currently. ;)

Actually, implementing this is part of the work I am currently doing
but this needs still time until I can manage to propose this for upstream.

Greetings,

Hannes

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html