Thank you for the update Chris.
I hope it is not too late to include my patch for pfSense 2.3 regarding prefixes.php ?
It is about https://github.com/pfsense/pfsense/pull/2470
I did some investigation over the last weeks and made a patch addressing the mentioned issue + another that occurs in 1 out of 256 times per octet in the IAID+DUID string (actually one of the non-octal encoded octets in the leases file: \n )
so that routing and IPv6 internet connectivity now works!
Not addressed by my patch (because it is unrelated and problem lies somewhere else in pfSense) is some GUI related quirks that I describe in the end. The file that likely needs to be fixed is: https://github.com/pfsense/pfsense/blob/master/src/usr/local/www/status_dhcpv6_leases.php
To understand how prefixes.php uses the ISC DHCPv6 lease file and how it works I made a converter/decoder to interpret the lease content:
https://anderslind.dk/isc-dhcpdv6-lease-decoder
I flashed my sub-router (which is a home router) D-Link DIR-860L A1 (originally running firmware 1.08) with DD-WRT instead and have been using that for quite some time.
I have made tests with different client dhcp6 configurations using DD-WRT and pfSense to reproduce and test the bugs mentioned above and through these tests I noticed those other (GUI related) bugs and made tests for those as well.
I also read https://redmine.pfsense.org/issues/2347 e.g. about the two options/paths Seth mentions regarding adding routes to delegated IPv6 prefixes.
So I try to wrap it up now.
It seems it is ok that the IAID of the IA_NA != that of the IAID of the IA_PD according to RFC 3633 https://tools.ietf.org/html/rfc3633#section-6
Please see section 6 with respect to paragraph 2 (Important):
An IA_PD is different from an IA, in that it does not need to be
associated with exactly one interface. One IA_PD can be associated
with the requesting router, with a set of interfaces or with exactly
one interface. A requesting router must create at least one distinct
IA_PD. It may associate a distinct IA_PD with each of its downstream
network interfaces and use that IA_PD to obtain a prefix for that
interface from the delegating router.
(compared to IAID description for IA_NA found in RFC 3315 https://tools.ietf.org/html/rfc3315#section-22.4 :
IAID
The unique identifier for this IA_NA; the
IAID must be unique among the identifiers for
all of this client's IA_NAs. The number
space for IA_NA IAIDs is separate from the
number space for IA_TA IAIDs. )
as well as sections:
section 7 with respect to paragraph 1 and 2 https://tools.ietf.org/html/rfc3633#section-7
section 8 with respect to paragraph 1 and 2 https://tools.ietf.org/html/rfc3633#section-8
Basically the patch I made is about:
1. Handling of IA_NA and IA_PD strings (that contain IAID+DUID content) using only the DUID part.
2. Fixing regular expression matching with respect to the IAID+DUID string regarding the legal \" substring (used in ISC DHCPv6 leases).
3. Checking the $duid variable before use. Default case for $type in the switch case statement.
Regarding 1. Especially section 8 paragraph 2 of RFC 3633 says SHOULD (https://tools.ietf.org/html/rfc2119) regarding:
When a requesting router sends a DHCP message, it SHOULD be sent on
the interface associated with the upstream router (ISP network). The
upstream interface is typically determined by configuration. This
rule applies even in the case where a separate IA_PD is used for each
downstream interface.
, so it should be quite safe to ignore the IAID part! Maybe for relay agents something extra is needed https://tools.ietf.org/html/rfc3633#section-14 and Errata ID: 3736 (in the bottom) https://www.rfc-editor.org/errata_search.php?rfc=3633 , but I assume this is quite out of scope. (It seems to be undefined how this should work.)
Regarding 2. this means the longer the IAID+DUID string is the more likely it is that it includes a \" and that the regular expression matches too soon, because it is non-greedy! Please read the patch for more comments about this.
Tests¶
I have tested the patch under different circumstances:
In all the cases below the route was created from pfSense to the sub-router and the sub-router had then working IPv6 connectivity to the Internet:
Test A:
Conditions:
IAID=normal (including neither " nor \ somewhere)
DUID=normal mac address (including neither " nor \ somewhere)
ia-na IAID(+DUID) == ia-pd IAID(+DUID)
Result: Works!
Test B:
Conditions:
IAID=normal (including neither " nor \ somewhere)
DUID=normal mac address (including neither " nor \ somewhere)
ia-na IAID(+DUID) != ia-pd IAID(+DUID)
Result: Works!
In the following tests the pfSense GUI "Status / DHCPv6 leases" does not present either the right IAID or the right DUID whenever a " or a \ is used (but routing is established and works!):
(d=decimal, h=hex)
Test C:
DUID=mac address as 00 11 22 33 44 55 (notice 22h==34d==")
IAID=normal (including neither " nor \ somewhere)
ia-na IAID(+DUID) != ia-pd IAID(+DUID)
Result: Works, but the pfSense GUI presents the DUID as:
00:03:00:01:00:11:22:22:33:44:55
when in reality it is:
00:03:00:01:00:11:22:33:44:55
It is both a problem in Leases and Delegated Prefixes in the GUI that the DUID is presented as 22:22 where it should just be 22.
Test D:
IAID=34d (") Tested with IAID of IA-NA
DUID=normal mac address (including neither " nor \ somewhere)
ia-na IAID(+DUID) != ia-pd IAID(+DUID)
Result: Works, but the pfSense GUI shows that IAID is 8738 which in hex is 2222 == "" (two apostrophes)
Test E:
IAID=34d (") Tested with IAID of IA-PD
DUID=normal mac address (including neither " nor \ somewhere)
ia-na IAID(+DUID) != ia-pd IAID(+DUID)
Result: Works, but the pfSense GUI shows that IAID is 8738 which in hex is 2222 == "" (two apostrophes)
Test F:
DUID=mac address as 00 11 5C 33 44 55 (notice 5Ch==92d==\)
IAID=normal (including neither " nor \ somewhere)
ia-na IAID(+DUID) != ia-pd IAID(+DUID)
Result: Works, but the pfSense GUI presents the DUID as:
00:03:00:01:00:11:5c:03
when in reality it is:
00:03:00:01:00:11:5c:33:44:55
Test G:
IAID=92d (\) Tested with IAID of IA-NA
DUID=normal mac address (including neither " nor \ somewhere)
ia-na IAID(+DUID) != ia-pd IAID(+DUID)
Result: Works, but the pfSense GUI presents the IAID as 23644 (5C 5C in hex). Also Wireshark confirms that both sub router and pfSense talk about one 5C (and not two 5Cs).
Test H:
IAID=92d (\) Tested with IAID of IA-PD
DUID=normal mac address (including neither " nor \ somewhere)
ia-na IAID(+DUID) != ia-pd IAID(+DUID)
Result: Works, but the pfSense GUI presents the IAID as 23644 (5C 5C in hex).
The GUI also needs a little fixing with regards to column headings and content that are not aligned on the "Status / DHCPv6 leases" page. At least in the alpha release I have:
2.3-ALPHA (amd64)
built on Sat Jan 02 09:55:38 CST 2016
Note:
It is my plan later to make a live test with all the CPEs that are present in my local non-profit housing association and see how this patch differs to the old version of prefixes.php to get an overview about how many CPEs (Ethernet SOHO routers) actually ask for a prefix and get routes created. But that will first happen in the coming months.