IPv6 Native with Telstra, Australia

[Larrikin]

@derelict said in IPv6 Native with Telstra, Australia:

The first thing I see in that capture that was responded to is there is no specificity in the request for the PD length so I would uncheck Send IPv6 Prefix Hint.

Also, I found an old post from another forum who claimed he got pfsense to work with Telstra

How about a link to that?

I think that packet capture is also a red herring. I have had someone try and replicate those settings and he gets the same result I do. I'll dig up the link though for you.

In the meantime, this link here is our most promising. It's just been done and probably steers us closest to getting this working.

https://forums.whirlpool.net.au/thread/2784659?p=2#r29

[Larrikin]

@derelict said in IPv6 Native with Telstra, Australia:

@larrikin said in IPv6 Native with Telstra, Australia:

@Derelict Whilst I think of it, what is going on at the ICMP level where Telstra does respond back to pfsense (neighbor solicit), but pfsense doesn't do anything with Telstra's response? Telstra stated in their email to me that they believe that is part of the problem. What should I say back to Telstra in relation to that?

What packet capture and what response? Please be specific.

I don't want to lose focus on that other link I just gave you as I think the key to getting this working is in that link.

I think the answer to getting this working lies in this link: https://forums.whirlpool.net.au/thread/2784659?p=2#r29

Note that just got posted with someone else trying to help getting this working.

However, back to answering your question, I am referring to what is in my original post:

Packet capture on my end:

22:13:15.731905 00:0c:29:05:a3:a1 > 33:33:ff:2f:08:93, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::20c:29ff:fe05:a3a1 > ff02::1:ff2f:893: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::4e16:fcff:fe2f:893
source link-address option (1), length 8 (1): 00:0c:29:05:a3:a1
0x0000: 000c 2905 a3a1

22:13:15.293243 4c:16:fc:2f:08:93 > 33:33:ff:05:a3:a1, ethertype IPv6 (0x86dd), length 96: (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:8003:0:bdf:f0:3:9:0 > ff02::1:ff05:a3a1: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::20c:29ff:fe05:a3a1

Telstra's logs:

(including the email from the Telstra tech so where it says "I" below, I = Telstra tech guy)

I can see it sending Ipv6 DHCPv6

13:30:59.553687 In
Juniper PCAP Flags [no-L2, In]
-----original packet-----
PFE proto 6 (ipv6): (hlim 1, next-header: UDP (17), length: 146) fe80::20c:29ff:fe05:a3a1.dhcpv6-server > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 Relay-forward

It’s also unable to establish Ipv6 neighbours which I suspect is a reason why it’s not functioning correctly

13:31:01.106029 In
Juniper PCAP Flags [no-L2, In]
-----original packet-----
PFE proto 6 (ipv6): (hlim 255, next-header: ICMPv6 (58), length: 32) fe80::20c:29ff:fe05:a3a1 > ff02::1:ff2f:893: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::4e16:fcff:fe2f:893
source link-address option (1), length 8 (1): 00:0c:29:05:a3:a1
0x0000: 000c 2905 a3a1

13:31:02.073018 Out
Juniper PCAP Flags [no-L2]
-----original packet-----
PFE proto 6 (ipv6): (class 0xc0, hlim 255, next-header: ICMPv6 (58), length: 32) 2001:8003:0:bdf:f0:3:9:0 > ff02::1:ff05:a3a1: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::20c:29ff:fe05:a3a1
source link-address option (1), length 8 (1): 4c:16:fc:2f:08:93
0x0000: 4c16 fc2f 0893

[Derelict]

Please post captures not textual representations.

[Larrikin]

@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.

[Derelict]

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.

[Larrikin]

@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.

[Larrikin]

@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).

[Derelict]

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.conf

You can copy that to /root with cp /var/etc/dhcp6c_wan.conf /root/orig_dhcp6c_wan.conf

Then make a working copy with cp /root/orig_dhcp6c_wan.conf /root/working_dhcp6c_wan.conf

Then you can edit /root/working_dhcp6c_wan.conf to 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 dhcp6c

Then manually run it with your custom configuration file:

/usr/local/sbin/dhcp6c -D -f -c /root/working_dhcp6c_wan.conf eth0

Substituting 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.conf

to 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.

[Larrikin]

@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]

login-to-view

[Larrikin]

@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.

[Derelict]

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.

[Larrikin]

@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.

[Derelict]

DHCP6: https://tools.ietf.org/html/rfc3315

[Larrikin]

@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.

[Larrikin]

This post is deleted!

[Larrikin]

@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/

[Larrikin]

@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.

[Derelict]

RFC-3633

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.

[Larrikin]

@derelict said in IPv6 Native with Telstra, Australia:

RFC-3633

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.