When I try to put the prefix given to me by HE in the 'IPv6 WAN Address' prefix field I get the error:
Prefix: Invalid Prefix / Prefix Length. Enter valid prefix and length in format ::/. Prefix length must be integer value between 32 and 63 and cannot be shorter than specified prefix.
So I went and allowed a Routed /48 address. I plugged that in, and still got the same error.
Note: I made sure to have the ::/ at the end. I even tried ::/. still with no luck.
I have a Verizon actiontec mi424wr rev.I router. I also made sure to have the Protocol 41 open as well.
Could you attach a screenshot of the configuration page to this thread?
I see many errors in your configuration:
- You have chosen static, but that is for use with native IPv6 from your ISP. You need to choose something else, in order to use addresses from HE.
- You are missing a length at the end of your WAN prefix. The correct value should be 64.
- You chose DHCPv6 for your LAN. Using SLAAC or SLAAC+DHCPv6 would work with more devices.
- You are using RFC 4193 addresses for your LAN. Using globally routeable addresses would work better.
- It looks like the RFC 4193 addresses might not have been generated using the correct algorithm.
If you show us a list of the options in the two dropdowns, we can advice you about, which would be better choices.
I have Verizon. I have called their Help Desk and they said that they do not IPv6 for residential customers.
On your 2nd point, the error says I have to between 32 to 64.
There is no option for SLAAC or SLAAC+DHCPv6.
I know that there is no option to enter anything in the 'LAN IPv6 Unique Local Address' and 'LAN IPv6 Link Local Address'
Then you cannot configure an IPv6 tunnel on that device. If you want you should try configuring it on a machine behind that device, and use that machine/device as your IPv6 router.
Quote from: mlegions on February 23, 2014, 09:48:44 AMI have Verizon. I have called their Help Desk and they said that they do not IPv6 for residential customers.
Lazy bastards ;-)
Quote from: mlegions on February 23, 2014, 09:48:44 AMOn your 2nd point, the error says I have to between 32 to 64.
That does not make any sense to me. The WAN prefix is a link prefix. Link prefixes are normally from 64 to 127 bits long. A routed prefix is usually between 48 and 64 bits long, so it would make a bit more sense to specify a range from 32 to 64, if they were talking about a routed prefix. But the WAN address by definition is not part of a routed prefix.
Quote from: mlegions on February 23, 2014, 09:48:44 AMThere is no option for SLAAC or SLAAC+DHCPv6.
The SL in SLAAC stands for stateless. I'm pretty sure the option they call "Stateless" means SLAAC. One would hope that the DHCPv6 option still leaves SLAAC enabled, such that DHCPv6 really means SLAAC+DHCPv6, but given what else I see in those screenshots, I doubt it.
Quote from: mlegions on February 23, 2014, 09:48:44 AMI know that there is no option to enter anything in the 'LAN IPv6 Unique Local Address'
So it autogenerates something wrong and provides no option to change it.
Quote from: mlegions on February 23, 2014, 09:48:44 AMand 'LAN IPv6 Link Local Address'
That's fine. You shouldn't need to change that.
Both the static and DHCPv6 options for the WAN side require native IPv6 from your ISP. In order to use HE you need a router with other options. The DHCPv6 option on the WAN side should have been able to retrieve some of the LAN settings from the ISP's DHCPv6 server. But that feature appears to be missing, though I'd argue that might be the most important feature in DHCPv6 on the WAN side.
Based on what I have seen in those screenshots, I even doubt this device is capable of routing IPv6 packets. They may have given you a NAT66 device instead of an IPv6 capable router. Hopefully a firmware upgrade can fix it.
It might be worth checking in the firewall section to see if something in there is causing it to behave stupidly. But I am not optimistic about it.
If you can pass IPv4 packets with protocol number 41 through the router, you can let another device on the LAN act as a tunnel endpoint instead.