Hi Thomas, Am Mo., 17. Dez. 2018 um 11:57 Uhr schrieb Thomas C. Schmidt < t.schm...@haw-hamburg.de>:
> 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. > Yes indeed. Forwarding to the default route is definitely an error. > > 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 >
_______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
