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

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

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

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

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

21
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

22
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)

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

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

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

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

27
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 HOTP/TOTP credentials in iCloud Keychain, if enabled, and therefore can be an option if you tend to be prone to phone loss/damage/etc.

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

29
Questions & Answers / Re: Reissue Forums Cert - Improve Forums SSL Security
« on: November 02, 2015, 09:25:52 AM »
Should be a solid A now.

30
Barring any policy routing, routing would work as it normally does.  Find the most-specific matching route to the destination in the routing table.  This would mean return traffic from tunnel IPs would try to go out the default route.  If that's set to Comcast, uRPF or similar filters on their side should realize that's not an IP they should see traffic from over your link, and discard it.  Similar thing if the default was pointed out the tunnel and the source was a Comcast assigned IPv6 address.

Now, depending on the tools available on your side, you might be able to set up policy routing, where you explicitly tell your side's routing that traffic from A should go out default-A and traffic from B should go out default-B.

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