IPv6 Native with Telstra, Australia
-
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.
-
I'm following this thread, because somewhere in Juy this year, I will have a fiber connection and probably my ISP will start to offer something that looks like "IPv6".
The thing is, Orange, in France, also joined the international conquest : "How to f*ck up IPv6 RFC rules".@larrikin said in IPv6 Native with Telstra, Australia:
So either FreeBSD opts to change to allow non standard ISP configs, or its game over.
I hate to say this, and might be totally wrong, but there exists some 'fork' of pfSense in Europe that replaced (patch) the local DHCP client so it could work with a upstream ISP to obtain a workable v6 connection.
I will stay a happy pfSense user, because he.net offers a very good alternative - if not far better. I have a POP in Paris, at 600 km or 500 miles away.
@Larrikin : possible to 'install' the ISC DHCP client, setting it up manually (the old way) just to see if it connects ?
-
@larrikin said in IPv6 Native with Telstra, Australia:
They will not change their DHCPv6 config for us unfortunately.
So I suggest submitting a detailed feature request at https://redmine.pfsense.org/ to ask the developers/maintainers to incur all the technical debt for making pfSense accommodate all of the ISPs in the world who choose to disobey accepted standards.
-
@derelict said in IPv6 Native with Telstra, Australia:
@larrikin said in IPv6 Native with Telstra, Australia:
They will not change their DHCPv6 config for us unfortunately.
So I suggest submitting a detailed feature request at https://redmine.pfsense.org/ to ask the developers/maintainers to incur all the technical debt for making pfSense accommodate all of the ISPs in the world who choose to disobey accepted standards.
I actually put a post up saying this is a commercial opportunity for netgate if they wanted it to be. For exactly this type of situation. Telstra isn't going to be the last, nor the first, in this situation. And as IPv6 deployment increases, this is going to happen more and more.
-
@gertjan said in IPv6 Native with Telstra, Australia:
@Larrikin : possible to 'install' the ISC DHCP client, setting it up manually (the old way) just to see if it connects ?
Using a Ubuntu server stock standard, it connected to Telstra's IPv6 fine last night. Not sure if that's what you are basically asking?
-
@larrikin said in IPv6 Native with Telstra, Australia:
Not sure if that's what you are basically asking?
Yes, it is.
I guess the same software (package) exists for FreeBSD, so I will find my way out if I have to. -
@gertjan said in IPv6 Native with Telstra, Australia:
@larrikin said in IPv6 Native with Telstra, Australia:
Not sure if that's what you are basically asking?
Yes, it is.
I guess the same software (package) exists for FreeBSD, so I will find my way out if I have to.Let me know if you find a way to install it and have it work with pfsense :)
-
@derelict said in IPv6 Native with Telstra, Australia:
@larrikin said in IPv6 Native with Telstra, Australia:
They will not change their DHCPv6 config for us unfortunately.
So I suggest submitting a detailed feature request at https://redmine.pfsense.org/ to ask the developers/maintainers to incur all the technical debt for making pfSense accommodate all of the ISPs in the world who choose to disobey accepted standards.
Lol. Check this out. Not me!! https://github.com/opnsense/dhcp6c/issues/9
Look at the date / time. Someone is following our work.
-
@derelict said in IPv6 Native with Telstra, Australia:
@larrikin said in IPv6 Native with Telstra, Australia:
They will not change their DHCPv6 config for us unfortunately.
So I suggest submitting a detailed feature request at https://redmine.pfsense.org/ to ask the developers/maintainers to incur all the technical debt for making pfSense accommodate all of the ISPs in the world who choose to disobey accepted standards.
BTW, are you serious when you ask me to write this up there? Hard to know if you are being sarcastic or not. I do appreciate your point, which is why, as I said above, I created this post (actually before we even started this journey):
https://forum.netgate.com/topic/140938/commercial-opportunity-for-netgate-ipv6
-
Yes, I am serious that you write it up there. I only write things up I can personally test and prove. And I am not going to write something up asking the devs to code something so it works with a broken ISP.
Let me ask you this: If Telstra were to mangle something fundamental like the TCP 3-way handshake so you could only make TCP connections when using their routers, would it be pfSense's burden to code around that, too? Where does it end? What does Telstra have to do to get the finger pointed at THEM?
I am still not convinced this has anything to do with T1/T2.
It would be nice to have confirmation from Telstra as to what they require - and why.
What is being logged by their system when the Solicit is received and why is there no response?
-
@derelict said in IPv6 Native with Telstra, Australia:
Yes, I am serious that you write it up there. I only write things up I can personally test and prove. And I am not going to write something up asking the devs to code something so it works with a broken ISP.
Oh, I certainly wouldn't expect you to write it up. I'd do it if I am going to. But I don't want to write anything up yet until Telstra get back to me next week so I have a much better understanding from their perspective on their implementation of IPv6, and also get their views as to why their DHCPv6 server is not responding (my contact said he'd check the logs against my packet captures to find out). Without that info, I don't want to write anything up as what I have today is speculation, not pure facts.
Let me ask you this: If Telstra were to mangle something fundamental like the TCP 3-way handshake so you could only make TCP connections when using their routers, would it be pfSense's burden to code around that, too? Where does it end? What does Telstra have to do to get the finger pointed at THEM?
Understood so let me get more facts before we do anything else so we know what the actual facts are.
I am still not convinced this has anything to do with T1/T2.
Yeah, I hear you. It is speculation on my part, and until I have further info from Telstra, I say we put ourselves into a holding pattern.
It would be nice to have confirmation from Telstra as to what they require - and why.
What is being logged by their system when the Solicit is received and why is there no response?
Yep - fully agree.
-
@derelict I have captured Ubuntu successfully connecting to Telstra IPv6 and I cannot see a DHCPv6 solicit packet in terms of how it got it.
So I have a theory of how this all works - but I’ll caveat it that I don’t really know this stuff as well as you do.
- Unless I am blind, I cannot see a UDP DHCPv6 solicit packet at all. This is consistent with a number of packet captures I did. I have not missed it by starting the capture late. I followed a very precise workflow and packet captured two ways. one using TCPdump and one using a WAN hub so plugging into the WAN interface and capturing the packets. At every time, the capture started before Ubuntu had ANY connectivity to the NTD.
- ICMPv6 is being used to setup the entire IPv6 delegation.
- ICMPv6 is using neighbor solicitation
- Telstra’s original email to me (which is posted in my original post) also states that one of the reasons they think its failing (pfsense) is that neighbor solicitation on ICMPv6 is failing
- DHCPv6 is the FINAL stage where its issued an IPv6 address and PD, but all the hard work to get there is done via ICMPv6 (and DHCPv6 is not being used to solicit).
ICMPv6 is SLAAC is it not? Are we witnessing a combination of SLAAC and DHCP at work?
Attached is a capture this morning. See attached screenshot for proof that it got its IPv6. The capture is using tcpdump on the Ubuntu box itself.
I booted up Ubuntu without it plugged into anything.
Started the capture.
Plugged the connection in directly to my NTD.
Took the screen shot attached to prove its getting a valid IPv6 address.
Then stopped the capture.
Interested in your thoughts.
0_1551487552781_ubuntu telstra.cap.zip
-
@larrikin had a quick look at your pcap and the first DHCPv6 packets are the "CONFIRM" type. This is what you'd see after a SOLICIT, ADVERTISE and REQUEST.
I would suggest that perhaps the capture is missing whatever happened before it was started.
