From owner-freebsd-net@freebsd.org Tue Jul 7 10:58:29 2020 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CADB235E606 for ; Tue, 7 Jul 2020 10:58:29 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4B1KDP55Jxz4QrG for ; Tue, 7 Jul 2020 10:58:29 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: by mailman.nyi.freebsd.org (Postfix) id AEABE35E605; Tue, 7 Jul 2020 10:58:29 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AE71135E4A1 for ; Tue, 7 Jul 2020 10:58:29 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B1KDP4CvXz4Qnl; Tue, 7 Jul 2020 10:58:29 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from localhost (unknown [IPv6:2400:4051:a743:3c00:16:ceff:fe34:2700]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: hrs) by smtp.freebsd.org (Postfix) with ESMTPSA id C80612BF54; Tue, 7 Jul 2020 10:58:28 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Date: Tue, 07 Jul 2020 19:57:54 +0900 (JST) Message-Id: <20200707.195754.1353021909850880836.hrs@FreeBSD.org> To: zeising+freebsd@daemonic.se Cc: net@FreeBSD.org Subject: Re: ndp and routers with link-local addresses From: Hiroki Sato In-Reply-To: References: X-Old-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-PGPkey-fingerprint: 6C0D 2353 27CF 80C7 901E FDD2 DBB0 7DC6 6F1F 737F X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="--Security_Multipart(Tue_Jul__7_19_57_54_2020_166)--" Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 10:58:29 -0000 ----Security_Multipart(Tue_Jul__7_19_57_54_2020_166)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Niclas Zeising wrote in : 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 ----Security_Multipart(Tue_Jul__7_19_57_54_2020_166)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iMoEABMKAC4WIQRsDSNTJ8+Ax5Ae/dLbsH3Gbx9zfwUCXwRVMhAcaHJzQGZyZWVi c2Qub3JnAAoJENuwfcZvH3N/+WoCCQFPEp/4Y9Yhg4CbAeghd4XV2uOCRp15dY2C RLAnQmvoPp886EMtlANdlz+EGGICb1mdxx3MrkEpYZ/fT6sSLY76cgIJAabh8qZj PzKvxDQSth5aTO6lYCYfs+H1exs2YzY9j0HGLTicT3RJ0MJY1VNktH/re4dGmbxW n9gGTiyMv1oiur8l =Zvxm -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Jul__7_19_57_54_2020_166)----