pfSense

I can have a look at dhcp6c, easy enough to add something. What do you want it do do, set an env stating what triggered the script?

It would probably be good enough if dhcp6c properly populated REASON with what actually happened. If it's a simple renew, then the script can detect that and do nothing. If it's a new binding or something else then it can take appropriate actions. The IPv4 equivalent gets to make a lot of decisions based on the REASON passed in from the client environment: https://github.com/pfsense/pfsense/blob/master/src/usr/local/sbin/pfSense-dhclient-script#L304

Got a source patch for that? If I do manage to try it, I am not keen on running binaries from outside sources.

This is cool... it works nicely. I'm still messing around with it but I've changed the strings to full reply words such as 'REPLY' 'RELEASE' etc and modified the dhcp6c script to use the response and it's good. It will need you to decide what you want to do with RELEASE etc if that comes in. I assume the script is called for REPLY or REBIND and skipped for INFO or RENEW?

My dhcp6c_wan_dhcp6withoutra_script.sh Not sure what to do with the RELEASE so just call the script I guess.

#!/bin/sh
 #This shell script launches rtsold.
 dmips=${new_domain_name_servers}
 dmnames=${new_domain_name}
 dreason=${REASON}
 echo $dmips > /tmp/igb0_domain_name_servers
 echo $dmnames > /tmp/igb0_new_domain_name
 echo $dreason > /tmp/igb0_reason
 case $REASON in
 REPLY|REBIND)
 /usr/sbin/rtsold -1 -p /var/run/rtsold_igb0.pid -O /var/etc/rtsold_igb0_script.sh igb0
 ;;
 RELEASE)
 /usr/local/sbin/fcgicli -f /etc/rc.newwanipv6 -d "interface=igb0&dmnames=${dmnames}&dmips=${dmips}" 
 ;;
 RENEW|INFO)
 /usr/bin/logger -t Info "dhcp6c renew, no change - bypassing update on igb0" 
 esac

Also added an EXIT as when the No-release flag it's useful to know that dhcp has exited. Would it be be useful to have it so that if it's sent a release to signal only that, and not the EXIT signal too? Otherwise it will issue a RELEASE and an EXIT.

OK, before I do a PR upstream for this, there is one issue left. This only applied in the default mode not dhcp6withoutRA. When releasing, if the EXIT is used to trigger the script dhcp6c_wan_script.sh there is an issue as that file has been deleted before dhcp6c has exited. The dhcp6c_wan_dhcp6withoutra_script.sh is not deleted, I suspect because I have not cleaned up that file during release. If the exit parameter is used then that needs changing. Also on a WAN down event, dhcp6c sits there sending release signals for about 30 seconds but cannot as the interface has been taken down. The only way around this is a forced exit kill -9 and that means no EXIT script run.

• STOP PRESS ***

Added new signal to dhcp6c, SIGUSR1, sending this signal will cause dhcp6c to cleanly exit even if wan interface is down. Sets the no-release internally and then exits normally..

PR Pushed upstream as fix needed for dhcp6c PID issue - Redmine #7185.

Having issues with this in 2.3.3
Every 30 minutes, my IPv6 address is refreshed, causing rc.newwanipv6 to fire on all cylinders, which in turn restarts unbound, which makes DNS lookups for internal addresses get relayed to external DNS servers for a split second, which then makes lookups for those addresses fail, as the external server has never heard of the internal names.

I've tested this by resolving an internal address (static DHCP assignment) with nslookup every 0.5 seconds, and at the exact time unbound restarts, I get:

Name: vault.mydomain.org
Address: 192.168.5.92

Wed Mar 15 19:20:26 UTC 2017
Server: 127.0.0.1
Address: 127.0.0.1#53

Name: vault.mydomain.org
Address: 192.168.5.92

Wed Mar 15 19:20:26 UTC 2017
Server: 127.0.0.1
Address: 127.0.0.1#53

Name: vault.mydomain.org
Address: 192.168.5.92

Wed Mar 15 19:20:27 UTC 2017
Server: 193.213.112.4
Address: 193.213.112.4#53

-- server can't find vault: NXDOMAIN

..and any cronjob or other thing attempting to resolve that address at that point in time will fail.

This loop was run on pfSense itself, so one can see all the previous replies coming from 127.0.0.1

This is fixed in 2.4. DHCP6C client modified to give REASONS and only call the update script when needed.

Are there any plans to have this fixed with a 2.3.* release?

I'm having the same problem (https://forum.pfsense.org/index.php?topic=136181.msg745462#msg745462) which is impacting user browsing on several of our customers who had purchased ALIX appliances.

Since 2.4 has dropped i386 and nanobsd support we and our customers who started rolling IPv6 in production are fundamentally doomed.

Given the scope of the changes and what had to be done, it's unlikely to make it to 2.3.x.