Hurricane Electric's IPv6 Tunnel Broker Forums

Please login or register.

Login with username, password and session length
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
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.

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

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

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

5
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

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

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

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

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

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

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

[1] https://tools.ietf.org/html/draft-google-self-published-geofeeds-02

12
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. (https://forums.he.net/index.php?topic=3109.0)

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

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

15
Questions & Answers / Re: ipv4.tunnelbroker.net 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 127.0.0.1" is a bad result, it should read your IPv4 address. Maybe it should say bad instead of good? :)

From https://help.dyn.com/remote-access-api/return-codes/, which we base our replies on:
Quote
good 127.0.0.1    

This answer indicates good update only when 127.0.0.1 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.

Pages: [1] 2 3 ... 27