it appears that you are experimenting with a special case.
Normally, a sending node decides on the outgoing interface based on the destination IP prefix. If you don't have a more specific routing entry, the default IF is correctly chosen in your case.
After the interface is selected, the source needs to decide on the Layer2 framing. Most link-layer technologies use an addressing (802.3/11, 15.4 ...) and the MAC address is acquired via ND. In your case, you mention SLIP. A serial line interface does not use L2 addresses and does not need ND.
Hi Thomas,
Thank you for your answer. OK I think I understand what you mean, but
is this really the correct behavior?
It was certainly unexpected to me to have the packets go out the
default route instead of on the interface with the configured prefix.
I will try to elaborate:
I have a prefix 2001:db8::/64 configured for the wireless interface.
When I run ping6 2001:db8::1234 from the shell on the RIOT node, I
expect the system to first attempt to find 2001:db8::1234 on the
interface which has been configured for that prefix, instead of
immediately falling back and taking the default route when the
destination does not already exist in the NIB neighbor table.
Thank you for your answer. OK I think I understand what you mean, but
is this really the correct behavior?
It was certainly unexpected to me to have the packets go out the
default route instead of on the interface with the configured prefix.
I will try to elaborate:
I have a prefix 2001:db8::/64 configured for the wireless interface.
When I run ping6 2001:db8::1234 from the shell on the RIOT node, I
expect the system to first attempt to find 2001:db8::1234 on the
interface which has been configured for that prefix, instead of
immediately falling back and taking the default route when the
destination does not already exist in the NIB neighbor table.
I would expect so, too: This should be the correct routing decision and default routing is wrong. Sorry, I didn't see that in your previous mail.
I'm not sure such fallback makes sense at all, if a specific, globally routable prefix is configured. If 2001:db8::1234 is not reachable via 2001:db8::/64, a 'destination unreachable' should be triggered.
at first glance this seems to be indeed a bug. If the prefix 2001:db8::/64 is configured for one interface, this should be hint enough for the NDP to use that interface to multicast the NS there. I’ll investigate that.
However, I have to add that RFC 6775 (which applies for the border router) makes the neighbor discovery very destination-oriented (so typically NS are only send upstream performing address registration with the upstream router). So that might also be a legitimate behavior, as downstream nodes should usually be registered via Address registration with the border router or at least a route should be configured to the downstream node with a routing protocol of your choosing ;-).
at first glance this seems to be indeed a bug. If the prefix `2001:db8::/64` is configured for one interface, this should be hint enough for the NDP to use that interface to multicast the NS there. I'll investigate that.
However, I have to add that RFC 6775 (which applies for the border router) makes the neighbor discovery very destination-oriented (so typically NS are only send upstream performing address registration with the upstream router). So that might also be a legitimate behavior, as downstream nodes should usually be registered via Address registration with the border router or at least a route should be configured to the downstream node with a routing protocol of your choosing ;-).
Yes, but forwarding to the default upstream should be a failure in this case: The packet would then come back from upstream in a loop.
at first glance this seems to be indeed a bug. If the prefix
2001:db8::/64 is configured for one interface, this should be hint
enough for the NDP to use that interface to multicast the NS there. I’ll
investigate that.
However, I have to add that RFC 6775 (which applies for the border
router) makes the neighbor discovery very destination-oriented (so
typically NS are only send upstream performing address registration with
the upstream router). So that might also be a legitimate behavior, as
downstream nodes should usually be registered via Address registration
with the border router or at least a route should be configured to the
downstream node with a routing protocol of your choosing ;-).
Yes, but forwarding to the default upstream should be a failure in this
case: The packet would then come back from upstream in a loop.
Yes indeed. Forwarding to the default route is definitely an error.