ndp and routers with link-local addresses

[Hiroki Sato]

Niclas Zeising <zeising+freebsd at daemonic.se> wrote
  in <f66cfbcd-6cd8-c63f-2b76-cd02025c9892 at daemonic.se>:

ze> On 2020-07-07 12:57, Hiroki Sato wrote:
ze> > Niclas Zeising <zeising+freebsd at daemonic.se> wrote
ze> >    in <f0e663d9-99e5-2166-a83e-30a57b534850 at daemonic.se>:
ze> > ze> However, if the interface on the router facing the client network
ze> > only
ze> > ze> has a link-local (and no global unicast) address, NDP neighbor
ze> > ze> discovery breaks.
ze> >   This is related to the prefix discovery, not neighbor discovery
ze> >   (L2-L3 address resolution) in NDP.  In the current implementation,
ze> >   just adding an interface route does not mean that the prefix is
ze> >   on-link.  Adding the prefix (i.e. an address) on the interface or
ze> >   receiving an Router Advertisement message with a Prefix Information
ze> >   Option on the interface are the only ways to update the prefix list.
ze>
ze> What is needed to mark a prefix as being on-link?

 On FreeBSD, they are basically either 1) an address configured on an
 interface or 2) receiving RA from a router on the same link with
 prefix information.

ze> What does the relevant RFCs say? (I haven't looked myself, to be
ze> honest).

 RFC 5942 is the most relevant RFC.  Note that the current FreeBSD
 implementation is based on older discussions even before RFC 4861, so
 the on-link assumption is a bit relaxed compared to RFC 5942.

ze> On networks where SLAAC is in use, there is no need for a global
ze> address on the router interface facing the clients, since all
ze> communication with the router is done on the link-local address, and
ze> clients has the router link-local address as their next hop.
ze>
ze> In my case, nothing is preventing me from adding an address in the
ze> correct network on the interface, and getting this to work.  I was
ze> just surprised it didn't work without a global unicast address, since
ze> it works on Linux, and both information I've read about the topic, as
ze> well as people I've talked to, say that it should be possible to only
ze> have a link-local address on the router.

 An IPv6 router works without GUA even on FreeBSD.  However, the final
 hop of the packet forwarding depends on the on-link information on the
 router.  Linux recognizes a routing table entry as source of on-link
 information.  FreeBSD does not.  This is the primary difference.

 RFC 5942 says making a prefix on-link may be done by "explicit manual
 configuration".  FreeBSD defines an address configuration as its
 manual prefix configuration.  Adding a routing table entry might be
 considered as an additional manual configuration, but if doing so,
 communications whose source is fe80::/16 and destination is a GUA
 will happen when it is originated from the router itself.  Strictly
 speaking it is not against the specification, a unicast communication
 between two addresses which have a different scope from each other is
 not desirable, and at least an unexpected behavior in the current
 implementation.  We need to carefully check if it works in our
 network stack before enabling it.

ze> This has more to do with interoperability, and conformance with other
ze> IPv6 implementations (the one in Linux).  I haven't tested other
ze> Routers, such as Cisco or Juniper, though.

 Manual configuration of the prefix list is up to the platform.  It is
 not something determined by communication with another nodes, so I do
 not think this is an interoperability issue of the protocol.

ze> >   Theoretically, a router can always have Subnet-Router anycast address
ze> >   on each interface and it works as an on-link prefix information.  For
ze> >   this reason, KAME implementation does not support properly to use
ze> >   interface route for directly-connected prefixes.
ze>
ze> I'm not sure that I understand this part.  I know what a subnet router
ze> anycast address is, and how to assign it, and I know what anycast
ze> is. But I'm not sure I understand the comment about the KAME
ze> implementation not properly supporting interface routes for directly
ze> connected prefixes.

 On all interfaces of an IPv6 router, Subnet-Router anycast address of
 prefixes on the connected links must be configured, according to RFC
 4291.  An interface with only LLAs does not happen.  This means that
 the prefix list is configured properly by these addresses.

 Most of people do not configure this anycast address in practice,
 however.  So I used the word "theoretically".  Configuring an GUA
 within the prefix also works and more intuitive.

 As explained earlier, it is an odd situation that there is an
 interface route with a prefix and the prefix list does not have the
 prefix as on-link.  The odd behaviors came from it because IPv6
 network stack got confused.

-- 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/20200708/1da2d0e5/attachment.sig>