Hurricane Electric's IPv6 Tunnel Broker Forums

Advanced search  

News:

Welcome to Hurricane Electric's Tunnelbroker.net 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
1
Questions & Answers / Re: tserv11.ams1 down since this morning (CET)
« on: August 16, 2017, 05:51:18 PM »
Tunnels have been re-homed back to Amsterdam at this time.

2
Questions & Answers / Re: tserv11.ams1 down since this morning (CET)
« on: August 15, 2017, 11:58:51 AM »
Tunnels have temporarily been migrated to a London tunnel server until the primary Amsterdam server is back in service.  Part of the migration process temporarily disables the server migrated from, which is why it dropped off the status page briefly.

3
General Questions & Suggestions / Re: CAA records
« on: August 02, 2017, 02:47:33 PM »
257 is the CAA record number.  If it's showing up as "TYPE257" instead of "CAA", and therefore with the raw record data instead of a nicely formatted reply, that's a function of your DNS query client not supporting the record type.

As to the rest, email dnsadmin@he.net with the hostname you're seeing issues with.

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

5
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 ipv6@he.net to open a trouble ticket.

6
We do run 9000 MTU internally.

7
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.

8
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.

9
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.

10
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.

11
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

12
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.

13
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.

14
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.

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

Pages: [1] 2 3 ... 27