IPv6 Prefix Delegation broken?

jimp

ok, figured mine out, my WAN interface's prefix length wasn't set to match the upstream router, I had it set to /60 on the upstream but the ALIX was set to /64 (I must have defaulted it at some point and never checked back on it…)

athurdent

Hmm, I am delegating a /64 and have external and internal Interface set to /64, too. Is there a problem using a /64? The only thing I am doing different on my ALIX client is, that I am using the LAN interface as "external" and OPT1 as "internal" for this test. Should it work like that? How can I debug this?

jimp

It shouldn't matter which interface is used for what so long as the PD and track interface selections are right.

On the upstream firewall handing out DHCPv6 prefixes, you'd need to set the PD size there to /64 in Services > DHCPv6 Server/RA, and also make sure your delegation range is set on a boundary that would allow for multiple /64's.

In your case on LAN you'd have it set to DHCPv6 and a prefix delegation size of 64. On OPT1 you'd have it set to Track Interface, and for IPv6 Interface you'd have LAN selected there and a Prefix ID of 0.

I haven't tried resetting mine all around for a /64. Might try that if I get time later.

athurdent

OK, what I found out so far:
I switched to delegating /62 nets for my tests. Using /62 now on "DHCPv6 Prefix Delegation size".
External net: 2001:xxxx:xxxx:dead::/64
Delegated Net in this case: 2001:xxxx:xxxx:2000::/62

IPv6 Prefix ID: ", or leave blank." does not work, I have to enter something there, went for "0".

I also have to reboot, that is mandatory. Just pressing apply does not help.

After a reboot the dashboard shows a correct IP from the delegated net on the internal interface.
However, ifconfig on the internal net shows the following:

vr2: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
        options=8280b <rxcsum,txcsum,vlan_mtu,wol_ucast,wol_magic,linkstate>inet6 fe80::1:1%vr2 prefixlen 64 scopeid 0x3
        inet6 2001:xxxx:xxxx:dead::1 prefixlen 64
        inet6 2001:xxxx:xxxx:2000:20d:b9ff:fe12:7866 prefixlen 64</rxcsum,txcsum,vlan_mtu,wol_ucast,wol_magic,linkstate></up,broadcast,running,simplex,multicast>

the alias 2001:xxxx:xxxx:dead::1 is wrong, thats my external net.

Also the auto configured DHCP server uses the wrong (external) net:

cat /var/dhcpd/etc/dhcpdv6.conf

option domain-name "local-lan";
option ldap-server code 95 = text;
option domain-search-list code 119 = text;

default-lease-time 7200;
max-lease-time 86400;
log-facility local7;
ddns-update-style none;
one-lease-per-client true;
deny duplicates;
ping-check true;
authoritative;
subnet6 2001:xxxx:xxxx:dead::/64 {
        range6 2001:xxxx:xxxx:dead::1000 2001:4dd0:fb52:dead::2000;

jimp

I switched mine to /64 on the server and client side and I get the expected IP, no alias like that, and a proper DHCPv6 server config also.

Not sure where the problem might be there… I only get the wrong addresses if the prefix size on the server doesn't match the client.

I did notice that rebooting was necessary after changing the size on the client though, not sure what's up there.

athurdent

Ok, thanks for the help so far.
I have found the problem. I had set my RADVD to "Assisted". Setting it to "Managed" solved the problems.
Is it mandatory to use "Managed" when configuring IA-PD?
Most users do not have the option to configure their DHCPv6 server / RADVD, I think. Normally your Cable/DSL provider will do that for you, maybe you do not have access to the device at all.
As a workaround, could we safely turn off SLAAC on the Client when using IA-PD or would that break something?

jimp

Not sure there, databeestje would know for sure.

athurdent

As it is mandatory on other BSD to set net.inet6.ip6.accept_rtadv=0 when enabling IPv6 forwarding, I tried to do this on my test system. Sadly I can't find a way to have this option set at boot time, which is necessary because at least in my case I have to reboot to get IA-PD working.
I tried it via the GUI and also in /etc/sysctl.conf but it will always be (re)set to 1 at some point I cannot find. Any hints?

eri--

That is set since probably you have a DHCP6 type WAN interface configured which requires routing advertisement set!
Not sure how this case can be handled.

UPDATE: Does your dhcp wan get router information through DHCP by any case? Or it needs RA as well?

athurdent

I turned off RA completely and only left on DHCPv6 on my Router, then my client gets an external /128 and ignores the delegated prefix. It uses the external net on the inside again. So the only way to get IA-PD to work on the client side is to use RA set to Managed and turn on DHCPv6. I am out of ideas how one would use IA-PD on pfSense when RA does anything else than Managed. Maybe it is invalid to use anything else and databeestje can shed some light into this.

eri--

Can you try with later snapshots or gitsync i think i fixed this just now.
This is the related fix https://github.com/bsdperimeter/pfsense/commit/6ebfa0ccfd7db500a4f85d2d45ebd74699a8805f

athurdent

Thanks for looking into this!
As I'm on NanoBSD, I just copied the interfaces.inc over, no gitsync. I am on the latest snapshot.
For the tests I have set RADVD to Assisted on my gateway.
Interface configuration on the client looks good after a reboot. No external address on the inside, just an address of the delegated network.
RADVD and DHCPv6 are not started automatically after reboot, the configs also don't contain the delegated subnet.
If I press save / apply on the external interface, they get generated/configured correctly and start.
But that also spawns a second dhcp6c, the old one is not killed.

root  19235  0.0  0.5  3328  1288  ??  Ss    2:32PM   0:00.01 /usr/local/sbin/dhcp6c -d -c /var/etc/dhcp6c_lan.conf -p /var/run/dhcp6c_lan.pid vr0
root  82988  0.0  0.5  3328  1288  ??  Ss    2:34PM   0:00.00 /usr/local/sbin/dhcp6c -d -c /var/etc/dhcp6c_lan.conf -p /var/run/dhcp6c_lan.pid vr0

Pressing save / apply on the internal interface destroys the radvd.conf and dhcpdv6.conf and nothing works anymore.
If I press save / apply on the external interface again, I get third dhcp6c instance.

eri--

I pushed some more fixes.
Same you can just recopy interfaces.inc since it contains the changes.

athurdent

Didn't change anything, sorry. Even with latest 6387590fa6dcd90f11154c62ad87c62aec43b1b9
The system acts exactly like described before. I double checked that I am using the newest version of interfaces.inc

Edit: if it helps, from Syslog right after reboot:
php: : Error: cannot open dhcpdv6.conf in services_dhcpdv6_configure().
dhcp6c[19183]: update_ia: T1(2250) and/or T2(3600) is locally determined

phil.davis

Are you on a nanobsd system?
There isn't any call to conf_mount_rw then conf_mount_ro in services_dhcpdv6_configure(). If this routine is called from something that does not already have the file system mounted RW, then trying to write the dhcpdv6.conf will fail. The easy fix would be to put these rw/ro calls either side of the block of code doing the file_put_contents. But ermal might see a better/more appropriate place to do it - I'll leave it to him as I don't have a test system accessible now to play on.

eri--

Pushed another fix its both services.inc and interfaces.inc
Test it out and let me know.

athurdent

Sorry, no changes. Same behaviour as described in http://forum.pfsense.org/index.php/topic,58664.msg314878.html#msg314878

eri--

Can you show me the contents of /tmp/dhcpd.sh?

athurdent

Sure:

cat /tmp/dhcpd.sh
mkdir -p /var/dhcpd
mkdir -p /var/dhcpd/dev
mkdir -p /var/dhcpd/etc
mkdir -p /var/dhcpd/usr/local/sbin
mkdir -p /var/dhcpd/var/db
mkdir -p /var/dhcpd/var/run
mkdir -p /var/dhcpd/usr
mkdir -p /var/dhcpd/lib
mkdir -p /var/dhcpd/run
chown -R dhcpd:_dhcp /var/dhcpd/*
cp /lib/libc.so.* /var/dhcpd/lib/
cp /usr/local/sbin/dhcpd /var/dhcpd/usr/local/sbin/
chmod a+rx /var/dhcpd/usr/local/sbin/dhcpd

eri--

Do you have those directories created?
If you run the script from ssh do you get any errors?