IPv6 Native with Telstra, Australia
-
@derelict said in IPv6 Native with Telstra, Australia:
Please post captures not textual representations.
If you are referring to this link: https://forums.whirlpool.net.au/thread/2784659?p=2#r29
that isn't me or my work. That is someone else. I think he has done an excellent job at uncovering some key details. I've encouraged him to post here, but in the meantime, I'm providing a link so at least you can read what is in that post.
If you want more details from it, I'll proxy that request by posting on that forum asking for it.
-
Not sure why anyone would want to request a "domain-name" from their ISP. It would be an even bigger mystery why requesting one would be required.
-
@derelict said in IPv6 Native with Telstra, Australia:
Not sure why anyone would want to request a "domain-name" from their ISP. It would be an even bigger mystery why requesting one would be required.
I hear you, but the key thing he has done a packet capture of a successful DHCPv6 connection to Telstra and then comparing that to trying to get pfsense working. I think its the closest and best way to troubleshoot this. He even points out in the working version (which isn't using pfsense) what it takes to get it working as it shows how Telstra has implemented IPv6 and perhaps why pfsense isn't working with it.
-
@derelict said in IPv6 Native with Telstra, Australia:
Please post captures not textual representations.
I truly think our answer lies i this post. Do you mind reading it and giving me your thoughts?
https://forums.whirlpool.net.au/thread/2784659?p=2#r29
As stated above, I can go back to that guy and ask any questions you have (I've encouraged him to come to this forum and participate in this thread, but so far he hasn't yet).
-
If you find that an IA-NA and IA-PD are required you can add them in the advanced configuration.
If you find they REQUIRE you request option 34 I guess you're out of luck and you'll need to use something else. I highly doubt that is the case.
The default dhcp6c configuration file is here:
/var/etc/dhcp6c_wan.confYou can copy that to /root with
cp /var/etc/dhcp6c_wan.conf /root/orig_dhcp6c_wan.confThen make a working copy with
cp /root/orig_dhcp6c_wan.conf /root/working_dhcp6c_wan.confThen you can edit
/root/working_dhcp6c_wan.confto your heart's content using these as your guide:https://www.freebsd.org/cgi/man.cgi?query=dhcp6c.conf&sektion=5&apropos=0&manpath=FreeBSD+11.0-RELEASE+and+Ports#Interface_statement
https://www.freebsd.org/cgi/man.cgi?query=dhcp6c&sektion=8&apropos=0&manpath=FreeBSD+11.0-RELEASE+and+Ports
You can kill the existing dhcp6c with
killall dhcp6cThen manually run it with your custom configuration file:
/usr/local/sbin/dhcp6c -D -f -c /root/working_dhcp6c_wan.conf eth0Substituting eth0 with the physical interface name of your WAN.
You can make changes in the gui and look at what it places in /var/etc/dhcp6c_wan.conf and use that as a guide. Keep in mind you will have to kill that automatically-started dhcp6c process after saving before running your debug foreground process.
Then, if you get it working, you have the original file saved and you can:
diff /root/orig_dhcp6c_wan.conf /root/working_dhcp6c_wan.confto get the changes required.
As long as you don't find something is required that FreeBSD's dhcp6c does not do (like option 34) you should be able to get it working.
The FIRST step in this process is giving up the notion that FreeBSD/pfSense is doing something wrong, like not responding to neighbor discovery. It obviously responds to proper neighbor discovery or nobody's IPv6 would ever work on any provider anywhere. This is obviously not the case.
If they want to press that issue then you will need to pcap on the WAN to be sure you are actually receiving what they say they are sending.
-
@derelict Here is where I am stuck. I can't give the capture files, so I'll have to use text. Here is a successful DHCP request with Telstra:
Working DHCP (not pfsense)
00:00:04.375540 IP6 (flowlabel 0x46adf, hlim 1, next-header UDP (17) payload length: 80) fe80::3cb2:bc83:1dd4:589c.546 > ff02::1:2.547: [bad udp cksum 0x6d8e -> 0x4cff!] dhcp6 solicit (xid=80f112 (client-ID hwaddr/time type 1 time 604416232 001c42a0251a) (option-request DNS-server DNS-search-list Client-FQDN SNTP-servers) (elapsed-time 750) (IA_NA IAID:1117791514 T1:3600 T2:5400) (IA_PD IAID:1117791514 T1:3600 T2:5400))
Note the T1 and T2 values above.
Not working (pfsense)
10:32:08.063065 00:0c:29:05:a3:a1 > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 132: (hlim 1, next-header UDP (17) payload length: 78) fe80::20c:29ff:fe05:a3a1.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=756a16 (client-ID hwaddr/time type 1 time 604501842 000c2905a3a1) (IA_NA IAID:1117791514 T1:0 T2:0) (elapsed-time 3186) (option-request DNS-server DNS-search-list SNTP-servers) (IA_PD IAID:1117791514 T1:0 T2:0))
See how pfsense uses 0 for both T1 and T2? I cannot find a way to change those values to patch T1:3600 T2:5400. That may or may not be the difference between this working or not. It certainly is the only difference in the DHCP request now between the one working versus the one not working.
-
-
@derelict Can't see where I would change the T1 and T2. I've done the IA_PD and IA_NA numbers (easy), but can't see where I can set T1:3600 and T2:5400. pfsense defaults them to 0, but no where can I see either manually in the file or GUI how to set these.
-
You might have to do some RFC scraping. My guess is pltime and vltime. I have never had this be anything I have had to pay any attention to so off the top of my head I don't know.
The links for dhcp6c.conf and dhcp6c I gave above probably have information too.
-
@derelict said in IPv6 Native with Telstra, Australia:
You might have to do some RFC scraping. My guess is pltime and vltime. I have never had this be anything I have had to pay any attention to so off the top of my head I don't know.
The links for dhcp6c.conf and dhcp6c I gave above probably have information too.
I've looked at the links. Nothing in there about T1 and T2. I'm not sure pfsense dhcp6c can set them from the reading I've done. It's not pltime and vltime - that's something different.
-
DHCP6: https://tools.ietf.org/html/rfc3315
-
@derelict said in IPv6 Native with Telstra, Australia:
DHCP6: https://tools.ietf.org/html/rfc3315
I'll have a read of that. In the meantime, I now have a hub so I'm about to packet capture a Telstra router successfully doing DHCP. Will post the results here.
-
This post is deleted! -
@derelict said in IPv6 Native with Telstra, Australia:
DHCP6: https://tools.ietf.org/html/rfc3315
OK, reading that capture, packet 45 is the most interesting, and we are back to the T1 and T2 fields. Somehow need to set them in pfsense.
This is how cisco do it: https://www.alcatron.net/tag/telstra-ipv6-configuration/
-
@derelict Well, after consulting a few other people here in Australia who are all working with me on this, we have all reached a consensus. That those T1 and T2 fields are the sole difference between a working DHCPv6 and a non working DHCPv6 with Telstra.
I get pfsense gets dhcp6c from FreeBSD, who take who take it straight from https://sourceforge.net/p/wide-dhcpv6/git/ci/master/tree/ via https://www.freshports.org/net/dhcp6
So basically unless either FreeBSD allow T1 and T2 fields to be edited rather than hard coded to 0, no one will be able to use IPv6 with Telstra / pfsense. Telstra certainly won't change their end as they officially don't support third party routers. It's too big of a change for them to make.
-
Nothing here says the requesting router MUST set T1/T2. They are merely suggestions to the delegating router for desired renewal times and may be zero.
In a message sent by a requesting router to a delegating router,
values in the T1 and T2 fields indicate the requesting router's
preference for those parameters. The requesting router sets T1 and
T2 to zero if it has no preference for those values. In a message
sent by a delegating router to a requesting router, the requesting
router MUST use the values in the T1 and T2 fields for the T1 and T2
parameters. The values in the T1 and T2 fields are the number of
seconds until T1 and T2.The delegating router selects the T1 and T2 times to allow the
requesting router to extend the lifetimes of any prefixes in the
IA_PD before the lifetimes expire, even if the delegating router is
unavailable for some short period of time. Recommended values for T1
and T2 are .5 and .8 times the shortest preferred lifetime of the
prefixes in the IA_PD that the delegating router is willing to
extend, respectively. If the time at which the prefixes in an IA_PD
are to be renewed is to be left to the discretion of the requesting
router, the delegating router sets T1 and T2 to 0.If a delegating router receives an IA_PD with T1 greater than T2, and
both T1 and T2 are greater than 0, the delegating router ignores the
invalid values of T1 and T2 and processes the IA_PD as though the
delegating router had set T1 and T2 to 0.If a requesting router receives an IA_PD with T1 greater than T2, and
both T1 and T2 are greater than 0, the client discards the IA_PD
option and processes the remainder of the message as though the
delegating router had not included the IA_PD option.Sorry, but if they actually require T1 and T2 to be set in the Solicit/Request messages they are wrong. I think you are chasing a red herring, personally.
Note that similar language exists in RFC-3315, covering IA_NA.
-
@derelict said in IPv6 Native with Telstra, Australia:
Sorry, but if they actually require T1 and T2 to be set in the Solicit/Request messages they are wrong. I think you are chasing a red herring, personally.
Well, it is the ONLY difference in a packet capture that demonstrates a working solicit vs a non working one. Everything else is identical.
-
@larrikin That changes nothing about what I said. RFCs exist for a reason.
-
@derelict said in IPv6 Native with Telstra, Australia:
@larrikin That changes nothing about what I said. RFCs exist for a reason.
Well, a number of us managed to get DHCPv6 working using a packet capture. One was on Unix, the other a stock Telstra supplied router.
We compared the packet captures. For the successful ones, they were pretty much identical in terms of the original solicit captures (all of which I have posted above).
For the unsuccessful ones (pfsense), we managed to get exactly the same solicit packet crafted EXCEPT for T1 and T2 fields, and surprise, it didn't work.
It isn't hard to conclude that those fields are the difference between it working and not. We may have to agree to disagree.
-
Sorry, but if they actually require T1 and T2 to be set in the Solicit/Request messages they are wrong.
On this part, I completely concur. It is non standard. But getting Telstra to change will be impossible. They own the market in Australia, and they want to sell their own routers, and they do not support third party ones (as they can then support the connection end to end using their router). They will not change their DHCPv6 config for us unfortunately.
So either FreeBSD opts to change to allow non standard ISP configs, or its game over.
