I have a tunnel from HE and it worked just fine for me for quite some time however, I didn't have home internet service for a few months after I moved and after I got hooked up with my new ISP, my tunnel isn't working at all. I'm a bit rusty on this setup since I only did it once and I'd like to make sure that I'm doing it right even though I never removed the ipv6 tunnel settings from my router while it was disconnected from the internet.
The attached image is my Basic->IPv6 router settings.
At this point I'm quite confused since these settings used to work just fine but they aren't working now. So, thank you for any assistance you can provide.
EDIT: I thought that I should add a bit more detail on exactly what I'm experiencing. I can use IPv6 to ping my router however, I cannot ping any IPv6 addresses beyond my router including the IPv6 address of the HE end of my tunnel. Also, using telnet since the GUI doesn't like IPv6 addresses, I've tried pinging various IPv6 addresses (including my tunnels server end and ipv6.google.com) from the router itself and also got nothing.
The tunnel server need to know the IPv4 address of your router. Having moved to another ISP, that address must have changed. If your router isn't configured to update this on tunnelbroker.net automatically, you will need to do it manually through the website. It is possible that your tunnel was deleted, because it was inactive for too long. Once you log in on that page, you will find out if your tunnel is still there.
Quote from: kasperd on May 16, 2013, 03:23:08 PM
The tunnel server need to know the IPv4 address of your router. Having moved to another ISP, that address must have changed. If your router isn't configured to update this on tunnelbroker.net automatically, you will need to do it manually through the website. It is possible that your tunnel was deleted, because it was inactive for too long. Once you log in on that page, you will find out if your tunnel is still there.
I've checked and my tunnel is still active. Also, I have DDNS set up to automatically update HE with my new IP address once a day. Upon checking it, the IP that HE has does match my current public facing IPv4 address. I was going to post a picture of my DDNS settings screen as well but, since it says 'update successful' and HE has the correct IPv4 address for my router I thought that it would be a bit superfluous. Thanks for the suggestion though.
I don't see an obvious explanation for the problem. Could you try temporarily changing the router configuration to use server address 80.167.222.169 instead and then try to ping 2001:470:28:940:793b:aa03:518b:23c8. That IPv4 address is not a real tunnel server, but it will be able to reach that one IPv6 address.
Quote from: kasperd on May 17, 2013, 03:40:29 PM
I don't see an obvious explanation for the problem. Could you try temporarily changing the router configuration to use server address 80.167.222.169 instead and then try to ping 2001:470:28:940:793b:aa03:518b:23c8. That IPv4 address is not a real tunnel server, but it will be able to reach that one IPv6 address.
I don't get anything with that either. I get a "Request timed out." message on my Windows 8 Pro x64 desktop and I get this:
root@Yggdrasil:/tmp/home/root# ping -6 -c 5 2001:470:28:940:793b:aa03:518b:23c8
PING 2001:470:28:940:793b:aa03:518b:23c8 (2001:470:28:940:793b:aa03:518b:23c8): 56 data bytes
--- 2001:470:28:940:793b:aa03:518b:23c8 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
when I telnet to my router and try to ping that address.
Could my ISP be blocking tunneling? Is that even possible without deep packet inspection?
Quote from: RLH1985 on May 17, 2013, 08:08:59 PMCould my ISP be blocking tunneling?
They could, but I would not consider doing so deliberately to be acceptable. A more likely explanation would be that the packets are going through a NAT, which cannot handle protocol 41.
Quote from: RLH1985 on May 17, 2013, 08:08:59 PMIs that even possible without deep packet inspection?
Yes, the protocol number is right there in the IPv4 header. It is easy to block specific protocol numbers. Blocking specific port numbers (on either IP version) will in fact require deeper inspection than blocking tunnelling.
You should try a few things. First of all find out what the external IP address of your router is. You want to know, if there is any NAT involved. Secondly compare traceroute using different protocols. For example try
traceroute 209.51.181.2 and
traceroute -P 41 209.51.181.2
Quote from: kasperd on May 18, 2013, 01:00:36 AM
Quote from: RLH1985 on May 17, 2013, 08:08:59 PMCould my ISP be blocking tunneling?
They could, but I would not consider doing so deliberately to be acceptable. A more likely explanation would be that the packets are going through a NAT, which cannot handle protocol 41.
Quote from: RLH1985 on May 17, 2013, 08:08:59 PMIs that even possible without deep packet inspection?
Yes, the protocol number is right there in the IPv4 header. It is easy to block specific protocol numbers. Blocking specific port numbers (on either IP version) will in fact require deeper inspection than blocking tunnelling.
You should try a few things. First of all find out what the external IP address of your router is. You want to know, if there is any NAT involved. Secondly compare traceroute using different protocols. For example try traceroute 209.51.181.2 and traceroute -P 41 209.51.181.2
*sigh* it looks like the second problem is the case. Both a standard traceroute and a type of service specific traceroute reach the tunnel but my router is behind
two different NAT's. My router's external IP address is 192.168.6.14, the modem in my place has an IP address of 192.168.6.1, and it connects to a system with an IP of 172.18.254.132. Only the next jump has a publicly routable IP address and that is the one the internet sees as mine.
One would hope that an ISP who is in the situation of having to double NAT their customers would try to build out IPv6 quickly but apparently that is either not the case or their upstream provider is dragging their feet as well.
Just in case I managed to foul something up, here's the results of both traceroute's:
Tomato v1.28.0000 MIPSR2-108 K26 USB Big-VPN
root@Yggdrasil:/tmp/home/root# traceroute 209.51.181.2
traceroute to 209.51.181.2 (209.51.181.2), 30 hops max, 38 byte packets
1 192.168.6.1 (192.168.6.1) 0.727 ms 0.659 ms 0.685 ms
2 172.18.254.132 (172.18.254.132) 18.225 ms 18.994 ms 35.566 ms
3 vqwireless.com (71.89.156.145) 26.968 ms 26.640 ms 26.836 ms
4 dtr01dvsnmi-tge-0-1-0-1.dvsn.mi.charter.com (96.34.32.184) 18.228 ms dtr01dvsnmi-tge-0-1-0-0.dvsn.mi.charter.com (96.34.32.180) 22.496 ms dtr01dvsnmi-tge-0-1-0-1.dvsn.mi.charter.com (96.34.32.184) 23.053 ms
5 * * crr02sgnwmi-tge-0-7-0-6.sgnw.mi.charter.com (96.34.32.187) 18.706 ms
6 bbr01sgnwmi-bue-2.sgnw.mi.charter.com (96.34.2.58) 26.559 ms 25.170 ms 16.223 ms
7 bbr01aldlmi-tge-0-1-0-6.aldl.mi.charter.com (96.34.0.54) 19.477 ms 33.030 ms 35.183 ms
8 bbr01chcgil-bue-4.chcg.il.charter.com (96.34.0.99) 36.424 ms 34.662 ms 33.981 ms
9 prr01chcgil-bue-2.chcg.il.charter.com (96.34.3.9) 39.308 ms 43.636 ms 31.413 ms
10 v201.core1.chi1.he.net (216.66.73.241) 35.162 ms 19.786 ms 38.216 ms
11 tserv1.chi1.he.net (209.51.181.2) 28.010 ms 36.156 ms 34.665 ms
root@Yggdrasil:/tmp/home/root# traceroute -t 41 209.51.181.2
traceroute to 209.51.181.2 (209.51.181.2), 30 hops max, 38 byte packets
1 192.168.6.1 (192.168.6.1) 1.003 ms 0.733 ms 0.698 ms
2 172.18.254.132 (172.18.254.132) 18.492 ms 37.928 ms 38.839 ms
3 vqwireless.com (71.89.156.145) 43.609 ms 35.734 ms 37.151 ms
4 dtr01dvsnmi-tge-0-1-0-0.dvsn.mi.charter.com (96.34.32.180) 36.245 ms dtr01dvsnmi-tge-0-1-0-1.dvsn.mi.charter.com (96.34.32.184) 44.485 ms dtr01dvsnmi-tge-0-1-0-0.dvsn.mi.charter.com (96.34.32.180) 36.455 ms
5 crr02sgnwmi-tge-0-7-0-7.sgnw.mi.charter.com (96.34.33.135) 46.043 ms crr02sgnwmi-tge-0-7-0-6.sgnw.mi.charter.com (96.34.32.187) 30.222 ms crr02sgnwmi-tge-0-7-0-7.sgnw.mi.charter.com (96.34.33.135) 35.708 ms
6 bbr01sgnwmi-bue-2.sgnw.mi.charter.com (96.34.2.58) 16.166 ms 20.351 ms 16.620 ms
7 bbr01aldlmi-tge-0-1-0-6.aldl.mi.charter.com (96.34.0.54) 25.877 ms 41.196 ms 27.994 ms
8 bbr01chcgil-bue-4.chcg.il.charter.com (96.34.0.99) 31.304 ms 34.590 ms 35.177 ms
9 prr01chcgil-bue-2.chcg.il.charter.com (96.34.3.9) 31.066 ms 45.537 ms 34.771 ms
10 v201.core1.chi1.he.net (216.66.73.241) 51.062 ms 64.767 ms 55.206 ms
11 tserv1.chi1.he.net (209.51.181.2) 56.123 ms 34.208 ms 42.317 ms
Quote from: RLH1985 on May 18, 2013, 07:31:47 AMBoth a standard traceroute and a type of service specific traceroute reach the tunnel
This is not consistent with the previous results. When you tried to ping my IP, the packets did not reach me. That means either some middelbox is mangling the packets in some way that still leave them recognizable for traceroute, but not valid ICMPv6 packets when decapsulated, or your traceroute wasn't actually testing protocol 41 packets.
Quote from: RLH1985 on May 18, 2013, 07:31:47 AMbut my router is behind two different NAT's. My router's external IP address is 192.168.6.14, the modem in my place has an IP address of 192.168.6.1, and it connects to a system with an IP of 172.18.254.132.
This doesn't tell us much about the number of layers of NAT. Of course we can deduce that your router is doing NAT, and that there is another layer of NAT, since the external IP of your router is not a global address. That means at least two layers of NAT.
There is no particular reason to think, there is more than two layers of NAT involved. Also there is no way to know from the traceroute alone, where the next layer of NAT is.
The ICMP time exceeded messages from the intermediate routers, which is what traceroute is displaying, could originate from local or global addresses regardless of which side of the NAT they are on.
Quote from: RLH1985 on May 18, 2013, 07:31:47 AMOnly the next jump has a publicly routable IP address and that is the one the internet sees as mine.
Hang on. This is an unusual configuration. Usually routers have different IP addresses on their interfaces, and the IP address your traceroute would display for the NAT is for the interface facing towards you. The IP the outside world would see for you, would be the IP address of the interface facing away from you.
If 71.89.156.145 really is the external IP address of the CGN, that could still be explained in a few ways. It is possible the NAT has been configured with the same IP address on all interfaces. It is also possible it is simply using a pool of IP addresses, which include all of those assigned to each of its interfaces. It is also possible the NAT has only one interface and packets are routed back and forth over the same interface, but in that case the router that interface is connected to would need unusual routing rules. It is also possible the NAT is NATing the ICMP time exceeded errors sent to you, though I can't imagine what sort of NAT configuration would do that.
Quote from: RLH1985 on May 18, 2013, 07:31:47 AMOne would hope that an ISP who is in the situation of having to double NAT their customers would try to build out IPv6 quickly
They definitely should. Customers should not accept carrier-grade-NAT unless they are getting native IPv6 as well. If I had experienced that, I would have called them and told them I am not getting the service, I signed up for.
Quote from: RLH1985 on May 18, 2013, 07:31:47 AMtraceroute -t 41 209.51.181.2
Which traceroute version is that? On the traceroute version I have on this machine, the -t option sets the TOS, not the protocol number.
Quote from: kasperd on May 18, 2013, 10:04:51 AM
Quote from: RLH1985 on May 18, 2013, 07:31:47 AMOnly the next jump has a publicly routable IP address and that is the one the internet sees as mine.
Hang on. This is an unusual configuration. Usually routers have different IP addresses on their interfaces, and the IP address your traceroute would display for the NAT is for the interface facing towards you. The IP the outside world would see for you, would be the IP address of the interface facing away from you.
If 71.89.156.145 really is the external IP address of the CGN, that could still be explained in a few ways. It is possible the NAT has been configured with the same IP address on all interfaces. It is also possible it is simply using a pool of IP addresses, which include all of those assigned to each of its interfaces. It is also possible the NAT has only one interface and packets are routed back and forth over the same interface, but in that case the router that interface is connected to would need unusual routing rules. It is also possible the NAT is NATing the ICMP time exceeded errors sent to you, though I can't imagine what sort of NAT configuration would do that.
You're right here, it looks like that address is simply one of a pool of addresses. The IP that I'm seen at has been 71.89.156.145 in the past but right now it's 71.89.156.14
7. (I checked to make sure that my tunnel was updated with the change but it seems as though the DDNS service on my router already updated it.)
Quote from: RLH1985 on May 18, 2013, 07:31:47 AMtraceroute -t 41 209.51.181.2
Which traceroute version is that? On the traceroute version I have on this machine, the -t option sets the TOS, not the protocol number.
[/quote]
Here I seem to have made a mistake, it looks like the version of traceroute on my router doesn't support the -P switch. It only seems to support -p which sets the port and I'm guessing that's also incorrect. (I did however try it and the traceroute on port 41 worked just fine.)
So, I loaded up a Linux Live CD that I had around and tried the two traceroutes again. Here are the results for the test without the protocol flag:
root@kali:~# traceroute 209.51.181.2
traceroute to 209.51.181.2 (209.51.181.2), 30 hops max, 60 byte packets
1 Yggdrasil (192.168.2.1) 0.640 ms 0.523 ms 0.404 ms
2 192.168.6.1 (192.168.6.1) 1.683 ms 1.980 ms 2.049 ms
3 172.18.254.131 (172.18.254.131) 31.314 ms 31.135 ms 30.980 ms
4 vqwireless.com (71.89.156.145) 30.837 ms 30.686 ms 30.548 ms
5 dtr01dvsnmi-tge-0-1-0-0.dvsn.mi.charter.com (96.34.32.180) 48.203 ms dtr01dvsnmi-tge-0-1-0-1.dvsn.mi.charter.com (96.34.32.184) 48.635 ms dtr01dvsnmi-tge-0-1-0-0.dvsn.mi.charter.com (96.34.32.180) 48.701 ms
6 crr02sgnwmi-tge-0-7-0-7.sgnw.mi.charter.com (96.34.33.135) 50.810 ms crr02sgnwmi-tge-0-7-0-6.sgnw.mi.charter.com (96.34.32.187) 63.904 ms crr02sgnwmi-tge-0-7-0-7.sgnw.mi.charter.com (96.34.33.135) 63.862 ms
7 bbr01sgnwmi-bue-2.sgnw.mi.charter.com (96.34.2.58) 63.908 ms 64.648 ms 64.562 ms
8 bbr01aldlmi-tge-0-1-0-6.aldl.mi.charter.com (96.34.0.54) 72.998 ms 62.933 ms 62.782 ms
9 bbr01chcgil-bue-4.chcg.il.charter.com (96.34.0.99) 68.541 ms 68.712 ms 68.683 ms
10 prr01chcgil-bue-2.chcg.il.charter.com (96.34.3.9) 58.060 ms 58.053 ms 57.918 ms
11 v201.core1.chi1.he.net (216.66.73.241) 67.126 ms 67.241 ms 107.637 ms
12 tserv1.chi1.he.net (209.51.181.2) 99.313 ms 99.105 ms 95.353 ms
Here are the results
with the protocol flag set.
root@kali:~# traceroute -P 41 209.51.181.2
traceroute to 209.51.181.2 (209.51.181.2), 30 hops max, 60 byte packets
1 Yggdrasil (192.168.2.1) 0.551 ms 0.397 ms 0.345 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
It looks like the modem is killing my connection here. I see the router but nothing past it when using protocol 41. Is this something I can fix from here or am I going to have to contact my ISP?
Quote from: RLH1985 on May 18, 2013, 11:07:38 AMI did however try it and the traceroute on port 41 worked just fine.
Right, but protocol 41 and port 41 are two completely different and totally unrelated things.
Quote from: RLH1985 on May 18, 2013, 11:07:38 AMIt looks like the modem is killing my connection here. I see the router but nothing past it when using protocol 41.
From this output you can only deduce that the packets are dropped by 192.168.2.1 or 192.168.6.1.
There are routers, which can NAT protocol 41 traffic out of the box. There are other routers where it requires an explicit forwarding configuration. And there are routers, which cannot NAT protocol 41 traffic at all.
You know your router supports operation as a tunnel endpoint using protocol 41. I can tell you that simultaneously being a protocol 41 tunnel endpoint and NATing protocol 41 traffic is tricky. I don't know if there is any router, which supports it. In addition it is a more straightforward implementation, if decrementing the TTL is done before any consideration of NATing of the traffic. Which means it would be likely that the router, which is not capable of forwarding the traffic would still show up in the traceroute.
Based on that my best guess is that your own router is dropping the protocol 41 packets in the traceroute you just posted. So the easiest way to test what your ISP does to protocol 41 traffic is to connect that computer directly to the modem without the router in between (spoofing the MAC of the modem, if necessary), and then running the same two traceroute commands again.
Quote from: kasperd on May 18, 2013, 11:30:52 AM
Based on that my best guess is that your own router is dropping the protocol 41 packets in the traceroute you just posted. So the easiest way to test what your ISP does to protocol 41 traffic is to connect that computer directly to the modem without the router in between (spoofing the MAC of the modem, if necessary), and then running the same two traceroute commands again.
Here are the results for the test without the protocol flag:
root@kali:~# traceroute 209.51.181.2
traceroute to 209.51.181.2 (209.51.181.2), 30 hops max, 60 byte packets
1 192.168.6.1 (192.168.6.1) 4.617 ms 3.819 ms 3.740 ms
2 172.18.254.131 (172.18.254.131) 35.906 ms 38.575 ms 39.305 ms
3 vqwireless.com (71.89.156.145) 42.036 ms 44.871 ms 45.597 ms
4 dtr01dvsnmi-tge-0-1-0-1.dvsn.mi.charter.com (96.34.32.184) 87.743 ms 106.493 ms dtr01dvsnmi-tge-0-1-0-0.dvsn.mi.charter.com (96.34.32.180) 107.502 ms
5 crr02sgnwmi-tge-0-7-0-6.sgnw.mi.charter.com (96.34.32.187) 108.355 ms crr02sgnwmi-tge-0-7-0-7.sgnw.mi.charter.com (96.34.33.135) 108.284 ms crr02sgnwmi-tge-0-7-0-6.sgnw.mi.charter.com (96.34.32.187) 111.751 ms
6 bbr01sgnwmi-bue-2.sgnw.mi.charter.com (96.34.2.58) 112.533 ms 52.329 ms 57.907 ms
7 bbr01aldlmi-tge-0-1-0-6.aldl.mi.charter.com (96.34.0.54) 60.871 ms 28.838 ms 29.312 ms
8 bbr01chcgil-bue-4.chcg.il.charter.com (96.34.0.99) 43.694 ms 43.552 ms 44.208 ms
9 prr01chcgil-bue-2.chcg.il.charter.com (96.34.3.9) 40.186 ms 40.800 ms 41.368 ms
10 v201.core1.chi1.he.net (216.66.73.241) 64.044 ms 41.839 ms 35.311 ms
11 tserv1.chi1.he.net (209.51.181.2) 35.886 ms 36.505 ms 30.759 ms
Here are the results with the protocol flag set.
root@kali:~# traceroute -P 41 209.51.181.2
traceroute to 209.51.181.2 (209.51.181.2), 30 hops max, 60 byte packets
1 192.168.6.1 (192.168.6.1) 1.323 ms 1.020 ms 1.301 ms
2 172.18.254.131 (172.18.254.131) 15.164 ms 20.631 ms 19.416 ms
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
So, I guess my router was dropping the packets. However, now they're being dropped by another device up the line.
Quote from: RLH1985 on May 18, 2013, 12:02:59 PMSo, I guess my router was dropping the packets.
Yep. But that is not a problem, since you wanted the router to be a tunnel endpoint, so you didn't need it to forward the protocol 41 packets in the first place.
Quote from: RLH1985 on May 18, 2013, 12:02:59 PMHowever, now they're being dropped by another device up the line.
This is what we expected to see. We needed these two traceroute outputs to confirm the guess.
This is a problem. You should contact the ISP and let them know, that you are not satisfied. There are three different ways the ISP could solve your problem.
- Give you native IPv6, such that you don't need a tunnel.
- Give you access to a tunnel server within their own network, such that the tunnel does not have to go through their carrier grade NAT. Either 6in4 or 6rd could work for this tunnel.
- Give you a public IPv4 address, such that you can setup a tunnel to HE.
If you live in an area with competition between ISPs, you should consider switching to a better ISP, if they don't fix the problem, when you call them. If you are unfortunate enough to live in an area with no competition, you may need to consider other options. You can look into other tunnel protocols, which can work through NAT devices.
Unfortunately the beta which HE did with another protocol was discontinued. So you'd have to use another tunnel provider. SixXS supposedly support the widest range of protocols. They also have an infamous bureaucracy, which means signups are randomly rejected. It is worth a try, you may get lucky.
You could also pay for a dual stack VPS somewhere and set up your own tunnel server with whatever protocol is suitable for you. If you do this, make sure you get a VPS with a routed IPv6 prefix (preferably /63 or shorter).
Quote from: kasperd on May 18, 2013, 12:34:05 PM
Quote from: RLH1985 on May 18, 2013, 12:02:59 PMSo, I guess my router was dropping the packets.
Yep. But that is not a problem, since you wanted the router to be a tunnel endpoint, so you didn't need it to forward the protocol 41 packets in the first place.
Quote from: RLH1985 on May 18, 2013, 12:02:59 PMHowever, now they're being dropped by another device up the line.
This is what we expected to see. We needed these two traceroute outputs to confirm the guess.
This is a problem. You should contact the ISP and let them know, that you are not satisfied. There are three different ways the ISP could solve your problem.
- Give you native IPv6, such that you don't need a tunnel.
- Give you access to a tunnel server within their own network, such that the tunnel does not have to go through their carrier grade NAT. Either 6in4 or 6rd could work for this tunnel.
- Give you a public IPv4 address, such that you can setup a tunnel to HE.
If you live in an area with competition between ISPs, you should consider switching to a better ISP, if they don't fix the problem, when you call them. If you are unfortunate enough to live in an area with no competition, you may need to consider other options. You can look into other tunnel protocols, which can work through NAT devices.
Unfortunately the beta which HE did with another protocol was discontinued. So you'd have to use another tunnel provider. SixXS supposedly support the widest range of protocols. They also have an infamous bureaucracy, which means signups are randomly rejected. It is worth a try, you may get lucky.
You could also pay for a dual stack VPS somewhere and set up your own tunnel server with whatever protocol is suitable for you. If you do this, make sure you get a VPS with a routed IPv6 prefix (preferably /63 or shorter).
Thanks for your help, I'll try talking to my ISP and see if they can help me out a bit from their end. If I can't get anything from there, unfortunately I'm under contract for a year, I'll try SixXS. I actually still have a tunnel through them, though I disabled it when I moved to HE. My main issue with them was that the setup was quite a bit more difficult than HE's. I'm a bit more knowledgeable now than I was when I first tried setting that one up 18 months ago though so it may be worth it to try.
Quote from: RLH1985 on May 18, 2013, 12:48:49 PMunfortunately I'm under contract for a year
Is the contract binding, if they cannot deliver the service, you signed up for? If they called the product an Internet connection, I would say an IP address is part of the service you were promised, unless the conditions didn't clearly stated otherwise.
A reasonable minimum to expect today is either one public IPv4 address, or NATed IPv4 access plus a static routed IPv6 prefix.
Before you try to get out of the contract, you should of course ensure that you can get better service somewhere else. If you consider switching to another ISP, ask the new ISP about what addresses they will give you.
It might even be that your current ISP fixes the problem once you call them. Giving NATed access by default and a public address to anybody who ask for it would make sense for an ISP, as that would probably reduce their usage of IP addresses significantly. If they additionally give only one public address to those who ask for one, but multiple local addresses to those going through carrier grade NAT, then those who don't ask for a public address don't have to buy their own router.
Quote from: RLH1985 on May 18, 2013, 12:48:49 PMI'll try SixXS. I actually still have a tunnel through them, though I disabled it when I moved to HE. My main issue with them was that the setup was quite a bit more difficult than HE's.
Supporting different protocols will of course add to the complexity. Though it could be setting up SixXS access is more complicated than it needed to be.
Please update this thread and let us know how it turns out, both with your ISP and with SixXS configuration, if you give it a try.
Quote from: RLH1985 on May 18, 2013, 11:07:38 AMThe IP that I'm seen at has been 71.89.156.145 in the past but right now it's 71.89.156.147.
For the record, I did a traceroute to each of those IPs, and this is what I saw.
traceroute to 71.89.156.145 (71.89.156.145), 30 hops max, 60 byte packets
1 10.9.255.254 8.338 ms 8.348 ms 8.407 ms
2 212.10.10.1 8.459 ms 8.497 ms 12.154 ms
3 194.255.53.29 12.896 ms 13.315 ms 13.768 ms
4 * * 213.248.66.146 15.683 ms
5 213.248.66.145 15.450 ms 15.416 ms 15.411 ms
6 80.91.253.244 14.855 ms 80.91.254.222 10.816 ms 213.155.130.96 11.165 ms
7 80.91.254.89 96.838 ms 213.155.134.52 107.497 ms 213.248.64.22 97.596 ms
8 213.155.136.19 127.407 ms 80.91.249.110 126.429 ms 80.91.246.166 126.696 ms
9 62.115.14.42 133.588 ms 132.438 ms 132.122 ms
10 96.34.0.98 140.557 ms 140.514 ms 140.040 ms
11 96.34.2.11 137.133 ms 137.272 ms 134.050 ms
12 96.34.36.16 144.003 ms 134.582 ms 135.368 ms
13 96.34.34.9 141.022 ms 140.383 ms 134.445 ms
14 96.34.38.165 134.256 ms 138.718 ms 134.275 ms
15 96.34.33.134 130.251 ms 130.719 ms 131.677 ms
16 96.34.32.185 136.249 ms 96.34.32.181 131.499 ms *
traceroute to 71.89.156.147 (71.89.156.147), 30 hops max, 60 byte packets
1 10.9.255.254 7.836 ms 12.008 ms 12.600 ms
2 212.10.10.1 12.660 ms 12.759 ms 12.783 ms
3 194.255.53.29 12.935 ms 13.573 ms 14.112 ms
4 * * *
5 213.248.66.145 15.036 ms 15.485 ms 15.469 ms
6 213.155.130.96 15.433 ms 11.022 ms 213.155.135.182 10.534 ms
7 213.155.134.52 106.029 ms 80.91.254.89 95.195 ms 213.155.134.50 98.141 ms
8 80.91.249.110 126.350 ms 80.91.246.164 128.110 ms 127.092 ms
9 213.248.104.198 139.108 ms 137.691 ms 62.115.14.42 127.828 ms
10 96.34.0.98 131.669 ms 132.149 ms 140.643 ms
11 96.34.2.11 133.231 ms 132.057 ms 132.390 ms
12 96.34.32.26 144.327 ms 143.692 ms 142.343 ms
13 96.34.32.99 129.364 ms 139.045 ms 134.630 ms
14 96.34.32.55 140.475 ms 135.006 ms 146.366 ms
15 96.34.32.186 134.191 ms 135.972 ms 135.143 ms
16 96.34.32.181 134.722 ms 96.34.32.185 162.567 ms 155.093 ms
17 71.89.156.147 134.538 ms 135.427 ms 137.000 ms
One could try to figure out a bit more about the network from this. But whatever we make from these, it won't change your situation.