@kaspar030, IMO the current behavior for this setup is not a bug. In your example, you should be able to ping beef::1 and dead::blah from Linux. dead::1 is configured to a different interface, not reachable.

@OlegHahm is right, the correct way to approach this is over the FIB.

@kaspar030, IMO the current behavior for this setup is not a bug. In your example, you should be able to ping beef::1 and dead::blah from Linux. dead::1 is configured to a different interface, not reachable.

(this is just to summarize opinions from IRC)
Well, the RIOT 6lr even announces itself as default router. Linux sends the packet, dead::1 receives it eventually, but cannot find a route back to the source anymore, even though it is directly connected to the same /64 ethernet subnet and beef::2 is still in the neighbour cache. IMHO RIOT should know how to reach beef::2.

Also, if a packet arrives through one interface, RIOT should still use the best-matching prefix on any interface to send the reply, right?

I'm not sure if you read my previous statement, before you wrote that, but that is exactly what the FIB is for...

Otherwise you weaken the definition between what a node is and what an interface is and by doing so you might screw with the routing behavior.

I'm not sure if you read my previous statement, before you wrote that, but that is exactly what the FIB is for...

Does this mean we should populate the fib then with default routes when adding addresses to the interface? This won't work anymore if we do not compile the fib into the binary.

Yes (that's what Linux is doing in the background too btw afaik). If you do have multiple interfaces it does not make much sense to have no FIB IMHO.

Otherwise you weaken the definition between what a node is and what an interface is and by doing so you might screw with the routing behavior.

Why? If RIOT receives any IP packet and it is the final destination for that packet and it is a router, it should deliver that packet (which it does). But then, if RIOT sends a packet to the original sender, it should also be able to figure out the way back.

IMHO making a difference between "fib" and "we save the prefix length with interfaces" doesn't make sense. From a conceptual PoV, they're the same: a table deciding what to use as next hop.

If I look at the diff: what happens if the upper layer wants to explicitly send over a certain interface? IMO the lower layer (ND in this case) should not ignore that.

what happens if the upper layer wants to explicitly send over a certain interface?

Is there a use-case for non-link-local packets? edit I mean, for IPv6 non-link-local packets with a forced egress interface?

Routing metrics for example.

Testing RIOT (at least that is something where I use forced egress interfaces a lot on Linux ;-))

Routing metrics for example.

wouldn't they be part of the routing decision, not an "upper layer request"?

Not sure if I fully understand the trend of the conversation here. There are two problems as far as I can see:

• what to do if there are no instructions from upper layers
• how to process upper layer instructions if any

For the second point, wouldn't that belong in another PR anyway?
For the first point, there is no "standard" way to implement this from the IP protocols specs PoV, since this is purely internal node logic (out of scopes for network protocol specs). The only thing we should make sure is that a node can answer queries to any non-link-local address it possesses, whatever interface it came from.

After today's discussion: can we close this?

Can someone summarize the outcome of this meeting regarding this issue here?

Here is the idea of the protocol (@cgundogan @emmanuelsearch @haukepetersen @kaspar030 @thomaseichinger please correct me if there is something wrong about that):

• Some machine in the network joins a well-known link-local multicast address (not ff02::1) and starts a configuration server listening for packets from that group
• Border router sends out UDP packet to the well-known multicast address asking for a prefix or multiple prefixes (in case it wants to configure more than one LoWPAN interface e.g.) and listing its prefixes [edit: WPAN interfaces]
• configuration server replies with a prefix<->interface mapping
• border router configures its interfaces accordingly

With this no NDP hacks as this one are necessary.

Maybe I misunderstand something. I thought this issue was about the following:

• 6LBR has 2 interfaces (IF0 connected to the Internet and IF1 connected to the LoWPAN
• a host connected to 6LBR over IF0 tries to reach the 6LBR using an address that is configured to IF1
• currently 6LBR won't respond to this address, this PR is about to change this.

Yes but only because the FIB wasn't configured properly. The procedure above would update FIB and prefix list and take care that the situation you described doesn't happen anymore. The solution offered by this PR is more of a hack than a solution for this.

Sounds somewhat strange to me. Why do we need an UDP based protocol for that. Can't we configure locally on the node if it should respond to an address that is configured to any interfaces vs. only to addresses configured to the receiving interface?

Yes but only because the FIB wasn't configured properly.

This is not correct. Currently, it is impossible to say "prefix A is on link on interface X" other by setting an address on that interface, which implicitly adds it to the prefix list. The issue from this PR stands.

Sounds somewhat strange to me. Why do we need an UDP based protocol for that.

The protocol has nothing to do with the issue here.

Can't we configure locally on the node if it should respond to an address that is configured to any interfaces vs. only to addresses configured to the receiving interface?

A node not answering to global addresses, no matter on which interface they're configured, is a bug (or an administrativly desired cut in otherwise expected connectivity). While as a next step that should be configurable, the current issue is that RIOT sends the reply over the link the original target is configured on, and not over the link that has the target address as on-link prefix.

A node not answering to global addresses, no matter on which interface they're configured, is a bug (or an administrativly desired cut in otherwise expected connectivity).

This shouldn't be fixed in the forwarding routine, but in the destination address check.

I think we can either hardcode this (always answer to addresses configured to any interface) or setup an according forwarding rule (which is IMO conceptually more correct). I think both solutions have pros and cons.

Yes, but this doesn't setup forwarding rules, it by-passes them.

That's why I don't ACK. ;)

Consider #4738 as an alternative

I think we can either hardcode this (always answer to addresses configured to any interface) or setup an according forwarding rule (which is IMO conceptually more correct).

This doesn't need a special forwarding rule. RIOT already answers to the ping.
But in our split prefix list / fib setup, the prefix list is RIOT's knowledge base on where to send a packet, e.g., part of the "forwarding" logic. But if RIOT replies to a packet (or the packet has an "iface" set), it only considers prefix list entries of that interface. And if ICMP replies, it sets that iface to the interface of the incoming interface (I think). So without this PR, RIOT skips part or the forwarding rules. edit additionally, it selects a completly bogus outgoing interface for it's reply.

@kaspar030 this has nothing to do with forwarding, but address assignment.

(or am I missing something?)

Hm, not forwarding, but next-hop determination. When answering, RIOT doesn't consider the prefix assigned to it's ethos interface, then selects the 6lo for sending the reply. (possibly because of internal_default_router).

I thought in your scenario the ethos interface doesn't even have a (non-link-local) prefix...

Anyway after this long discussion and now that I read the algorithm again, I might think that you are right regarding next-hop determination. The "I ping a node, but it does not answer for the non-receiving interface"-problem you hinted at earlier isn't fixed by this however and we still should consider #4738.

additionally, it selects a completly bogus outgoing interface for it's reply.

Can you elaborate?

echo request comes in on interface 5, gnrc decides it is for us, re-queues the packet, it arrives on interface 6, icmp handles it, tries to send the echo reply (with "iface 6" set, _next_hop_l2addr doesn't consider interface 5 when looking up target as interface is set, no next hop is found, internal_default_router finds a router, reply is sent there). Everything in brackets is theory.

I can't follow, you're too fast for an old man. Let's break it down:

1. echo request comes in on interface 5
2. gnrc decides it is for us
3. re-queues the packet
4. it arrives on interface 6
5. icmp handles it
6. tries to send the echo reply
7. and 2. are okay.

ad 3. Why would it be re-queued?

ad 4. It arrives on another interface now? Why? Who sent it?

Solved by #4738.