Date: Tue, 7 Jul 2020 14:03:52 +0200 From: Niclas Zeising <zeising+freebsd@daemonic.se> To: Hiroki Sato <hrs@FreeBSD.org> Cc: net@FreeBSD.org Subject: Re: ndp and routers with link-local addresses Message-ID: <f66cfbcd-6cd8-c63f-2b76-cd02025c9892@daemonic.se> In-Reply-To: <20200707.195754.1353021909850880836.hrs@FreeBSD.org> References: <f0e663d9-99e5-2166-a83e-30a57b534850@daemonic.se> <20200707.195754.1353021909850880836.hrs@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-07-07 12:57, Hiroki Sato wrote: > Niclas Zeising <zeising+freebsd@daemonic.se> wrote > in <f0e663d9-99e5-2166-a83e-30a57b534850@daemonic.se>: > > ze> However, if the interface on the router facing the client network only > ze> has a link-local (and no global unicast) address, NDP neighbor > ze> discovery breaks. > > This is related to the prefix discovery, not neighbor discovery > (L2-L3 address resolution) in NDP. In the current implementation, > just adding an interface route does not mean that the prefix is > on-link. Adding the prefix (i.e. an address) on the interface or > receiving an Router Advertisement message with a Prefix Information > Option on the interface are the only ways to update the prefix list. What is needed to mark a prefix as being on-link? What does the relevant RFCs say? (I haven't looked myself, to be honest). > > Neighbor discovery does not work for communications to an address > within the prefix not on the prefix list because the prefix is not > considered as directly-connected. > > This restriction can be relaxed technically by adding the prefix to > the list when a route for it is installed (also discussed in > https://reviews.freebsd.org/D23695, and there are experimental > patches to implement it). However, adding an address within the > prefix is the safest option. Is there any specific reason why using > the interface route for a directly-connected prefix, instead of > adding an address on the interface? I am interested in this use > case. On networks where SLAAC is in use, there is no need for a global address on the router interface facing the clients, since all communication with the router is done on the link-local address, and clients has the router link-local address as their next hop. In my case, nothing is preventing me from adding an address in the correct network on the interface, and getting this to work. I was just surprised it didn't work without a global unicast address, since it works on Linux, and both information I've read about the topic, as well as people I've talked to, say that it should be possible to only have a link-local address on the router. This has more to do with interoperability, and conformance with other IPv6 implementations (the one in Linux). I haven't tested other Routers, such as Cisco or Juniper, though. > > Theoretically, a router can always have Subnet-Router anycast address > on each interface and it works as an on-link prefix information. For > this reason, KAME implementation does not support properly to use > interface route for directly-connected prefixes. I'm not sure that I understand this part. I know what a subnet router anycast address is, and how to assign it, and I know what anycast is. But I'm not sure I understand the comment about the KAME implementation not properly supporting interface routes for directly connected prefixes. Regards -- Niclas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f66cfbcd-6cd8-c63f-2b76-cd02025c9892>