IPv6 Prefix Delegation broken?

athurdent

I'm trying to set up prefix delegation, but it's not working as expected.
In short, the delegated prefix is not used, it always uses the external /64 IPv6 net on the internal interface, too.
The long version:
I have configured my main pfSense gateway to hand out a /64 prefix on the LAN side. The file /var/dhcpd/etc/dhcpdv6.conf is generated correctly and a tcpdump shows that the configured /64 prefix is requested and send out correctly to my client ((IA_PD prefix 2001:xxxx:xxxx:affe::/64 pltime:4500 vltime:7200)))).
It also gets a DHCP IP from my LAN net with inet6 2001:xxxx:xxxx:dead::150 prefixlen 128.
Shouldn't that be /64? The autoconf IP on the same interface has a /64 prefix.
The client is another pfSense gateway on the same LAN, on the LAN interface I have enabled IPv6 DHCP6 and set prefix delegation size to /64. I know, normally people would use the WAN interface but I would have to rewire everything, so I just use LAN. I have also created an OPT1 interface which is set to Track Interface (LAN) and I left IPv6 Prefix ID blank (also tried with 0).
Now comes the stange part, the OPT1 interface is automaticaly set to 2001:xxxx:xxxx:dead::1 and /var/dhcpd/etc/dhcpdv6.conf shows a correctly configured DHCPv6 but it also uses the false net 2001:xxxx:xxxx:dead::/64 where it should be using 2001:xxxx:xxxx:affe::/64.
Anything I can do to help debug this further? I'm using 2.1-BETA1 (i386) built on Thu Feb 7 18:00:57 EST 2013 on the client.

eri--

Normally that is how it works even though it sounds wierd.
You get a /128 on the interface from dhcp at least on pfSense from our testing.

You have connectivity issues or just wondering why the configuration is done like that?

athurdent

I don't understand this. I delegate a /64 (2001:xxxx:xxxx:affe::/64) and that is not used on the internal side. Instead one IP address from the the external net 2001:xxxx:xxxx:dead::/64 is used on the outside as /128 and on the inside the whole 2001:xxxx:xxxx:dead::/64 is used, too? I would expect the delegated 2001:xxxx:xxxx:affe::/64 to be used on my inside net.
I don't know how routing should work when using exactly the same net in the LAN and WAN.

jimp

It should be using the delegated network there, and I just checked my ALIX which I have setup to use delegation and it does appear to be using the 'wrong' IP there on its LAN. I don't know when it would have broken though because I don't keep anything connected behind that ALIX most of the time on the LAN segment.

jimp

My edge router that hands out PD subnets to my other VMs and test boxes shows this in the DHCPv6 status:

2001:xxx:yyy:ff00::/60
Routed To: 2001:xxx:yyy:e1c::ff42

but my ALIX shows this:
WAN (wan) -> vr1 -> v4/DHCP4: 192.168.x.x/24
v6/DHCP6: 2001:xxx:yyy:e1c::ff42/128
LAN (lan) -> vr0 -> v4: 192.168.1.1/24
v6/t6: 2001:xxx:yyy:e1c::1/64

The LAN IP on the ALIX should be 2001:xxx:yyy:ff00::1/64.

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.