On 2020-07-07 12:57, Hiroki Sato wrote:
Niclas Zeising <zeising+free...@daemonic.se> wrote
in <f0e663d9-99e5-2166-a83e-30a57b534...@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
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"