Subject: [homenet] how to avoid getting stuck at Medius: additional DHCPv6 (PD) options needed?

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Jul 2013 07:01:57 -0400

1) I would ask the CableLabs guys to more clearly articulate what
   their timeline is, and what features are really in that timeline.
   (It seems to me that we could be done already if the ISPs pushed
   their suppliers of CPE devices to join the homenet WG and participate,
   and/or hired proxies and/or open-source authors to act as
   intermediaries/consultants. I realize that to first order, CableLabs
   *is* fullfulling some of that exact role)

2) If it is indeed the case that the Medius network requires hierarchical
   DHCPv6 PD, I would like to suggest that we add some additional DHCP
   options to this so that the internal routers explicitely know that they
   are internal routers, and further, that the ability of the routers to
   go to full homenet is more clearly articulated.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Jul 2013 07:27:18 -0400

During Juliusz (or was it Matthieu speaking?) presentation on source routing,
I asked the question:
  okay, great, but are these just implementation issues?
  Yes, "IP rule" sucks, and the netdev response to the question is typical.
  It sucks less than IPsec "setkey", let me tell you.

(As an aside I want to point out again that IPsec RFC2401 and RFC4301 detail
this problem. They do not solve it via the way that Matthieu and Juliusz
suggest, and that I suggested in the IPsec WG at the time, by adding explicit
routes to clarify ambiguity, but rather, but forcing the SPD to be
explicitely ordered, and mandating that the ordering knobs be available to
administrators, who have no idea what any of it means.   Note that the
ordering of the SPD is never explicitely expressed in IKEv1 or IKEv2, so in
fact it is possible for two IPsec peers to resolve the ambiguity differently)

There *is* a protocol issue/requirement.
1) if we are going to introduce a new route to deal with the
   conflict, then the routing protocol must be able to express
   what might appear to be multiple routes to the same dest/prefix.
   As we are considering link-state protocols that do not do
   summarization of routes, this may be a null requirement, but
   it is something to keep in mind if we want to consider something else.

2) while we might agree that the destination wins, so that we have
   a consistent routing table across the homenet, the routing protocol
   should have a way for a router to say, "yes, but I see a conflict"
   such that someone or something can say, "oh. Well, I shall insert a
   disambiguation route.

   I haven't thought very hard yet if it's possible for one router to
   see an ambiguity, while others would not.  This should not occur with a
   link-state routing protocol, as all routers should have the same database.
   It could however, occur because a router participates in another routing
   protocol (such as a community mesh) which the rest of the home does not
   see.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 29 Jul 2013 13:53:49 +0200

On Jul 29, 2013, at 1:01 PM, Michael Richardson <[email-masked]> wrote:
> If it is indeed the case that the Medius network requires hierarchical

That's exactly what I'm hoping to see as well.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 29 Jul 2013 15:35:41 +0200

>    what might appear to be multiple routes to the same dest/prefix.

I believe the routes only need to be local and do not need to appear on the
wire and in the routing protocol (in fact, they don't even need to be
stored locally; the draft claims that they can be recalculated when adding
/ removing real routes from the FIB).

As regards the reason for existence of the routes themselves, David
Lamparter tells me that he has in fact gotten the Linux IPv6 source routing
code (the mythical CONFIG_IPV6_SUBTREES?) to work on 3.8. Attempting to CC
a randomly-found email address I have for him so he can comment directly.
David?

---

From: Acee Lindem <[email-masked]>
Date: Mon, 29 Jul 2013 14:01:27 +0000

From: Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 29, 2013 6:35 AM
To: Michael Richardson <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, David Lamparter <[email-masked]<mailto:[email-masked]>>
Subject: Re: [homenet] source routing requirements for routing protocols

On Mon, Jul 29, 2013 at 1:27 PM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:
1) if we are going to introduce a new route to deal with the
   conflict, then the routing protocol must be able to express
   what might appear to be multiple routes to the same dest/prefix.

I believe the routes only need to be local and do not need to appear on the wire and in the routing protocol (in fact, they don't even need to be stored locally; the draft claims that they can be recalculated when adding / removing real routes from the FIB).

As regards the reason for existence of the routes themselves, David Lamparter tells me that he has in fact gotten the Linux IPv6 source routing code (the mythical CONFIG_IPV6_SUBTREES?) to work on 3.8. Attempting to CC a randomly-found email address I have for him so he can comment directly. David?

Agreed. We've had several presentations and tutorials on source/destination routing at the last three home net meetings. I believe they can be summarized by 1) All routers in the routing domain must use the same priority for routing lookup keys. In this case, the routing keys are Longest Prefix Match (LPM) on destination address and followed by LPM on source address limited to entries with the LPM destination address match. 2) All routers in the routing must use the same rules or policies to install additional routes to resolve ambiguities.

That the routers in the routing domain agree is actually more important than the actual routing key priority or policies.

Thanks,
Acee

---

From: David Lamparter <[email-masked]>
Date: Mon, 29 Jul 2013 16:32:09 +0200

> a randomly-found email address I have for him so he can comment directly.

(warning: wall of text.  skip down to last paragraph for results.)

I've tested the following setup:

host A - router
# system: Linux 3.8.3
# CONFIG_IPV6_SUBTREES=y
# ip utility, iproute2-ss130221

# (0) enable ipv6 forwarding (...)

# (1) set routes

ip link add name test0 type dummy
ip link add name test1 type dummy
ip link add name test2 type dummy
ip link add name test3 type dummy
ip link set test0 up
ip link set test1 up
ip link set test2 up
ip link set test3 up
ip -6 route add 2001:db8::/32 via fe80::1 dev test0
ip -6 route add 2001:db8:dead::/48 from 2001:db8:cafe:1::/64 via fe80::1 dev test1
ip -6 route add 2001:db8:dead::/48 from 2001:db8:cafe:2::/64 via fe80::1 dev test2
ip -6 route add 2001:db8:dead::/48 from 2001:db8:cafe:2::f00d/128 via fe80::1 dev test3
ip -6 route add 2001:db8:dead:beef::/64 dev test3

# (2) connection to packet source - fix as needed
ip -6 link set veth0 up
ip -6 addr add fe80::1/64 dev veth0
ip -6 addr add 2001:db8:cafe:0::1/64 dev veth0
ip -6 addr add 2001:db8:cafe:1::1/64 dev veth0
ip -6 addr add 2001:db8:cafe:2::1/64 dev veth0

# (3) now start 4 tcpdumps/wiresharks/... on test0..3

host B - packet source

# - interlude: shortcut to virtualise host B, skip if appropriate -
#   unshare -n /bin/bash
# you now have a shell in a separate network namespace. now do:
#   ip link set lo up
#   ip link add name veth0 type veth peer name veth0 netns 1
# you now have a "veth0" interface on both your host and your network
# namespace shell session.  don't forget to set them "up".
# - end interlude -

# (0) default route over linklocal, persistent over tests
ip -6 route add ::/0 via fe80::1 dev veth0

# (1) source 2001:db8:cafe:0::2, does not match sources
ip -6 addr add 2001:db8:cafe:0::2/64 dev veth0
ping6 -c 3 2001:db8::1		 # => test0 on router
ping6 -c 3 2001:db8:dead::1	 # => unreachable, no route [*]
ping6 -c 3 2001:db8:dead:beef::1 # => test3 on router
ip -6 addr del 2001:db8:cafe:0::2/64 dev veth0

# (2) source 2001:db8:cafe:1::2, matches "test1" source spec
ip -6 addr add 2001:db8:cafe:1::2/64 dev veth0
ping6 -c 3 2001:db8::1		 # => test0 on router
ping6 -c 3 2001:db8:dead::1	 # => test1 on router
ping6 -c 3 2001:db8:dead:beef::1 # => test3 on router
ip -6 addr del 2001:db8:cafe:1::2/64 dev veth0

# (3) source 2001:db8:cafe:2::2, matches "test1" source spec
ip -6 addr add 2001:db8:cafe:2::2/64 dev veth0
ping6 -c 3 2001:db8::1		 # => test0 on router
ping6 -c 3 2001:db8:dead::1	 # => test2 on router
ping6 -c 3 2001:db8:dead:beef::1 # => test3 on router
ip -6 addr del 2001:db8:cafe:2::2/64 dev veth0

# (4) source 2001:db8:cafe:2::2, matches more-specific /128 source
ip -6 addr add 2001:db8:cafe:2::f00d/64 dev veth0
ping6 -c 3 2001:db8::1		 # => test0 on router
ping6 -c 3 2001:db8:dead::1	 # => test3 on router
ping6 -c 3 2001:db8:dead:beef::1 # => test3 on router
ip -6 addr del 2001:db8:cafe:2::f00d/64 dev veth0

so, for the 2001:db8:dead::1 destination, the following happens:
- source 2001:db8:cafe:0::2 - no source match - icmp unreachable
- source 2001:db8:cafe:1::2 - matches ...1::/64 dev test1
- source 2001:db8:cafe:2::2 - matches ...2::/64 dev test2
- source 2001:db8:cafe:2::f00d - matches ...2::f00d/128 dev test3

RESULT  (stop skipping here)
======

The non source specific routes keep working as intended.  The source
specific routes work as intended, doing a longest-match on the source.
The lookup also is "final", i.e. after not finding a route with a source
match (=> first test case), Linux returns an "unreachable".

As far as I've been following, this is the desired effect?

Cheers,

-David

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 29 Jul 2013 19:03:32 +0200

>    go to full homenet is more clearly articulated.

That's a really good idea. +1.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 29 Jul 2013 19:24:31 +0200

Le 29/07/2013 16:32, David Lamparter a écrit :
[...]
> RESULT  (stop skipping here) ======
>

What _is_ longest match in detail? (regardless of src or dst).

Alex

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 29 Jul 2013 19:34:05 +0200

> During Juliusz (or was it Matthieu speaking?)

'Twas me, Juliusz.

> As an aside I want to point out again that IPsec RFC2401 and RFC4301
> detail this problem. They [force] the SPD to be explicitely ordered,
> and mandating that the ordering knobs be available to
> administrators, who have no idea what any of it means.

Thanks for the pointer, I'll have a look.  (Not that these are the
most digestible RFCs ever.)

>    what might appear to be multiple routes to the same dest/prefix.

No.  The disambiguation routes appear in the RIB only, they never
appear in the FIB, let alone on the wire.

>    such that someone or something can say, "oh. Well, I shall insert a

I don't think that's necessary -- what issue are you trying to solve?

>    see an ambiguity, while others would not.

Yes, that's normal behaviour in the presence of filtering.  It does
not appear to cause any issues.

>    This should not occur with a link-state routing protocol

Assuming a single area, you're right.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 29 Jul 2013 19:36:41 +0200

> code (the mythical CONFIG_IPV6_SUBTREES?) to work on 3.8.

David,

That's really weird, since we've tried and failed on Debian's 3.8.
Perhaps it only works for forwarded packets, not for locally
originated ones?

Could you please try repeating the tests described in

  http://www.spinics.net/lists/netdev/msg235316.html

and see if they work for you?

-- Juliusz

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 29 Jul 2013 19:41:48 +0200

>  Perhaps it only works for forwarded packets, not for locally

Source-based routing will never work for locally originated packets because
source address selection is done after routing. So at routing lookup time
there is no source address to match.

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 29 Jul 2013 18:52:01 +0000

Longest match specifies that the longest prefix that matches a particular
address should be used in looking up a leaf, and eventually an adjacency
that specifies the L2 rewrite information and outgoing interface in
standard destination lookup forwarding.

For source/dest lookup, a source lookup is performed and then a dest
lookup based on the source results.

An example of longest match:

When matching 1234:5678::1, three routes are found in the routing table:
::/0
1234::/16
1234:5678::/32

Longest match says 1234:5678::/32 will be chosen.

- Wes

On 7/29/13 1:24 PM, "Alexandru Petrescu" <[email-masked]>
wrote:

>_______________________________________________
>homenet mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/homenet

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 29 Jul 2013 21:01:53 +0200

> lookup based on the source results.

For dst-based longest-match there is this concept of "default" route: if 
longest-match fails then pick the default.

Is there such concept with src-bsed longest-match? (if longest match on 
src fails then pick a default).

Which of the 2 defaults would prime over the other?

> When matching 1234:5678::1, three routes are found in the routing table:

Yes, but this is not specified.

Alex

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 29 Jul 2013 19:29:40 +0000

>Which of the 2 defaults would prime over the other?

A default route is simply a fancy name for the route with prefix ::/0.

With src/dst routing, there is potentially a ::/0 destination prefix that
corresponds to each source prefix.
There is also potentially a whole destination lookup table that¹s entirely
devoted to the ::/0 source prefix.

- Wes

---

From: Teco Boot <[email-masked]>
Date: Tue, 30 Jul 2013 00:28:51 +0200

> # (3) source 2001:db8:cafe:2::2, matches "test1" source spec
Typo? Would be: 
# (3) source 2001:db8:cafe:2::2, matches "test2" source spec

> # (4) source 2001:db8:cafe:2::2, matches more-specific /128 source
Typo? Would be: 
# (4) source 2001:db8:cafe:2::food, matches more-specific /128 source

> As far as I've been following, this is the desired effect?

Al least it looks the right route :-)

Teco

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Jul 2013 02:00:04 -0400

> I don't think that's necessary -- what issue are you trying to solve?

Different routers might have different sources of routing information.
While the OSPF/BABEL/insert-new-one routes might be identical, a given
specific router might have other routes from other places (RPL, VPNs, etc.)
which would cause *it* to insert dis-ambiguation routes that other routes
would not see a reason for.

I think that I'd like all routers to be consistent.

---

From: Chris Grundemann <[email-masked]>
Date: Wed, 31 Jul 2013 12:01:42 +0000

Thanks for the feedback Michael,

>   *is* fullfulling some of that exact role)

The timeline we are working from is ASAP; not having fully functional IPv6
capable home routers is currently a significant hurdle to real IPv6
adoption in residential broadband networks.

The key features (from my perspective) are very much in line with the
homenet architecture documents stated principles, namely basic network
detection (where's the Internet), addressing of both end-clients and
multiple home routers, routing between in-home CPE (IPv4 and IPv6),
routing from in-home CPE to the Internet (IPv4 w/ NAT and IPv6), in-home
multicast forwarding (primarily in support of existing service discovery
protocols), and basic fire walling (simple security) on the CER.

Within the CableLabs "ecosystem" we are absolutely working with suppliers
and have included all of the above key features in the eRouter
specification: 
https://www.cablelabs.com/doczone/docsis/requirements/specs/current/issued/
erouter/DocZoneFolder_view (the notable exception is edge detection, as we
currently rely on the inclusion of a Cable Modem (CM) as indication of
where the/an ISP is connected to the HIPnet). The HIPnet draft
(draft-grundemann-hipnet) is our effort to share what we have already
completed with the wider IETF audience.

>   go to full homenet is more clearly articulated.

The HIPnet solution is very much focused on providing a solution that is
actually implantable today, a large part of that is not adding new
protocols and not changing existing protocols unless absolutely necessary.
We did include what we are calling a "/48 check"
(https://tools.ietf.org/html/draft-grundemann-hipnet-00#section-4.1) in
the HIPnet draft to allow IRs to determine that they are IRs without
having to create a new communication protocol (or update an existing one).

Cheers,
~Chris

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 31 Jul 2013 15:45:27 +0200

Le 29/07/2013 21:29, Wes Beebee (wbeebee) a écrit :
>> For dst-based longest-match there is this concept of "default"
>> route: if longest-match fails then pick the default.
>>
>> Is there such concept with src-bsed longest-match? (if longest
>> match on src fails then pick a default).
>>

Right.  With the particularity that its bits are not scanned by the
longest-match.

> With src/dst routing, there is potentially a ::/0 destination prefix
> that corresponds to each source prefix.

If no prefix is found by the longetst-matching on the src address, will
a default be used instead?

Alex

> There is also potentially a whole destination lookup table that¹s
> entirely devoted to the ::/0 source prefix.
>
> - Wes
>
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 31 Jul 2013 09:57:50 -0400

> having to create a new communication protocol (or update an existing one).

This new option in DHCPv6 is from the Customer Edge Router (CER) to the
Interior Router (btw: Interior Router is not in the homenet-arch glossary).
So no existing equipement or provisioning at the ISP is needed do this.

As for getting a DHCPv6 option for this to deploy yesterday, it could be a
vendor-option, to be replaced with an IETF creation option.  I note that
the following entities already have Enterprise Numbers:

1174   Time Warner Cable, Inc.
4491   Cable Television Laboratories, Inc.

If time is of such an essence here,  then it's more important that the option
be emitted in Medius capable CER devices, and that it declare "Medius"
or ">Medius" clearly, than that we know what exactly an Interior Router needs to
*do* when it sees that.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 31 Jul 2013 10:02:38 -0400

(I've changed the subject)

    > adoption in residential broadband networks.

ASAP doesn't tell us what the product lifecycle for the devices that are
going to be produced is.

    > protocols), and basic fire walling (simple security) on the CER.

Not having compared your list to the arch document, I think that the only
thing you left out is multiple ISPs.

    > erouter/DocZoneFolder_view (the notable exception is edge detection, as

It requires a login.... I've asked for one.

    > completed with the wider IETF audience.

Okay, so you already have an extra edge detection.
Maybe you can send text for Erik Kline's document.

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Wed, 31 Jul 2013 15:38:31 +0000

>> entirely devoted to the ::/0 source prefix.

My understanding is that there IS a default for source address (see the
above comment).

- Wes

---

From: Chris Grundemann <[email-masked]>
Date: Wed, 31 Jul 2013 15:44:19 +0000

>(I've changed the subject)

Thanks.

>ASAP doesn't tell us what the product lifecycle for the devices that are

Fair point. I will defer to the folks planning to deploy eRouters wrt
expected lifecycle though (a cop out I know).

>thing you left out is multiple ISPs.

That sounds about right. And while it's not a priority, HIPnet will handle
multi-ISP, especially if you look at the potential "Provectus" phase in
jvkjjmb-home-networking-incremental
(https://tools.ietf.org/html/draft-jvkjjmb-home-networking-incremental-00#s
ection-6) where we could add a routing protocol on top of HIPnet
provisioning (probably a routing protocol which can handle source and
destination based routing).

>It requires a login.... I've asked for one.

That's my fault, here is the non-protected link (with my apologies):
http://www.cablelabs.com/cablemodem/specifications/e-router.html

>Maybe you can send text for Erik Kline's document.

What I have written is in:
https://tools.ietf.org/html/draft-grundemann-hipnet-00#section-4.1 as
"Physical" - I will look to provide more contextually significant feedback
to Erik Kline's doc as well.

Cheers,
~Chris

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 31 Jul 2013 18:15:36 +0200

Le 31/07/2013 17:38, Wes Beebee (wbeebee) a écrit :
> 
>> If no prefix is found by the longetst-matching on the src address, 
>> will a default be used instead?
>> 
>> Alex
>> 
> My understanding is that there IS a default for source address (see 
> the above comment).

Ok.

The default for dst addresses leads to a nexthop.

The default for src addresses leads also to a nexthop?  Or to the dst of
another dst prefix?  Or to the nexthop of the default of dst?

It may sound as a rathole discussion but it is fully part of what the
longest-match algorithm does.

Alex

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Wed, 31 Jul 2013 17:01:29 +0000

>longest-match algorithm does.

My understanding is that the default src address leads to exactly the same
thing as any other prefix src address - the root of a dst address table.

The algorithm is:
1) Lookup in source table.
2) Use result to look up in dest table.
3) Use result to go to next hop.

It doesn't matter if it's a prefix that's found or a default (a default is
programmed as a ::/0 prefix in the prefix table) - the lookup algorithm is
the same.  If you think about it a bit, you can probably even come up with
a very efficient algorithm that can be implemented in hardware to do this
simple two-stage lookup.

To make it even more clear:

For a source/dest prefix match, this becomes:
1) Lookup in source table, find prefix.
2) Use result to lookup in dest table, find prefix.
3) Use result to go to next hop.

For a default source/dest prefix match, this becomes:
1) Lookup in source table, find default.
2) Use default to lookup in dest table, find prefix.
3) Use result to go to next hop.

For a source prefix/default dest match, this becomes:
1) Lookup in source table, find prefix.
2) Use result to lookup in dest table, find default.
3) Use default to go to next hop.

For a default source/default dest match, this becomes:
1) Lookup in source table, find default.
2) Use default to lookup in dest table, find default.
3) Use default to go to next hop.

- Wes

---

From: Pierre PFISTER <[email-masked]>
Date: Wed, 31 Jul 2013 19:16:41 +0200

Le 31 juil. 2013 à 18:15, Alexandru Petrescu a écrit :

>>> If no prefix is found by the longetst-matching on the src address, will a default be used instead?
>>> Alex
>> My understanding is that there IS a default for source address (see the above comment).
> 
> Ok.
> 

I'm not sure about how it should be done but I can say how Linux seems to do it.

* Those affirmation came by looking at the code... That I didn't wrote. So I cannot be 100% sure *

Linux uses a tree structure in order to perform the longest prefix lookup on the destination address first.
The found node (which has the longest prefix for the source address), CAN have a subtree. 
This subtree has the same structure as a regular routing table, but is used with the source address.

This means that each node in a routing table has its own source routing table. There is no
destination lookup first and then a source lookup in a global table.

--> See fib6_lookup, and fib6_lookup_1 functions

Now, when you add a route with destination and source prefix, 
the node for destination is created (or updated) and, then, 
if the source routing prefix length is not null, a subtree is created (or updated) and
a node with the provided source prefix is inserted.

--> See fib6_add

Therefore, for a given node in the main tree, if there is no source routing (no subtree), the route
is always used. Otherwise, a longest prefix match is performed on the source address, using the subtree. 
If there is no corresponding node for the source (no matching prefix, where the prefix length can be null), 
then, the parent node in the destination routing table is used as default. 

So, yes, inserting a route for a destination and source prefix will create an entry for the destination alone 
(without source routing). 
So the default route, for a source lookup, is basically the last inserted next-hop for the destination prefix... 
Which could create unexpected behaviors.

Concerning the previous question, Linux actually has a RTF_GATEWAY flag. But it doesn't seem to
be used in the routing decision process. I guess it is used by other protocols that like to have a 
concept of "default router".

Pierre

---

From: Michael Richardson <[email-masked]>
Date: Wed, 31 Jul 2013 14:14:17 -0400

> It requires a login.... I've asked for one.

But, it requires an NDA to be executed.

---

From: Chris Grundemann <[email-masked]>
Date: Wed, 31 Jul 2013 18:52:44 +0000

>But, it requires an NDA to be executed.

Yes, that was my mistake, I sent the internal link. The same document is
available publicly here:
http://www.cablelabs.com/cablemodem/specifications/e-router.html

Cheers,
~Chris

---

From: Pierre PFISTER <[email-masked]>
Date: Thu, 1 Aug 2013 08:57:39 +0200

Teco pointed at a possible mistake, and I actually made one (reading code is not easy...).

-> If you insert an entry with source and destination prefixes, it will create a node in the main
tree and in the subtree. 

*But*

There is no routing information in the node created in the main tree (The flag RTN_RTINFO is not set).

And it seems that Linux, when it finds its longest prefix for the destination, doesn't step back to a previous (shortest prefix) entry
if there is no matching prefix for the source address in the subtree. (It returns the current node, which has not valid routing information).

And then the packet is probably dropped.

Pierre