ndp and routers with link-local addresses
Hiroki Sato
hrs at FreeBSD.org
Tue Jul 7 10:58:29 UTC 2020
Niclas Zeising <zeising+freebsd at daemonic.se> wrote
in <f0e663d9-99e5-2166-a83e-30a57b534850 at 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.
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.
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.
-- Hiroki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 342 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20200707/2559f318/attachment.sig>
More information about the freebsd-net
mailing list