FIOS - getting /56 PD via DHCP6 but no V6 is assigned to WAN

JKnott

You can set up monitors for IPv4 and IPv6 separately. You can disable gateway monitoring on the same page as where you set up the monitor address. However, it only actually does something if you have more than one WAN connection and also provides status info on the dashboard. So, you don't really need it.

pilot45

@luckman212 I'm not at your level of understanding. However, I'm also in nyc and had FIOS turn on IPv6 a week ago. Despite not getting a WAN GUA, dpinger automatically began pinging the fe80::de38... gateway and is reporting "Online" with no adjustments from me.

I am NOT disabling "hardware checksum offloading" though. And under Interfaces>WAN>DHCP6 Client Config, I have "request only an IPv6 prefix" checked. In system>routing>gateways I have "Monitor IP" blank for both WAN_DHCP and WAN_DHCP6.

Everything has been perfect so far. I'm also on 22.05. Protectli FW4B.

Screenshot 2022-09-28 173200.png

pilot45

forgot to add to my first reply

Screenshot 2022-09-28 174612.png

luckman212

I am burying my head in the sand on this one for now. Wasted half a day on this and in the end maybe it's just not that important. Hopefully as Verizon finishes their rollout maybe they'll continue improving things.

JKnott

@luckman212

I just noticed something in the help for gateway monitors:

"By default, the gateway monitoring daemon will ping each gateway periodically to monitor latency and packet loss for traffic to the monitored IP address."

I haven't verified this, so perhaps it automagically pings the gateway for the monitor. Perhaps you could remove any address you entered to see what happens. Just run Packet Capture on the WAN port, filtering on the gateway address and ICMP6 to see what turns up. I do know you can't manually enter a link local address, but perhaps when it tries what it knows is the gateway it might work.

JKnott

@pilot45 said in FIOS - getting /56 PD via DHCP6 but no V6 is assigned to WAN:

I have "request only an IPv6 prefix" checked.

Is that setting required for them? If not, try without it. That definitely will prevent pfSense from getting a WAN GUA.

luckman212

@jknott No - that setting is not required. But, I tested it extensively with both modes, it made no difference. VZ ignores the ia-na request completely. It only supplies the delegated prefix.

Dpinger will ping the default gateway if monitor IP is left blank. This has always been the case. The problem there is, very often an ISP outage will not be detected because the first or 2nd hop continue to be "up" even though nothing gets beyond that. So it's generally more useful to specify a public IP farther upstream so outages are detected properly.

What is really needed to fix this is one or both of:

Verizon deciding to respect dhcp6c's ia-na request in the solicit
Upstream code change to dhcp6c to allow it to assign an IP from one of the ia-pd (delegated prefix) subnets to the parent interface itself. Currently, putting that in /var/etc/dhcp6c.conf is rejected as invalid—even though manually assigning the IP with ifconfig works fine.

JKnott

@luckman212 said in FIOS - getting /56 PD via DHCP6 but no V6 is assigned to WAN:

Dpinger will ping the default gateway if monitor IP is left blank. This has always been the case.

I checked mine. When the monitor IP is left blank, I can see the pings go out, but the gateway is not responding. I went back to using an address I obtained by doing a traceroute to Google and taking the first GUA it passed through.

luckman212

@jknott this is veering a little off topic. But, who's your ISP? What kind of CPE/ONT is it? Guessing it's just a case of the near-side equip not allowing pings. In my case my next hop is pingable even on its fe80 IP.

SirSilentBob

@luckman212 you are not alone. Most of us other Vz Fios users have asked or searched for at one point if anyone has a script or something or ideas on how to automate the WAN geting a GUA assigned that will draw from the /56 so we don't have ONLY a link local ipv6 addresson wan. Verizon's own routers seem to have something hardcoded that makes it so that FF::1 is used for the wan. People thought that it was RFC6603 being used, but when the traffic was analyzed at the packet level verizon did not seem to be responding to the RFC6603 prefix exclusion request.

So if you have 2600:4040:ABCD:12/56 as your PD, the the fios router will set 2600:4040:ABCD:12FF::1 as your WAN ipv6 GUA. Basically the fios router just takes the very last of the 256 LAN /64s you have (FF) and dedicates it to the WAN.

If anyone ever comes up with a way to scrip that, then many many fios pfsense users will be greatful, especially me.

Most of the time people suggest using a virtual IP and just setting that ip to something valid within your /56, but even with the ipv6 setting to not release the prefix, power flickers, and other things beyond control can make the PD still change.

If what you did to get a valid GUA on your wan is a script you can share that will update the WAN gua when PD changes occur, could you share it and maybe give a brief setup tutorial please?

Good luck and enjoy ipv6 without a tunnel.

luckman212

@sirsilentbob Good idea. I just whipped this together. Please give it a try and let me know if it works for you. Don't forget to check the box to enable dhcp6 to start in debug mode (see README)

luckman212/assign-gua-from-iapd - GitHub

JKnott

@luckman212

My ISP is Rogers. They provide a Technicolor CGM4141ROG modem, which I assume is a Rogers specific version.

The first hop, which is likely the modem, doesn't show up in traceroute and every address past it is GUA. So yeah, pings are likely blocked.

JKnott

@jknott

I just did some more checking. I have a public IPv4 address and the MAC address for it corresponds to the IPv6 link local address for my IPv6 gateway. However, that MAC address is not listed on the modem, which means it might be the CMTS. The MAC address is 00:17:10:9a:a1:99, which belongs to Casa Systems, a manufacturer of telecom equipment, including CMTS. So, the ping to my IPv4 gateway shows a connection as far as the cable head end.

luckman212

To anyone following this thread:

I pushed a few updates this morning to make the script more robust, add some logging, error checking etc, skipping unnecessary updates etc.

Also added a patch that you can hook in with System Patches to integrate this into /var/etc/dhcp6c.conf so it gets triggered automatically (no need for a cronjob)

SirSilentBob

@luckman212 As I mentioned in the dslr forums where I first saw you post about this, you are awesome and thanks for creating it! Please mention or PM me your paypay so I can throw you a few bucks for your favorite drink.

I have downloaded and installed the shell script, put it in /root and made it executable. Your instructions mention "Make sure the DHCP6 Debug checkbox is enabled at System → Advanced → Networking." I don't have that particular checkbox at that location on my system (2.6.0 CE), however I have it under "DHCP6 Client Configuration" on my Interfaces / WAN page. I have checked it. I rebooted the firewall and success, the WAN has a IPv6 GUA!

The only thing I have is an alert on the top of the dashboard "pfSense has detected a crash report or programming bug. Click here for more information."

Here's the contents of the crash report below. Not sure if this is because I am using CE 2.6.0 but so far the script has worked as far as I can tell. As for if it will detect when the PD changes and update the WAN accordingly with this error, I can't say at this time. Somehow despite the hurricane, I have managed to not loose power so I guess just time will tell on that.

Please let me know if I need to poke around more, ssh in or give more info. Or if it's a benign error that isn't any real concern. Crash report and a clip of the system log file provided below.

Crash report begins.  Anonymous machine information:

amd64
12.3-STABLE
FreeBSD 12.3-STABLE RELENG_2_6_0-n226742-1285d6d205f pfSense

Crash report details:

PHP Errors:
[01-Oct-2022 21:12:22 America/New_York] PHP Fatal error:  Uncaught Error: Call to undefined function create_interface_ipv6_cfgcache() in Command line code:1
Stack trace:
#0 {main}
  thrown in Command line code on line 1



No FreeBSD crash data found.

Here's the info from the patch debug:

"Patch does not apply cleanly (detail)"

/usr/bin/patch --directory='/' -t  --strip '2' -i '/var/patches/6338e3a0e63dd.patch' --check --forward --ignore-whitespace

Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|From a20cd10a34020e09dcdc14882c04dc749d3c6487 Mon Sep 17 00:00:00 2001
|From: luckman212 <1992842+luckman212@users.noreply.github.com>
|Date: Thu, 29 Sep 2022 08:59:11 -0400
|Subject: [PATCH] companion patch for
| https://github.com/luckman212/assign-gua-from-iapd
|
|auto assign GUA when dhcp6c script is called
|---
| src/etc/inc/interfaces.inc | 2 ++
| 1 file changed, 2 insertions(+)
|
|diff --git a/src/etc/inc/interfaces.inc b/src/etc/inc/interfaces.inc
|index a7fe25497eb..630dfb9ccfe 100644
|--- a/src/etc/inc/interfaces.inc
|+++ b/src/etc/inc/interfaces.inc
--------------------------
Patching file etc/inc/interfaces.inc using Plan A...
Ignoring previously applied (or reversed) patch.
Hunk #1 ignored at 4990.
Hunk #2 ignored at 5042.
2 out of 2 hunks ignored while patching etc/inc/interfaces.inc
done

And small clip of log activity:

Oct 1 21:12:22	assign_gua_from_iapd	34083	done, removing lockfile
Oct 1 21:12:22	php	33798	thrown
Oct 1 21:12:22	php	33798	#0 {main}
Oct 1 21:12:22	php	33798	Stack trace:
Oct 1 21:12:22	php	33798	Standard input code: New alert found: PHP ERROR: Type: 1, File: Command line code, Line: 1, Message: Uncaught Error: Call to undefined function create_interface_ipv6_cfgcache() in Command line code:1
Oct 1 21:12:22	php	33798	thrown
Oct 1 21:12:22	php	33798	#0 {main}
Oct 1 21:12:22	php	33798	Stack trace:
Oct 1 21:12:22	php	33798	Standard input code: PHP ERROR: Type: 1, File: Command line code, Line: 1, Message: Uncaught Error: Call to undefined function create_interface_ipv6_cfgcache() in Command line code:1
Oct 1 21:12:20	assign_gua_from_iapd	88073	restarting dpinger
Oct 1 21:12:20	assign_gua_from_iapd	87791	assigning 2600:4040:XXXX:6cff::1 to interface igb0
Oct 1 21:12:20	assign_gua_from_iapd	87398	GUA: 2600:4040:XXXX:6cff::1
Oct 1 21:12:20	assign_gua_from_iapd	86800	IA_PD found: 2600:4040:XXXX:6c00::/56
Oct 1 21:12:20	php	511	rc.bootup: dhcp6 init complete. Continuing
Oct 1 21:12:20	assign_gua_from_iapd	84682	lockfile present, aborting
Oct 1 21:12:19	php-fpm	460	/rc.newwanipv6: rc.newwanipv6: on (IP address: fe80::21b:21ff:fe73:d358%igb0) (interface: wan) (real interface: igb0).
Oct 1 21:12:19	php-fpm	460	/rc.newwanipv6: rc.newwanipv6: Info: starting on igb0.
Oct 1 21:12:19	php	511	rc.bootup: Unbound start waiting on dhcp6c.
Oct 1 21:12:18	rtsold	67737	Received RA specifying route fe80::f6b5:2fff:fe04:d9da for interface wan(igb0)
Oct 1 21:12:18	php	511	rc.bootup: Unbound start waiting on dhcp6c.
Oct 1 21:12:17	assign_gua_from_iapd	67145	acquiring lockfile
Oct 1 21:12:17	php	511	rc.bootup: Unbound start waiting on dhcp6c.

luckman212

@sirsilentbob That's very kind but no need for any paypal etc I am glad to hear this might be useful.

So yeah without applying the patch you'll be missing a function called create_interface_ipv6_cfgcache() which is so the script can be a little more efficient and check if the IP is the same or not before applying any redundant changes.

It's not strictly necessary, so if you can't apply the patch using System Patches (probably due to differences between CE and Plus) then you can just comment out the line using 2 forward slashes //. I added a note about this to the README on github. Hopefully after doing that and rebooting it shouldn't cause any more crashes.

SirSilentBob

@luckman212 Oh I DID apply the patch, but it's still giving those hourly errors.

I can comment out the specific line, but before I do, anything else I should modify or anything else you need info on? I guess I could go from CE to plus maybe next weekend or so...

luckman212

@sirsilentbob You only applied the companion patch which activates the automatic assignment (so a cronjob isn't needed.)

You still need the other patch from https://github.com/pfsense/pfsense/pull/4595/ to bring in the missing function.

If you don't want to (or can't) apply that one, then I suggest just commenting out line 57 as mentioned in the readme and going with a cronjob every XX min.

SirSilentBob

@luckman212 Ok. Sorry, I misunderstood! I thought there was just the one.

betapc

@luckman212 Hi,

Nice work. I follow all the instructions and I have when a run the command assign_gua_from_iapd.sh, there are 2 error the first one "specify an interface", so then run the command specifying the interface assign_gua_from_iapd.sh igb0 then I had the follow out put "waiting a few seconds for IA_PD no IA_PD detected in logs". I am on Verizon FiOS and I have access to IPv6. So what I am doing wrong?

Thanks