Hurricane Electric's IPv6 Tunnel Broker Forums

Please login or register.

Login with username, password and session length
Advanced search  


Welcome to Hurricane Electric's forums!

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - kcochran

Pages: [1] 2 3 ... 27
Advancing the available tunnel MTU beyond 1480 isn't something we're investigating at this time.

As to peers, if it's across a public IX, odds are that isn't an option as most public exchanges exist at the traditional MTU value.  A few exchanges have a 9000 MTU option, but tend to not have many members exist on the jumbo frame VLAN.  Jumboframes on a direct connection is do-able, however.

News & Updates / Update - 30 March 2017
« on: March 30, 2017, 08:29:13 AM »
We have added additional regular tunnel-servers in the following locations:
  • Honolulu, Hawaii, United States
  • Lisbon, Portugal
  • Johannesburg, South Africa
They are now live and available to choose when creating a tunnel. Again if you would like your existing tunnel's IPv4 endpoint to use one of the new tunnel-servers, please delete your existing tunnel then pick the new location to create your tunnel on.

*REMINDER* - Deleting your old tunnel means deallocating your IPv6 blocks, and you will be assigned NEW allocations based on the tunnel server you pick.

If you have any problems and want to report them, please email to open a trouble ticket.

We do run 9000 MTU internally.

The best place to run something like this is via whatever scripts may also run when your IPv4 address changes.  If you run the query too frequently, you may get blocked for abuse.

Questions & Answers / Re: Carrier grade NAT on 4G
« on: February 21, 2017, 04:32:37 PM »
6in4 doesn't have the typical IPv4 TCP/UDP headers, so most NAT implementations don't get enough information to determine a flow to pinhole permit the traffic.  As such, 6in4 tunnels almost never work through a CGNAT environment.  There's no initial handshake with a 6in4 tunnel, each end just flings the IPv6 traffic at the other side with an IPv4 IP header slapped on top.

IPv6 Basics & Questions & General Chatter / Re: geo-ip for HE Subnets
« on: February 05, 2017, 12:18:02 PM »
Basic location data (city, state, country) is in the rWHOIS data associated with the tunnel's IPv6 assignments, per RIR requirements, and suitable for use by external tools.  IPv6 assignments are also from a pool specific to a tunnel server, and those have never been re-used or moved between servers.

That said, GeoIP vendors tend to use their own heuristics to determine location, and not use public information.  Additionally, tunnels, due to their very nature, tend to create errors in those heuristics.  For example: latency checks can be off if your location is widely divergent from the tunnel server, or your ISP's connectivity to us is not close to either your IPv4 side or the tunnel server.

IPv6 on Linux & BSD & Mac / Re: Address unreachable
« on: December 14, 2016, 09:13:14 AM »
6in4 tunnels are stateless.  There's nothing on our side to remember or forget, beyond the IPv4/IPv6 address of your side, and those are ultimately statically configured.  If you have to send out traffic to get the tunnel operating again, there's likely a stateful firewall for IPv4 involved on your side.  If you've got an IPv4 firewall configured on VPS1, ensure it has explicit permits for the tunnel server's IPv4 address, and isn't relying on something like conntrack.

As we've been seeing a number of emails recently on this from people getting their apps rejected due to the IPv6 requirements Apple put in place earlier in the year, I'm putting up some resources for those who might need it.  Here are some of Apple's own resources on things to do for your app to conform to the submission requirements.

Properly put, the Apple requirement is that an app must be able to work on an IPv6-only network.  This means no usage of IPv4-only APIs, no IPv4 literals, and avoidance of some pre-flight checks.  It must be able to work in a NAT64 environment.  You do not need IPv6 support on the server-side yet.  If they required that now, people hosting on AWS or GAE would be in trouble.  However those services would then have more calls to finish up their implementations.  That said, it's still a good idea to work towards server-side support.

Apple's Tech Note on IPv6 networks, and app requirements

WWDC 2015 Video on the same, and the NAT64 implementation in El Capitan

Questions & Answers / Re: Need to change server address
« on: October 09, 2016, 10:00:24 PM »
IPs are tied to the tunnel server they're assigned from.  The deaggregation resulting from portability between tunnel servers would quickly grow unwieldy.

Questions & Answers / Re: IPv6 over IPv6 to get /48
« on: September 06, 2016, 12:09:45 PM »
In order to use our service, you need IPv4 connectivity.

Questions & Answers / Re: Prague Server
« on: June 20, 2016, 12:00:06 PM »
Prague tunnels are temporarily anchored in Berlin until an issue with the Prague tunnel server is resolved.

Double check your outgoing default route.  I can ping you from within the subnet, but not externally.  Routing all looks right on this side.

Questions & Answers / Re: Netflix blocking
« on: June 05, 2016, 09:52:58 PM »
Nothing has changed on our side.  The tunnels work as they always have: RFC 6in4.  IP assignment information, including basic user geographical location (city, state, country), is updated periodically throughout the day on the public rWHOIS server, as it has been for many years, and as we're required to do by ARIN for end-user assignments.

Just as an additional addendum: there's no central repository for geolocation<>IP data.  Anyone telling you otherwise is trying to sell you something (possibly geolocation services).  The closest thing to such is the regional registry's data of who has been allocated which blocks of IPs.  At best that tells you where the business is located, but doesn't mean anything in regards to any end-user's location using that IP.  We publish reasonably anonymized location data (city, region, country) in rWHOIS for all tunnel allocations and services are welcome to use that data.  There was a push for a while from Google in the IETF[1] for an ISP provided location/IP map feed specification, however it looks like that proposal died as it expired over two years ago.


We don't publish your side's IPv4 address in any records.

You can either setup a hostname in the FreeDNS service, or use one of the tunnel information APIs to retrieve your IPv4 address. (

Pages: [1] 2 3 ... 27