cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

IPv6 connectivity

skyblaster
Neighbour

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?

1 ACCEPTED SOLUTION

Matthew_Wilder
TELUS Employee
TELUS Employee

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!

View solution in original post

31 REPLIES 31

Koalas
Good Samaritan

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://gogonet.gogo6.com/

http://tunnelbroker.net/register.php

Test IPv6 Connectivity:  http://test-ipv6.com/

 

Hope that helps!

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.

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.

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.

Matthew_Wilder
TELUS Employee
TELUS Employee

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!

View solution in original post

Paeonius
Connector

@Matthew_Wilder,


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?

@Paeonius​

Hopefully this will help clear things up for you:

We (TELUS) are using dhcp6-pd to assign an IPv6 Prefix to the requesting router (usually an Actiontec RG). As you have noticed the prefix is /56 is size and the Actiontec is using two /64 prefixes out of that at this time (In theory those prefixes don't have to be a /64, they could be anything within that /56). The Actiontec "owns" the entire /56 prefix, so you can't just arbitrarily pick say a /64 out of that and start using it. The only way that could work is if the Actiontec in turn delegated a prefix to a requesting router on the LAN side (a feature that currently is not supported on it).

Now if you want to use your own router, you can do what you mentioned by using the port 1 bridge mode on the Actiontec and connecting your device into this. It will work fine, however there are a few issues with a majority of 3rd party devices. In order for it to work your device must:

1. Only request a dhcp6-pd (So only send IA-PD in the dhcp6 solicit message). This is what the Actiontecs actually do.

2. If the device does request both an IA-NA, and an IA-PD in the solicit message, then it must conform to RFC 7550. We are not using IA-NA so in our dhcp Advertise message there will be a NoAddrAvail message for the IA-NA, and a prefix for the IA-PD.

#2 is where most of the 3rd party devices have issues. They don't handle this case and will usually reject the dhcp advertise message that is sent down and just go into and endless solicit loop.

Paeonius
Connector

@Dan_Seibel


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?

Connor
Organizer

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:~$


@Paeonius​

The reason we are handing out a /56 right now is to hopefully future proof things. We don't know what will be required in say 5 years but we can prepare for it (will there be some requirement that has all of your Kitchen appliances on one /64, your TVs on another etc etc?)

@Connor​

What you should see on the Actiontec is something like the following (IPs have been changed for this example)

IPv6 Prefix of Delegated: 2001:56a:1234::/56
IPv6 WAN Status: Connected
IPv6 WAN Address: 2001:56a:1234:ff:123:4ff:fe00:1234/64
IPv6 WAN Link Local Address: fe80::123:4ff:fe00:1234
IPv6 LAN Link Local Address: fe80::123:4ff:fe00:1233

This shows the /56 that has been delegated to the Actiontec, it also shows the IP that the Actiontec has assigned itself for it's own internet needs (2001:56a:1234:ff:123:4ff:fe00:1234/64), plus the Link Local addresses.

The IPv6 WAN Address is only used by the Actiontec itself if it needs to get to the internet, it is not used for anything else.

The IPv6 WAN Link Local address is what is used by the Actiontec and our Edge router to route packets between them.

In the example above if there was a PC with IP 2001:56a:1234:ff:10be:aff:fe00:f234 then our edge router would not forward traffic to that destination address, what it would do is look in it's route table and see that to reach 2001:56a:1234::/56 it needs to forward traffic to fe80::123:4ff:fe00:1234 (which is essentially the point to point addressing between our edge router and the RG).

Likewise for traffic from that PC to the internet, the Actiontec would forward traffic to our Edge router's link local address fe80::(something). You can see this in your example for your

gateway: K ::/0 [0/1024] via fe80::2d0:f6ff:fe3c:2788, eth1, 08:14:54

I would guess that devices in your home would be using your devices LAN Link Local address as their default gateway.

With the actiontec this would be the IPv6 LAN Link Local Address.

Connor
Organizer

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





Dan_Seibel
TELUS Employee
TELUS Employee

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.





Connor
Organizer

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

Paeonius
Connector

@Dan_Seibel


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?

@Paeonius

 

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!

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

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.

Dan_Seibel
TELUS Employee
TELUS Employee

@Paeonius


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.

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.

Paeonius
Connector

@Dan_Seibel


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?