Date: Wed, 08 Jul 2020 18:35:51 +0900 (JST) From: Hiroki Sato <hrs@FreeBSD.org> To: zeising+freebsd@daemonic.se Cc: net@FreeBSD.org Subject: Re: ndp and routers with link-local addresses Message-ID: <20200708.183551.294929323782099254.hrs@FreeBSD.org> In-Reply-To: <f66cfbcd-6cd8-c63f-2b76-cd02025c9892@daemonic.se> References: <f0e663d9-99e5-2166-a83e-30a57b534850@daemonic.se> <20200707.195754.1353021909850880836.hrs@FreeBSD.org> <f66cfbcd-6cd8-c63f-2b76-cd02025c9892@daemonic.se>
next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Wed_Jul__8_18_35_51_2020_692)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Niclas Zeising <zeising+freebsd@daemonic.se> wrote in <f66cfbcd-6cd8-c63f-2b76-cd02025c9892@daemonic.se>: ze> On 2020-07-07 12:57, Hiroki Sato wrote: ze> > Niclas Zeising <zeising+freebsd@daemonic.se> wrote ze> > in <f0e663d9-99e5-2166-a83e-30a57b534850@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 ----Security_Multipart(Wed_Jul__8_18_35_51_2020_692)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iMgEABMKAC4WIQRsDSNTJ8+Ax5Ae/dLbsH3Gbx9zfwUCXwWTdxAcaHJzQGZyZWVi c2Qub3JnAAoJENuwfcZvH3N/G3ACB22XWmTIGgFIKpeJp6Gd3+8g+fayCau09k3Q pyFKp4lIwk9e6/yJqno8u4Mb9zQjkfdjirfm+zzH/XkbxDFymA4iAgjlaURonGnT fcxmTqAFoS5Op8oaBcfBNEr7ihaAz4ZOJVchYKypxzNpjGsKWEmi5MxPp7UXGrmQ pyTR4Jf9ZzqBxA== =gSJg -----END PGP SIGNATURE----- ----Security_Multipart(Wed_Jul__8_18_35_51_2020_692)----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200708.183551.294929323782099254.hrs>