Hurricane Electric's IPv6 Tunnel Broker Forums

Advanced search  

News:

Welcome to Hurricane Electric's Tunnelbroker.net forums!

Pages: 1 ... 8 9 [10]
 91 
 on: April 08, 2020, 10:34:18 PM 
Started by h4x0r - Last post by h4x0r
Dear Hurricane!

Love the service and very happy member for many many years.

I am just making an enquiry today as to whether Hurricane Free DNS actually supports my (newer) Top Level Domain, ie: .productions

We are hoping to hear good news on the topic.

Thanks in advance!

 92 
 on: April 07, 2020, 09:56:49 PM 
Started by nefas - Last post by nefas
Hi folks,

Long time lurker, first time poster.

So I've been a member of the HE community for a fair spell (Sage earned in 2011, that seems like so long ago). I've been on and off with my tunnelbroker tunnel, and have deleted it a few times, etc. Up until the last few months I had a forward thinking ISP that had dualstack so that was nice, but due to cost I couldn't keep that connection, so I came back to my previous ISP + HE.NET / Tunnelbroker.

Here's where things go weird. On IPv4, when I go to Google, I get the normal www.google.com page everyone knows and loves. If I re-enable IPv6 in FF and go there, it redirects me to google.com.hk which is (of course) Google Hong Kong. Now I'm not sure if something dicey is going on here, or maybe Google just sees that IPv6 block I'm coming from and thinks its HK for some reason, or what.

I will say that ifconfig.co / whatismyip / and similar Geo sites all see the correct location of Fremont, CA (I use 66.220.7.82 as my tunnel endpoint).

Here's my IPv6 /64 and /48 prefix:

2001:470:1f19:xxxx::/64
2001:470:xxxx::/48

Obviously traceroutes don't do any good:

traceroute to google.com (2607:f8b0:4007:80d::200e), 30 hops max, 80 byte packets
 1  2001:470:xxxx:xxxx::1 (2001:470:xxxx:xxxx::1)  1.036 ms  1.007 ms  0.969 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  lax28s10-in-x0e.1e100.net (2607:f8b0:4007:80d::200e)  31.597 ms  31.432 ms  31.433 ms

Does anyone have any ideas? I've never seen this issue before with HE, and I was considering just nuking my /48 and redoing the config to see if that helps at all.

 93 
 on: April 07, 2020, 12:28:21 PM 
Started by revolt112 - Last post by revolt112
Is there a possibility that HE is interventing on this? I have major problems surfing on the web.

I found serveral IP geolocation services where HE's IPv6 Prefix for /48 is located in Iran

 94 
 on: April 05, 2020, 07:09:53 AM 
Started by kasperd - Last post by kasperd
I came across this post on Twitter which says Hurricane Electric's stance is that NAT64 hinders IPv6 adoption:
https://twitter.com/treysis/status/1229429649668792320

Does Hurricane Electric have an official stance on NAT64?


I know that Hurricane Electric used to operate a NAT64 gateway. But that is no longer available (though DNS64 is still up.)


I don't believe that NAT64 hinders IPv6 adoption. I am running https://nat64.net/ because I believe that a public NAT64 service has the potential to speed up IPv6 adoption. And I hope there are ISPs and transit providers who are interested in working together on making that happen. At the moment I do have some tunnelbroker.net tunnels among the more active users.

For those reasons I am quite interested in hearing whether the above post is in fact representative of Hurricane Electric's official stance. And if it is, I am wondering if there is anyone I could have dialogue with to understand why we have such different ideas of the effect of NAT64 services.

 95 
 on: April 05, 2020, 05:43:27 AM 
Started by kumy - Last post by kasperd
What I understand from a machine translation of that article is that the root problem is that Free have decided to run their network with only a single transit provider. That transit provider is Cogent.

As a tunnelbroker.net user you also only have a single transit provider. That transit provider is Hurricane Electric.

Cogent and Hurricane Electric aren't able to reach an agreement. From the information I have read on the subject it sounds like Cogent takes most of the blame for that dispute. You are welcome to take that last statement with a grain of salt, after all this forum might be skewed slightly in the favor of Hurricane Electric.

If you as a tunnelbroker.net user want multiple transit providers you would have to get your own addresses and BGP tunnels through different providers. I know of three providers who offer BGP tunnels. Doing BGP announcements with the addresses you received through a standard tunnelbroker.net tunnel would as far as I recall be a violation of the terms of service.

Until recently there was a direct peering between Free and Hurricane Electric, which is why the connection used to work. But for reasons which are not clear Free shut down that peering.

 96 
 on: April 05, 2020, 05:24:25 AM 
Started by ciroiriarte - Last post by kasperd
In such a configuration you will have a separate prefix from each tunnel. Assuming both of your routers send advertisements on the LAN you will end up with each device on the LAN having IP addresses from each prefix.

The ideal way to get redundancy in such a configuration is that each client device simply keep track of which IP addresses it got from which router. When the device needs to send packets through the default route it will look at the source IP address and send it through the router from which it got that IP address. If the devices do that, then applications running on the device can try both routers by creating two sockets which it binds to different local IP addresses before attempting to establish connections to the server.

In reality you cannot expect to see this ideal behavior with current implementations. More likely applications won't try multiple addresses and will rather just let the kernel pick a single one. And packets will likely be routed to the same router regardless of which source IP address is being used. And there is a high probability the tunnel provider will drop packets using IP addresses from the other tunnel. If you are lucky the kernel's choice of IP address matches its choice of gateway.

You can work around the dropped packets by configuring policy routing on both routers. Packets with a source IP belonging to the other router need a default route sending them to the other router. All other packets will need a default route sending them through the tunnel. The rest of the routing table just needs to be identical for all packets. Only the default route needs to depend on policy.

 97 
 on: April 05, 2020, 04:59:55 AM 
Started by Pentium4User - Last post by kasperd
Well, which miredo-Server are you using?
The answer to that is actually in the ping output. It says c38c:c38c which is teredo.trex.fi.

I see the same issue with teredo.remlab.net which is the one Miredo use by default.

So it probably isn't a problem with the Teredo server. More likely it's a problem with the Teredo relay heise.de is using, and since that Teredo relay isn't responding I cannot say with certainty which relay they are using.

To identify the relay you need to get the output of a traceroute6 command run on the heise.de server towards your Teredo address (should look the same regardless of which Teredo address they try).

The chances of getting this issue resolved are tiny as most network operators seem to not care about Teredo and many of them don't have a clue how it works.

 98 
 on: April 05, 2020, 04:35:05 AM 
Started by deags - Last post by kasperd
@kasperd
We also made a list of public NAT64 gateways: https://nat64.xyz
I found that list already. On Tuesday I added a link to it from my list and also sent some updates for that list.

 99 
 on: April 05, 2020, 03:30:24 AM 
Started by revolt112 - Last post by tjeske
In case you haven't found it yet, MaxMind even has a dedicated webform to submit correction requests:
https://support.maxmind.com/geoip-data-correction-request/

 100 
 on: April 05, 2020, 03:23:12 AM 
Started by revolt112 - Last post by revolt112
teamviewer seems to use maxmind, i already contacted support. Thanks

Pages: 1 ... 8 9 [10]