08-08-2013 08:23 PM
Is there a public roadmap to when Telus will provide IPv6 connectivity to residential and/or mobile customers?
Will there be any DSLAM compatibilty issues as an ADSL customer?
Solved! Go to Solution.
09-23-2015 05:23 PM
Hi @mtylerb and @skyblaster,
I am happy to share that we are in the midst of enabling IPv6 for eligible TELUS Internet subscribers. To be eligible you must be on our Converged Edge network (true of most TELUS Internet subscribers) and have an Actiontec gateway. Zyxel gateways will be enabled with a firmware update, likely in 2016. I hope you enjoy the addition of IPv6 connectivity coming soon to you!
08-09-2013 10:11 AM
Hi there!
IPv6 is a technology protocol. As such, there will not be a specific IPv6 service. Existing services will be enhanced to support IPv6 and new services will be developed which leverage the capabilities that IPv6 provides.
Today, no services offer IPv6 as an option. However, TELUS supports the move to IPv6 and have been operating experimental IPv6 networks for years.
TELUS is making TELUS.com and TELUSMOBILITY.com available via IPv6 addressing.
To connect to our websites with IPv6, an IPv6 tunnel broker will be required. These free brokers can be installed on personal computers from the following tunnel broker providers:
http://tunnelbroker.net/register.php
Test IPv6 Connectivity: http://test-ipv6.com/
Hope that helps!
08-09-2013 10:56 AM
No, unfortunetely that doesn't help as you didn't answer either of my questions.
I'm already using a free tunnel to the IPv6 Internet courtesy of Hurricane Electric. I don't mean to single Telus out. Most Canadian ISPs are behind in this transition. I just so happen to be a Telus customer and that's why I'm asking here.
08-09-2013 11:19 AM
Sorry but there's no ETA yet as to when TELUS will provide the IPv6 & no info yet for the DSLAM compatibility but stay tune for updates.
08-14-2014 10:24 PM
Sorry to resurface an old thread. Any updates on this? It's been a year and I'm really anxious to get IPv6 up and running natively. So many issues trying to use tunnels.
09-23-2015 05:23 PM
Hi @mtylerb and @skyblaster,
I am happy to share that we are in the midst of enabling IPv6 for eligible TELUS Internet subscribers. To be eligible you must be on our Converged Edge network (true of most TELUS Internet subscribers) and have an Actiontec gateway. Zyxel gateways will be enabled with a firmware update, likely in 2016. I hope you enjoy the addition of IPv6 connectivity coming soon to you!
12-12-2015 07:58 PM
A couple of weeks ago I was happy to discover that my Actiontec T1200H got IPv6 connectivity. I got prefix length 56, which is OK. I allows for 256 subnets, of which subnet 00 is used by the LAN side on the router and FF on the WAN side, which leaves 254 subnets for home use.
My happiness was short-lived, however, as I quickly discovered that Actiontec will not route anything to any of the assigned subnets (except for its own 00 subnet). The routing table is read-only, and the router will disregard any Router Advertisements from any other routers on the LAN side that carry routing information for other subnets.
Putting own router on PORT 1 in bridge mode as a workaround does not work either: it gets only IPv4 address, and no IPv6 address. So I had to go back to my SixXS tunnel.
It seems that the IPv6 deployment is half-working and half-broken. Or is it still more upgrade coming soon?
12-13-2015 05:56 PM - edited 12-13-2015 06:00 PM
12-15-2015 08:03 PM
Thanks for your explanation. It it very encouraging. I understand now why Port 1 option was not working for me and will give it another try with just DHCP6-PD.
As for Actiontec not willing to sub-delegate any longer prefixes to its clients, I hope it will be supported at some time, otherwise what's the point of assigning /56 per customer?
12-21-2015 02:58 AM - edited 12-21-2015 02:59 AM
what i dont get is that the actiontec is set to prefix only but it shows a wan ipv6 address with a /56
maybe thats just the prefix its getting and not the wan address? my edgerouterx doesnt show wan address?
admin@ERX:~$ show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address S/L Description
--------- ---------- --- -----------
eth0 192.168.2.3/24 u/u Local
eth1 162.156.10.91/22 u/u Internet
eth2 - u/u Local
eth3 - u/u Local
eth4 - u/u Local
lo 127.0.0.1/8 u/u
::1/128
switch0 192.168.1.1/24 u/u Local
2001:569:7419:e101:46d9:e7ff:fe07:73be/64
2001:569:7419:e101::1/64
admin@ERX:~$
i have a nat destination rule for 192.168.2.3 routing back to my telus router at 192.168.2.1 so i can log into it from my bridged setup 😉
what i dont get is why my computer, my phone, and my router all seem to get different default gateways yet all be on the same /64 and none of the default gateways are like my routers address
IP Route Table for VRF "default"
K ::/0 [0/1024] via fe80::2d0:f6ff:fe3c:2788, eth1, 08:14:54
C ::1/128 via ::, lo, 08:18:00
C 2001:569:7419:e101::/64 via ::, switch0, 08:14:54
C fe80::/64 via ::, eth0, 07:37:25
admin@ERX:~$
12-21-2015 09:11 AM - edited 12-21-2015 09:14 AM
12-21-2015 02:52 PM - edited 12-21-2015 02:53 PM
thats so odd, on my Ubiquiti EdgeRouterX it seems to be showing up the other way around
my equivalent to what your claiming is the IPV6 WAN address is on switch0 which is my lan
my equivalent to what your claiming is the IPV6 WAN link local address is on switch0 which is my lan
my equivalent to what your claiming is IPV6 LAN link local address is on eth1 which is my WAN and is kinda confusing
i determined this because there essentially is no "IPV6 LAN address" according to you ,other then the local
the "IPV6 WAN address" is always common to the "IPV6 WAN address"
so because the equivalent of the "IPV6 WAN address" is on my LAN (switch0) then i know that what you are claiming is "IPV6 WAN address" and "IPV6 WAN link local address" will be on the same interface (WAN) and the last 4 sets of colins will match
also my default gateway is the ipv6 link local wan address i believe and that is on switch0 which is my lan
admin@ERX:~$ show interfaces ethernet eth1
eth1: mtu 1500 qdisc htb state UP qlen 1000
link/ether 44:d9:e7:07:73:b5 brd ff:ff:ff:ff:ff:ff
inet 162.156.10.91/22 brd 162.156.11.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::46d9:e7ff:fe07:73b5/64 scope link
valid_lft forever preferred_lft forever
Description: Internet
RX: bytes packets errors dropped overrun mcast
3396004608 2729626 0 0 0 0
TX: bytes packets errors dropped carrier collisions
636239107 1506452 0 0 0 0
admin@ERX:~$ show interfaces switch switch0
switch0: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ether 44:d9:e7:07:73:be brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 brd 192.168.1.255 scope global switch0
valid_lft forever preferred_lft forever
inet6 2001:569:7419:e101:46d9:e7ff:fe07:73be/64 scope global dynamic
valid_lft 86134sec preferred_lft 14134sec
inet6 2001:569:7419:e101::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::46d9:e7ff:fe07:73be/64 scope link
valid_lft forever preferred_lft forever
Description: Local
RX: bytes packets errors dropped overrun mcast
645390831 1556292 0 0 0 0
TX: bytes packets errors dropped carrier collisions
3461080703 2802887 0 0 0 0
admin@ERX:~$ ^C
Wireless LAN adapter Wireless Network Connection 6:
Connection-specific DNS Suffix . : ERX
Description . . . . . . . . . . . : Intel(R) Wireless-N 7260
Physical Address. . . . . . . . . : 0C-8B-FD-2B-D1-A3
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2001:569:7419:e101:d4db:460f:3469:bddf(Preferred)
Temporary IPv6 Address. . . . . . : 2001:569:7419:e101:d8aa:b6e0:2f97:5a4e(Preferred)
Link-local IPv6 Address . . . . . : fe80::d4db:460f:3469:bddf%5(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.1.14(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Monday, December 21, 2015 1:34:40 AM
Lease Expires . . . . . . . . . . : Tuesday, December 22, 2015 11:45:15 AM
Default Gateway . . . . . . . . . : fe80::46d9:e7ff:fe07:73be%5
192.168.1.1
DHCP Server . . . . . . . . . . . : 192.168.1.1
DHCPv6 IAID . . . . . . . . . . . : 504138749
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1A-BA-C9-AE-00-26-B9-01-F8-26
DNS Servers . . . . . . . . . . . : 192.168.1.1
NetBIOS over Tcpip. . . . . . . . : Enabled
C:\Users\Connor>
ps i have no dns set on my dhcpv6-pd so that the telus ipv4 addresses are all my router uses and all my lan clients use 192.168.1.1 running an adblocker on dnsmasq
12-21-2015 03:34 PM
I have never played with that device but looking at your output I think:
This address would be your ipv6 WAN address (on eth0):
inet6 fe80::46d9:e7ff:fe07:73b5/64
And that is what would be talking to our Edge router. The default gateway for your router would also be a link local address that should show up in the router's route table.
Devices in your home that connect to your router would most likely have a default gateway of
fe80::46d9:e7ff:fe07:73be
And I assume they are all getting addressing in the 2001:569:7419:e101::/64 range?
It looks like your router has assigned itself this IP out of that range:
2001:569:7419:e101:46d9:e7ff:fe07:73be
and I would assume is using that for it's own IPv6 internet connectivity, similar to what the Actiontec calls the IPv6 WAN Address. These addresses are used for the RG to communicate with the internet, but they aren't a WAN address used for routing traffic to and from clients connected behind them out to the internet.
12-21-2015 03:52 PM
ok, so your saying fe80::46d9:e7ff:fe07:73b5/64 is my IPV6 WAN link local address?
i agree
but on the telus router the IP address that the device it assigns itself, it used the last digits from the IPV6 WAN link local address
wheras my router uses the last digits from my IPV6 LAN link local address
so i guess my router is placing its own IPV6 address on the LAN simply because ipv6 can work like this wheras the actiontec puts its own IPV6 as being on the wan because this is how things typically making sense
as normally lan ips are private and wan ips are not
so is it that the edgerouter is taking its own IP and placing it in the lan wheras the actiontec is taking it and putting it on the wan?
so where you say
"Devices in your home that connect to your router would most likely have a default gateway of
fe80::46d9:e7ff:fe07:73be"
the default gateway on my devices is the IPV6 WAN link local address, and not the IPV6 LAN link local address like it would be on the actiontec
fe80::46d9:e7ff:fe07:73b5
but yes i believe my gateway should be fe80::46d9:e7ff:fe07:73be
its wierd my routers IPV6 address is 2001:569:7419:e101:46d9:e7ff:fe07:73be/64 unding with BE (my IPV6 LAN link local address) instead of ending with the WAN IPV6 link local address and having fe80::46d9:e7ff:fe07:73be as my default gateway..
01-02-2016 04:47 PM
Assigning a shorter prefix to be prepared for future is a smart move. I hope that it means the prefixes we are getting assigned now will turn out to be pretty stable.
As for my IPv6 connectivity I want to to report a success. Based on your advice, I configured my router to only request Prefix Delegation (PD) without Non-temporary Address (NA), and it worked! I played with several DHVPv6 capable clients, but eventually settled on the standard dhclient from Internet Systems Consortium (ISC). The same I use for DHCPv4. Works like a charm, and fast too, an order of magnitude faster than DHCPv4. The DHCPv6 reply contains a /56 prefix and as a bonus two IPv6 addresses of Telus recursive DNS servers. Based on the prefix and following what Actiontec does, I assign to the WAN interface address of my router an address on subnet prefix+FF/64 (with interface ID based on MAC, following RFC 2464), and the LAN address on subnet prefix+00/64, with a custom host ID. Further down the line, all LAN hosts get Router Advertisement messages from my router with the LAN prefix (/64) and auto configure themselves accordingly. And it works! I get full IPv6 connectivity form all my devices.
There is only one problem remaining: routing. DHCPv6, unlike DHCPv4, does not carry routing information. In the IPv6 world, routing is configured by ICMPv6 message type 134: Router Advertisement (RA). Telus Edge router does send out RA messages at regular intervals (ca. 22 min), with a valid route to a link-local address of the edge router. The route is valid for 75 minutes, but will be refreshed long before it expires. My router does autoconfiguration of its default route when it receives RA from the Edge router and everything works fine after that. The problem is on booting: it may take up to 22 minutes for my router to receive RA from the Edge router, and until then IPv6 Internet connection is not working. The canonical solution to this problem is sending a Router Solicitation message (RS), ICMPv6 type 133, as described in RFC 4861, to the all-routers multicast address ff02::2, to which the Edge router should reply with an out-of-schedule RA message. However, despite my sending of tons of RS messages, the Edge router never replies with an RA message; it always sends them according to its own schedule. Am I missing something here again? Do I need to register my MAC or DUID somewhere so that the Telus router will listen to my solicitations? If so, where? What am I doing wrong?
05-18-2016 04:02 PM - edited 05-18-2016 04:26 PM
Hi, how in the world did you configure ISC dhclient to request IA_PD only? I can't find any documentation or examples on the internet. It seems my google-fu is too weak. May I ask that you share your configuration?
Also, how did you configure radvd (I'm assuming you're using this? If you're using ISC dhcpd then I am convinced you are some sort of higher-dimensional being) to use the prefix info from dhclient?
Finally, I saw your comment about the O flag in the Telus RA notification being incorrectly cleared but I read on this website (https://wikispaces.psu.edu/display/ipv6/DHCPv6) that the M and O flags are independent of each other. The website says that the M flag enables/disables stateful dhcpv6 and the O flag enables/disables stateless dhcpv6. It also mentions that it is possible to use both stateful and stateless dhcpv6 and that it is a common misconception that the M flag refers to SLAAC specifically (at least that was my understanding).
If my understanding is correct, the M flag is set to indicate that we require IA PD and DNS addresses (stateful dhcpv6 or M flag == 1) and that we do not need any other info from the dhcpv6 server for stateless autoconfig (stateless dhcpv6 disabled or O flag == 0). This is true because we are given an entire /56 subnet and therefore need no other parameter for stateless dhcpv6 other than our own MAC address for LAN ipv6 and (I'm assuming) some sort of algorithm that is built into Linux for ipv6 privacy extensions that we use for our global ipv6 address
EDIT: I also want to add that I'm aware of dhclient -6 -P command but I assumed you edited your dhclient.conf to request for IA_PD and DNS addresses. I have absolutely no idea how to setup the dhclient.conf properly and it all seems like pig latin to me. All the examples of dhclient.conf I've found are for ipv4.
Thanks in advanced!
06-05-2017 12:08 AM
@ckim44, I've just noticed your post.
You are correct to use dhclient -P command to obtain PD. The contents of dhclient.conf is of little importance as it seems that Telus router ignores most (if not all) options passed. I suspect it is due to their system security policy. So you should be already getting a prefix from Telus. If you enable the verbose mode (option -v) on dhclient, you should be seeing something like:
Internet Systems Consortium DHCP Client 4.3.3 Copyright 2004-2015 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on Socket/eth1 Sending on Socket/eth1 PRC: Confirming active lease (INIT-REBOOT). XMT: Forming Rebind, 0 ms elapsed. XMT: X-- IA_PD e2:3b:79:92 XMT: | X-- Requested renew +3600 XMT: | X-- Requested rebind +5400 XMT: | | X-- IAPREFIX 2001:569:xxxx:xxxx::/56 XMT: | | | X-- Preferred lifetime +7200 XMT: | | | X-- Max lifetime +7500 XMT: V IA_PD appended. XMT: Rebind on eth1, interval 990ms. RCV: Reply message on eth1 from fe80::225:baff:fe51:93d0. RCV: X-- IA_PD e2:3b:79:92 RCV: | X-- starts 1496634852 RCV: | X-- t1 - renew +7200 RCV: | X-- t2 - rebind +10800 RCV: | X-- [Options] RCV: | | X-- IAPREFIX 2001:569:xxxx:xxxx::/56 RCV: | | | X-- Preferred lifetime 14400. RCV: | | | X-- Max lifetime 86400. RCV: X-- Server ID: 00:03:00:01:00:25:ba:51:93:d0 PRC: Bound to lease 00:03:00:01:00:25:ba:51:93:d0.
Look for the line RCV: | | X-- IAPREFIX 2001:569:xxxx:xxxx::/56, this is your prefix.
After that, dhclient is supposed to configure the local host accordingly. This is where the fun begins, because dhclient, out of the box, does not support configuration based on prefix only.
Since it is over a year from your question, I don't know whether you are still interested in the answer, maybe you have figured it out in the meantime. But I am happy to share with you my solution, just let me know.
As for the O flag: you are right that it is independent from M. When the O flag is set it means that the server can provide "other" stateless information, like nameservers, which Telus does provide.
06-05-2017 12:19 AM
Thanks for the reply. The problem is that Telus' edge routers don't respond to RS with an RA until after the DHCP solicit message is sent. In the case of pfsense, by design, it sends the RS first and waits for an RA before sending the DHCP solicit. According to Telus, the reason for this is "security". Some other ISPs have their edge routers configured similarly, and fortunately one of the pfsense users developed a fix for this, which also works on the Telus network.
01-07-2016 01:23 PM - edited 01-07-2016 01:24 PM
Glad to see you got things working!
Now to your other issue. After the dhcp process is completed, our router will send out a RA right after the dhcp reply so you should see something like:
1 0.000000 fe80::1 ff02::1:2 DHCPv6 209 Relay-forw L: :: Solicit XID: 0x90 CID: 000200000d800001
2 0.068277 fe80::221:5ff:fec3:c424 fe80::1 DHCPv6 236 Relay-reply L: :: Advertise XID: 0x90 CID: 000200000d800001
3 1.000588 fe80::1 ff02::1:2 DHCPv6 223 Relay-forw L: :: Request XID: 0x91 CID: 000200000d800001
4 1.412554 fe80::221:5ff:fec3:c424 fe80::1 DHCPv6 236 Relay-reply L: :: Reply XID: 0x91 CID: 000200000d800001
5 2.195250 fe80::221:5ff:fec3:c424 fe80::1 ICMPv6 86 Router Advertisement from 00:21:05:6c:9d:ac
For the RS messages those don't get responded to, that is a security function of the edge network. We are looking to see if there are possible enhancements that can be made in this area, but no idea currently on timing for that.
06-18-2016 12:59 AM - edited 06-18-2016 01:01 AM
I'm trying to get my pfsense router working with native ipv6. I'm not getting anywhere, despite setting it for prefix delegation. I haven't been able find out why it's not working. However, I've been reading several RFCs, specifically RFC 3633, which seems to be written specifically for this particular application. It pretty clearly states that when a requesting router sends a solicit message, the delegating router is supposed to respond with an advertise message. Unless I've completely misunderstood your comment, it seems that the edge routers are bug compatible with the Actiontec, rather than being compliant with standards written for the specific purpose. It's not like any of this is new technology. RFC 3633 is dated 2003. I can't imagine what the reason would be to not use standards-based methods to allow subscribers to connect their routers using native ipv6.
Additionally, it appears that it's not possible for a host to acquire an ipv6 address. At least it didn't work for me. Not sure why this wouldn't be supported either.
01-11-2016 12:37 AM
Thanks for explaining that RS will never be answered; so I did not waste time chasing that path.
Instead of that, I spent some time in the search for the ever-elusive out-of-schedule RA after the DHCPv6 exchange. RA was not coming. Then I realized that on reboot my prefix lease is still valid (it has a preferred lifetime 2 days, and maximum 4 days) so my router did not do the full binding procedure, it just picked up the valid lease and did the quick rebind (request-reply exchange). So in another attempt I forced the dhclient to do the full solicit-adverise-request-reply, maybe that is what the edge router needs for RA. RA was not coming.
My normal sequence is DHCPv4 first, then DHCPv6. So I played with that: DHCPv6 first, then DHCPv4. No RA. Then only DHCPv6, without DHCPv4. No RA.
Here is a complete IPv6 packet sequence for the first 5 minutes after link up. No RA in sight.
No. Time Source Destination Protocol Length Info
1 0.00 :: ff02::16 ICMPv6 130 Multicast Listener Report Message v2
2 0.08 :: ff02::1:ff3b:7992 ICMPv6 78 Neighbor Solicitation for fe80::21f:e2ff:fe3b:7992
3 0.18 fe80::21f:e2ff:fe3b:7992 ff02::16 ICMPv6 150 Multicast Listener Report Message v2
4 0.18 fe80::21f:e2ff:fe3b:7992 ff02::2 ICMPv6 70 Router Solicitation from 00:1f:e2:3b:79:92
5 0.19 fe80::21f:e2ff:fe3b:7992 ff02::16 ICMPv6 150 Multicast Listener Report Message v2
6 0.28 fe80::21f:e2ff:fe3b:7992 ff02::16 ICMPv6 150 Multicast Listener Report Message v2
7 0.79 fe80::21f:e2ff:fe3b:7992 ff02::16 ICMPv6 90 Multicast Listener Report Message v2
8 0.81 fe80::21f:e2ff:fe3b:7992 ff02::1:2 DHCPv6 112 Solicit XID: 0x3f8650 CID: 000100011dfd1b55001fe23b7992
9 1.89 fe80::21f:e2ff:fe3b:7992 ff02::1:2 DHCPv6 112 Solicit XID: 0x3f8650 CID: 000100011dfd1b55001fe23b7992
10 1.92 fe80::225:baff:fe51:93d0 fe80::21f:e2ff:fe3b:7992 DHCPv6 179 Advertise XID: 0x3f8650 CID: 000100011dfd1b55001fe23b7992
11 1.92 fe80::21f:e2ff:fe3b:7992 ff02::1:2 DHCPv6 155 Request XID: 0x285e91 CID: 000100011dfd1b55001fe23b7992
12 2.22 fe80::225:baff:fe51:93d0 fe80::21f:e2ff:fe3b:7992 DHCPv6 179 Reply XID: 0x285e91 CID: 000100011dfd1b55001fe23b7992
13 2.38 fe80::21f:e2ff:fe3b:7992 ff02::16 ICMPv6 150 Multicast Listener Report Message v2
14 2.54 :: ff02::1:ff3b:7992 ICMPv6 78 Neighbor Solicitation for 2001:569:be10:c2ff:21f:e2ff:fe3b:7992
15 2.56 fe80::21f:e2ff:fe3b:7992 ff02::16 ICMPv6 150 Multicast Listener Report Message v2
16 4.19 fe80::21f:e2ff:fe3b:7992 ff02::2 ICMPv6 70 Router Solicitation from 00:1f:e2:3b:79:92
17 8.19 fe80::21f:e2ff:fe3b:7992 ff02::2 ICMPv6 70 Router Solicitation from 00:1f:e2:3b:79:92
18 143.51 fe80::225:baff:fe51:93d0 fe80::21f:e2ff:fe3b:7992 ICMPv6 86 Neighbor Solicitation for fe80::21f:e2ff:fe3b:7992 from 00:25:ba:51:95:17
19 143.51 fe80::21f:e2ff:fe3b:7992 fe80::225:baff:fe51:93d0 ICMPv6 78 Neighbor Advertisement fe80::21f:e2ff:fe3b:7992 (rtr, sol)
20 148.52 fe80::21f:e2ff:fe3b:7992 fe80::225:baff:fe51:93d0 ICMPv6 86 Neighbor Solicitation for fe80::225:baff:fe51:93d0 from 00:1f:e2:3b:79:92
21 148.53 fe80::225:baff:fe51:93d0 fe80::21f:e2ff:fe3b:7992 ICMPv6 86 Neighbor Advertisement fe80::225:baff:fe51:93d0 (rtr, sol, ovr) is at 00:25:ba: 51:95:17
What is strange is that Actiontec does get its IPv6 route set right after boot, so it is getting its RA somehow. I wonder what is the difference. Some specific DHCPv6 options required by the edge router?