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