From nobody Mon Oct 6 17:59:48 2025 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 4cgRrT5MdJz6BGj2 for ; Mon, 06 Oct 2025 18:00:25 +0000 (UTC) (envelope-from cross+freebsd@relay.distal.com) Received: from relay.wiredblade.com (relay.wiredblade.com [168.235.105.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cgRrT2P0zz40kc for ; Mon, 06 Oct 2025 18:00:25 +0000 (UTC) (envelope-from cross+freebsd@relay.distal.com) Authentication-Results: mx1.freebsd.org; none dkim-signature: v=1; a=rsa-sha256; d=relay.distal.com; s=mail; c=relaxed/relaxed; q=dns/txt; h=From:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References; bh=xpkwaZZDe8z4Q7fPlOya40hlxV9lriMVIHzC4vrZ1H0=; b=kd5NNrMVmn//nXrFOyjH69MFu+GbMe4ArNzr+41WFEVI7rEjTuot1QRWeBPfj/RYGEXq2OkRUafwVBaxFB/uRHher9iw/Fl468DtpPms0g9hG8+7pY1ajW0D49smEZx39J2toTqhXQ49Pyst3X2vr4Cn2TGXCA5qbngsBrckvPAQ9OmmPrP4UkbDNPgocdzasMJ2mcQ9PnxU9ddMPeGsWC2NEZx2EwUpORBmGkbn8uFrEjGvRJJHyk5zlw QvA33u8QChORDyR6b7jm1YJXWS/znTg48BeMFtkHvDeRAE1zt+60oSyWJRvCmlQKvF8OBEZfJC55nDco+xAQWR5pWTOw== Received: from mail.distal.com (pool-108-45-29-236.washdc.fios.verizon.net [108.45.29.236]) by relay.wiredblade.com with ESMTPSA (version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256) ; Mon, 6 Oct 2025 18:00:20 +0000 Received: from smtpclient.apple ( [2600:4040:2cc8:f620:f141:7f06:f21:8921]) by tristain.distal.com (OpenSMTPD) with ESMTPSA id a2a8194e (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Mon, 6 Oct 2025 14:00:19 -0400 (EDT) Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 16.0 \(3864.100.1.1.5\)) Subject: Re: IPv6 routing, Verizon FiOS, dhcpcd From: Chris Ross In-Reply-To: Date: Mon, 6 Oct 2025 13:59:48 -0400 Cc: freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A0A976D-EB8A-4ABF-B216-3CB6358C2559@distal.com> To: Tom Pusateri X-Mailer: Apple Mail (2.3864.100.1.1.5) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:3842, ipnet:168.235.104.0/22, country:US]; TAGGED_FROM(0.00)[freebsd] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cgRrT2P0zz40kc > On Oct 6, 2025, at 00:34, Tom Pusateri wrote: >=20 > Getting a router advertisement is independent of getting an IA_NA = global address for your upstream interface, however, the provider could = be filtering your router until it gets a DHCPv6 round trip. Understood. Also note that my provider won=E2=80=99t give me an IA_NA, = it is giving me an IA_PD. I tried to get an IA_NA from them when I started playing with this a year ago, they never give one. > Use tcpdump to capture the router advertisements on your upstream = interface. This will show router advertisements and router = solicitations. In my case, they=E2=80=99re sent about every 24 minutes. = A router solicitation would trigger one at restart. I have the RS=E2=80=99s and RA=E2=80=99s. What I am _not_ seeing in = tcpdump is=20 neighbor advertisements in response to my NS=E2=80=99s. At least, when the problem is occurring. I can wait for hours, and I never get an NA for the router I=E2=80=99m NS=E2=80=99ing for. I see now that in my test where I delayed dhcpcd startup, I do get NS back, so that makes sense. But I can=E2=80=99t imagine how when I = start dhcpcd affects whether or not Verizon responds to my NS. > See if you have a default route and try pinging the default IPv6 = route: Yup, I did all of this in my initial testing before I fell back to trying with a spare machine. There is no default route, but even with a config such that dhcpcd sets a default route (it will if I=E2=80=99= ve told it to assign an internal address from the IA_PD allocation, not otherwise) then the next-hop LL is always =E2=80=9C(incomplete)=E2=80=9D = in ndp -an output. > Does this act the same with another DHCPv6 client like KAME dhcp6c = instead of using dhcpcd? I have not tested others. Again, I don=E2=80=99t think it=E2=80=99s a = DHCP thing, The DHCP part is actually working. It=E2=80=99s that something else is Happening at an addressing level. Your comments about the ONT doing something make me wonder if it could be that, but I=E2=80=99m not sure why that would be different = depending on delaying starting dhcpcd, or what I can do to avoid it. Though I guess if I could confirm that, then at least I would know it=E2=80=99s a problem unique to me. Thanks. - Chris