Hi Martine,
On 17/12/2018 11:17, Martine Lenders wrote:
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.
Cheers,
Thomas
Am Mo., 17. Dez. 2018 um 10:13 Uhr schrieb Thomas C. Schmidt
<t.schm...@haw-hamburg.de <mailto:t.schm...@haw-hamburg.de>>:
Hi Joakim,
On 17/12/2018 09:37, Joakim Nohlgård wrote:
> 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.
Cheers,
thomas
> On Mon, Dec 17, 2018 at 9:11 AM Thomas C. Schmidt
> <t.schm...@haw-hamburg.de <mailto:t.schm...@haw-hamburg.de>> wrote:
>>
>> Hi Joakim,
>>
>> 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.
>>
>> Best,
>> Thomas
>>
>> On 17/12/2018 08:59, Joakim Nohlgård wrote:
>>> Hi developers,
>>> When using the shell on the gnrc_border_router application
trying to
>>> send to an unknown address with its designated prefix, the
application
>>> does not send any neighbor solicitations on the wireless network.
>>> When I type ping6 2001:db8::1234 I expected that a neighbor
>>> solicitation query to go out on the interface that has been
configured
>>> with the routing destination for 2001:db8::/64, but wireshark shows
>>> that nothing is sent on the wireless, but instead the ICMPv6
packet is
>>> sent immediately over the slip/ethos interface, which is
configured as
>>> the default route.
>>>
>>> Is this behavior correct or is this a routing bug?
>>>
>>> Configurations:
>>>> ifconfig
>>> Iface 6 HWaddr: 02:DA:F1:03:BC:48
>>> MTU:1500 HL:64 RTR
>>> RTR_ADV Source address length: 6
>>> Link type: wired
>>> inet6 addr: fe80::da:f1ff:fe03:bc48 scope: local
TNT[1]
>>> inet6 addr: fe80::2 scope: local VAL
>>> inet6 group: ff02::2
>>> inet6 group: ff02::1
>>> inet6 group: ff02::1:ff03:bc48
>>> inet6 group: ff02::1:ff00:2
>>>
>>> Iface 7 Channel: 26 Page: 0 NID: 0x23
>>> Long HWaddr: 23:31:53:29:36:B7:6E:5A
>>> TX-Power: 0dBm State: IDLE max. Retrans.: 3
CSMA Retries: 4
>>> ACK_REQ CSMA MTU:1280 HL:64 RTR
>>> RTR_ADV IPHC
>>> Source address length: 8
>>> Link type: wireless
>>> inet6 addr: fe80::2131:5329:36b7:6e5a scope:
local VAL
>>> inet6 addr: 2001:db8::2131:5329:36b7:6e5a scope:
global VAL
>>> inet6 group: ff02::2
>>> inet6 group: ff02::1
>>> inet6 group: ff02::1:ffb7:6e5a
>>> routing:
>>>> nib route
>>> 2001:db8::/64 dev #7
>>> default* via fe80::1 dev #6
>>>
>>> Best regards,
>>> Joakim
>>> _______________________________________________
>>> devel mailing list
>>> devel@riot-os.org <mailto:devel@riot-os.org>
>>> https://lists.riot-os.org/mailman/listinfo/devel
>>>
>>
>> --
>>
>> Prof. Dr. Thomas C. Schmidt
>> ° Hamburg University of Applied Sciences
Berliner Tor 7 °
>> ° Dept. Informatik, Internet Technologies Group 20099 Hamburg,
Germany °
>> ° http://inet.haw-hamburg.de/members/schmidt Fon:
+49-40-42875-8452 °
>>
>> _______________________________________________
>> devel mailing list
>> devel@riot-os.org <mailto:devel@riot-os.org>
>> https://lists.riot-os.org/mailman/listinfo/devel
> _______________________________________________
> devel mailing list
> devel@riot-os.org <mailto:devel@riot-os.org>
> https://lists.riot-os.org/mailman/listinfo/devel
>
--
Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences Berliner
Tor 7 °
° Dept. Informatik, Internet Technologies Group 20099 Hamburg,
Germany °
° http://inet.haw-hamburg.de/members/schmidt Fon:
+49-40-42875-8452 °
_______________________________________________
devel mailing list
devel@riot-os.org <mailto:devel@riot-os.org>
https://lists.riot-os.org/mailman/listinfo/devel
--
Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany °
° http://inet.haw-hamburg.de/members/schmidt Fon: +49-40-42875-8452 °
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
