From nobody Wed Jul 17 06:36:35 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WP5nN6y7fz5Qff0 for ; Wed, 17 Jul 2024 06:36:40 +0000 (UTC) (envelope-from roy@marples.name) Received: from sender-of-o57.zoho.eu (sender-of-o57.zoho.eu [136.143.169.57]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WP5nN1r2wz45xw; Wed, 17 Jul 2024 06:36:39 +0000 (UTC) (envelope-from roy@marples.name) Authentication-Results: mx1.freebsd.org; none ARC-Seal: i=1; a=rsa-sha256; t=1721198197; cv=none; d=zohomail.eu; s=zohoarc; b=evW0D8utAlO6xJ7v96JjF3z/A8T3LqgFkhOywKtjYIiqRwK97d6o9tkTe/+nFphO7XZZb1HMUnt+QRDBUWvcTQ/MCNPHAFu2rXVStrXG7J57uiSy+8E/8JybdDMSUskG1d4mRt3+r6WaeuY4hIdCxzY+SCvEpFZass101I2fMNo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1721198197; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=M/V8HAnEP6uVTDILppkFJhqL27CZdTP4AzgNmc1MsrQ=; b=WMZS+eTmn2icP53btS6xrtW0Iw00RHpqNz3SFtWsv8S/QgWjRrcCkRf4ZMg3uA5iGpse3IhkOZoFZo419r7BYQfecw/s/WH7cl7eadzPgwLuK5OdrKzhCNF3KtxsVdm1klWUwOCyJwoUo3cU63QgJnD62+gHBZh41t9tPAe29ho= ARC-Authentication-Results: i=1; mx.zohomail.eu; dkim=pass header.i=marples.name; spf=pass smtp.mailfrom=roy@marples.name; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1721198197; s=zmail; d=marples.name; i=roy@marples.name; h=Date:Date:From:From:To:To:Cc:Cc:Message-ID:In-Reply-To:References:Subject:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=M/V8HAnEP6uVTDILppkFJhqL27CZdTP4AzgNmc1MsrQ=; b=ML0MaFR1jQ4WVberpgsLNTN4FBVksXrXvzsjF21P6ZP7kI4Fs50TDUtPi88u8SJL t0751nZdDe5adg+Rs1D+WMp+t8dQi5wPrG6HZBD8nYcybSF4jbiHnFONi7d4WlJZWaG vgGfajhl8AuYVNuzkXBLdxTQdfravJPmXhBMrAuw= Received: from mail.zoho.eu by mx.zoho.eu with SMTP id 1721198195159961.6384912931234; Wed, 17 Jul 2024 08:36:35 +0200 (CEST) Date: Wed, 17 Jul 2024 07:36:35 +0100 From: Roy Marples To: "Mark Johnston" Cc: "freebsd-net" Message-ID: <190bf6831ac.b8c8bcf41215199.2223628794184357959@marples.name> In-Reply-To: References: Subject: Re: flushing default router list upon inet6 route flush List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Importance: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:41913, ipnet:136.143.168.0/23, country:CH] X-Rspamd-Queue-Id: 4WP5nN1r2wz45xw Hi Mark ---- On Tue, 16 Jul 2024 21:04:27 +0100 Mark Johnston wrote --- > Hello, > > When IPv6 SLAAC is configured for an interface, the kernel will update > its default router list upon receipt of a router advertisement. In so > doing it may install a default route; in the kernel this happens in > defrouter_addreq(). > > If one uses "route flush" or "service routing restart" to reset the > routing tables, the default router list is not purged, so a subsequent > RA from the original default router does not update the list, and so > does not re-create the default route, even if one re-runs rtsol(8). > > This appears to be a bug, but I'm not sure where best to fix it. Should > "service routing restart" invoke "ndp -R" to flush the default router > list? Should route(8) handle this as part of a flush command? Or > something else? rc.d/rtsold should probably be fixed, but it also really the wrong solutuion. Kernel handling of RA cannot be influenced very well from userland and as you see, this affects the default route. An alternative solution would be to use dhcpcd(8) from ports to manage RA instead of the kernel. It can also handle DHCP, replacing dhclient(8) but that's up to you. You might want to add `noipv4` to `/etc/dhcpcd.conf` until you're happy changing fully over. dhcpcd will intelligently manage all the routes. You can purge everything (including addresses and DNS) with `dhcpcd -k` and restore them with `dhcpcd -n`. Good luck! Roy