From nobody Wed May 7 22:13:24 2025 X-Original-To: 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 4Zt8fZ6fz3z5vNBV for ; Wed, 07 May 2025 22:13:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zt8fZ5Gpwz3Lfn for ; Wed, 07 May 2025 22:13:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746656006; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ot0K8+Q+/tF3sVZKoNjH+0Cr/5vLxO94+u5pSNhQZ5o=; b=QnFAwLZuQJ2UmbDDEZ28mz9eTq2bRhQVYxTrla4qqTLXuNAkuZJTzvAe6PnAEZWo7brgCp 0YQ1ZzwfbyvoqNyKwOka0HJMnOFNLw5fImMr+negIqI+ZfAlyuAY7w084MEb3GZY/soKdj gBVFrj+/uQzdJ8qcbhrZ6Q7LgxuKUmstzml7CTxn96eCCqVdWEazqnkCFXfkdHAo9DS2Ye jFMFJckfUDuQ5I43HrF/OVLUVz8ZzgfNYpOJ77U1IMl2IIz1zZpp+KJN7/wkHxtqXHS9ZM JLEz6VA1E+bb4kYZszUjdQu+1HxK5wGWksZfkR4KQavi36oklIGhJeyAjR3evQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746656006; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ot0K8+Q+/tF3sVZKoNjH+0Cr/5vLxO94+u5pSNhQZ5o=; b=PBmVyZYLcv93Edrn+ymWmrK8h7dIFBbUa1DBZ4wqCQ9dzxJ5MTmLeo5NeQVwuU0rc3P2Vf zmdBy1EEvue8pzVJ4ON5nZDm118cly2lj/Deug39vltKF9Jd+nfXNITISG3y+GQQY0Eovs Cikz7sFUeZBDS+vTRFbqDIIuPfNCkhgcc01w8KfrdJUIM9gNZBQam0VoAoZFHojwKkLZVa qxr01UjQ/70EOb9w75gwkYk0iRdm5Al7DzUk/o4JiYZo4XtkJt4vY5UuVzDjJadGv1L1+Z K2SmkdLx8jiSYqbPgGV+6bH9W6lybr/O4RUNNfbFvgTqbbGWFlwdY6Yis7LRDg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1746656006; a=rsa-sha256; cv=none; b=MAwNHX/j7zeaixRP2NIjpGRrT4LEn/A4KyfbdFeWxfnQ6xJXFg4zVCm2eDfYVXon+2CObG fePs0/2+OFpkHMGyhGIyI9tbuh7SkNpVQGjdb+5qasRUgeVJ1oc4eTpDBsj2Sk6yKaJZ+8 z7OQFw1LlpR4uCuWBH0BtVOMTiI3I7+x3j6tIuLx+xmIrjzBKQG/7U/asx5x8JVnvthuHY Tr9iIrYoV03uYgn5XYJML9rhqn7ceTAUhfgvUO+zgoVzqh5CHqV5vF+musixFiZUrcNDkh qvIxocBWgyXGJjBLyzLPbIAUmt2WkJz95cz9fnr1C3mhywxVJapJBQ7BlG7g2g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Zt8fZ4jC0zp6Y for ; Wed, 07 May 2025 22:13:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 547MDQx2055213 for ; Wed, 7 May 2025 22:13:26 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 547MDQio055212 for net@FreeBSD.org; Wed, 7 May 2025 22:13:26 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 280390] NPTv6 not working Date: Wed, 07 May 2025 22:13:24 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 13.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tatsuki_makino@hotmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ipfw@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D280390 --- Comment #24 from Tatsuki Makino --- (In reply to Andrey V. Elsukov from comment #22 & #23) > I still doesn't understand your problem. Me too :) As a result of being stingy with the money I pay upstream (removing services like phone and cable TV), the upstream provider only gives me a /64 prefix = :) In this case, the terminal connected to the downstream interface cannot communicate with the upstream unless the downstream interface belongs to the same bridge as the upstream interface. By using NPTv6, it is possible to make it a layer 3 packet forward. However, since the upstream prefix is already /64, there can only be one /64 prefix available for use downstream. There are two interfaces downstream. It seems that bridging those two interfaces would work, but since it operat= es in a dual stack with IPv4 and dhcpd is also running, it causes issues with = the operation. It was also tried to set a prefix length of /64+x on the interface when receiving a /64 RA from upstream via another patch. This method itself works pleasantly on FreeBSD. However, everything gets ruined because Andr=E2=97=8Bid refuses to operate = with a prefix longer than /64. Wind=E2=97=8Bws also requires that DHCPv6 is running when the prefix is lon= ger than /64. And the keep-state rule was introduced to identify which prefix to choose w= hen translating two or more downstream prefixes to the address of one upstream prefix and then returning it. Since NPTv6 has the same prefix length before and after translation, it see= ms that routing cannot return to the original interface, and this method must = be used. I was considering what to do about the part you pointed out, as the dynamic rules for ICMPv6 require that the addresses on both ends match exactly. As you can see in my patch, normal ICMPv6 packets should have a port value = of 0, so I feel that having a port that is not 0 can be interpreted differentl= y :) In any case, there is no problem with NPTv6 itself. It seems that a person like me is just trying to use it in a strange way :) --=20 You are receiving this mail because: You are on the CC list for the bug.=