Hurricane Electric's IPv6 Tunnel Broker Forums

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 4 ... 28
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. (

Questions & Answers / Re: Tunnel in ZRH stopped working
« on: February 15, 2016, 04:57:18 PM »
I see traffic going out to you, but nothing coming back.  Did your local IPv4 endpoint change?

If there was a server there, odds are Netflix would still think you're in the US.  They're not so good on the geolocation with tunnels.

Questions & Answers / Re: client ip update problem
« on: January 12, 2016, 10:04:56 AM »
That was it! They unblocked ICMP and I was able to update my IPv4 address on the tunnel broker. For the record, "good" is a bad result, it should read your IPv4 address. Maybe it should say bad instead of good? :)

From, which we base our replies on:

This answer indicates good update only when address is requested by update. In all other cases it warns user that request was ignored because of agent that does not follow our specifications.

General Questions & Suggestions / Re: CAA records
« on: January 07, 2016, 07:34:54 AM »
Not currently supported by the backend, and their roadmap doesn't have it as a high priority.

CAA records, while noted as a possible cross-check on wikipedia, seem to not be headed that way based on the feature requests for FF and Chrome.  The use case for CAA records seems to have focused on CAs being the consumer of the record prior to cert issuance (and mandating use of them when available as part of the requirements to remain in the root cert store on those browsers), and then any DNS-based cert verification on the client-side would be handled by DANE.

News & Updates / Two-factor Authentication
« on: January 04, 2016, 04:47:58 PM »
We've made some adjustments to the two-factor implementation to now include backup verification codes.

If you have two-factor enabled on your account, you should now see a section under it labeled: "Backup codes"

"Show codes" will show you the currently available and unused backup codes for your account.
"Reset codes" will generate a completely new set of ten backup codes for your account.

Each of these codes may be used once.

These codes exist as a means of getting into your account if you've misplaced or lost your phone with the authenticator application on it.  You may use them anywhere an authentication code is expected.

As a side note, the iOS version of the HE Network Tools app will sync TOTP credentials in iCloud Keychain, if enabled, and therefore can be an option if you tend to be prone to phone loss/damage/etc.  (HOTP based credentials are not synced, as they could get out of step)

General Discussion / Re: Daily Tests - DIG PTR
« on: December 31, 2015, 12:08:14 PM »
Bug in that dig output.  Note the TTL running into the record class.  (84362IN on the -x query).

As to hostnames, try to use ones which might not result in geographically specific IPs depending on where you're doing your query.  We run the same query on this side and compare results.  If you're querying a major site like Google, you'll tend to get an IP for a facility near you, and we'd get one near us.  Those two facilities might not always be the same.

Pages: 1 [2] 3 4 ... 28