IPv6 prefix6 not working as expected

awebster

Anything other than /64 doesn't work.
Tried /60, /56, no go.

jimp

Delegation works great in my home setup on 2.2.4 with /60 chunks.

Delegation Range:
<my_48_prefix>:F000:: to <my_48_prefix>:FF00::
Prefix Delegation Size: 60

Delegating anything smaller than a /64 is probably not wise, I'm not sure why the options like 63 are there, to be honest.</my_48_prefix></my_48_prefix>

johnpoz

what / are you working with total? Do you have a /48, /56? /32 maybe?? Really would hand out anything less than /56 to a site. That site can then break that up into /64s

awebster

Here's my LAB setup…
Everything is carved out of a unique /48
The lab consists of 2 arms, each connected together with a central pfSense called sim-internet. The expected behavior is that each arm receive IPv6 addresses and prefix delegations from this central point.

LAB NETWORK: fd33:3e94:8260::/48 I'll call this N for short in the diagram below...

If the prefix delegations are set to /64, everything works as expected.
Setting the prefix to anything else causes dhcpd to crash with error message on pfSense "sim-internet"

Please see https://redmine.pfsense.org/issues/4829 where this exact issue occurs. All I wanted to know is whether or not this is resolved in 2.2.4 as the bug report seems to indicate it. My experience shows differently.

Some Friday afternoon ASCII art…

Expected outcome is that the LAN-if interfaces on pfSense 1 and 2 obtain prefixes delegated by the "Sim-internet" pfSense.

doktornotor

I frankly cannot see how's "prefix is outside the subnet" exactly same issue like "network mask too short".

jimp

The issue stated in that ticket is different. I was the one who opened that after hitting it on my home router, which is now working fine with the corrections in place on 2.2.4. It's not related to what you're seeing.

awebster

Jimp,

The discussion that ensued over on the ISC mailing list seems to indicate that it is related.
https://lists.isc.org/pipermail/dhcp-users/2015-July/019099.html

Specifically that the delegated prefix doesn't/shouldn't need to be inside the interface's subnet.

Help, I'm confused!

Thanks,
–Andrew

jimp

Your error message is different than the ones stated there. It's not the same issue. If any of the problems from that ticket or the thread (in which I also posted) were still present, it could not be working on my setup which I quoted above. It's a different problem.

awebster

~~Jimp,

Fair enough…, but is there something fundamentally wrong with what I am trying to setup?

My expectations seem to be out of line with reality.~~

I'm an ID10T…it sure works great when the bits AFTER the prefix delegation size are zeroes, and not ones!

Many thanks for all your input that kept me going back to it.

--Andrew

awebster

I will add a little followup to this.

After some experimentation, I've determined that the DHCP leases file in /var/dhcpd/var/db has to be manually edited or deleted if you decide to make the prefix delegation mask shorter at any point, for instance if you go from a /64 prefix delegation size to a /60.

This is because the leases file contains previously allocated leases, and despite the fact that the client is asking for shorter mask (/60 for instance), continues to hand out the same subnet (/64) as it had previously.

Thanks,
–Andrew