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 5 ... 28
31
Questions & Answers / Re: Reissue Forums Cert - Improve Forums SSL Security
« on: November 02, 2015, 09:25:52 AM »
Should be a solid A now.

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

33
Questions & Answers / Re: tunnel broker endpoint update broken?
« on: October 14, 2015, 10:43:04 PM »
IP isn't pingable.

"good 127.0.0.1" is normally how Dyn-like APIs report that the update wasn't performed due to the remote side not following specifications.

34
General Discussion / Re: Stuck on Admin Cert
« on: October 14, 2015, 08:11:23 PM »
Yes, that would cause the v6 host to be tried first.  MX priority is a little weird in that usually you would think higher priority wins.  This is why some have taken to calling it "distance" since then it's that the shorter distance wins.

That said, if you had one record, with both a v4 and v6 address, you'd see roughly the same effect.  RFC6724 defines a priority order for client systems to try addresses when multiple are available.  In the general case, it causes IPv6 addresses to be tried before IPv4 (except for addresses involved with deprecated transition technologies such as 6to4, unless the other side is also 6to4, etc., etc.).

35
General Discussion / Re: Stuck on Admin Cert
« on: October 14, 2015, 05:12:22 PM »
If I run drill against mail.cerberus.network, I do have an answer section. Does that mean I need to swap the values for the MX record? v4 is working fine the way it is.

The MX record should be on the hostname you're testing against, and the one expected to receive email.  It'll work generally, as when no MX records are defined, the hostname is documented to be used as a fallback with MX priority 0.  We do not attempt that fallback for this test.  Having an MX is more efficient than relying on the fallback behavior, as having a defined MX means a single DNS query, versus potentially 3 (MX, fail, then an A and AAAA query).  It also makes a clear indication that the domain does mail service.

36
Questions & Answers / Re: Possible Routing Problem in HE Network
« on: October 08, 2015, 07:26:18 PM »
Traceroutes can be tricky to see where something stops, since where it actually stops, you don't get replies.  Hop 8 is the peering handoff to Pandora, so a lack of reply there isn't terribly unexpected.  Everything further is within Pandora's network, and it appears they may be filtering that traffic out.  In any case, I'm able to hit a webserver on that IP:

Code: [Select]
> telnet -6 mediaserver-ch1-t1-1-v4v6.pandora.com 80
Trying 2620:106:e002:f00f::21...
Connected to mediaserver-ch1-t1-1-v4v6.pandora.com.
Escape character is '^]'.

37
Questions & Answers / Re: Tunnelbroker.net API Documentation
« on: September 19, 2015, 11:16:04 PM »
Bug in the script.  Should be better.

39
Uhm, did you just set up your /48 w/o the client-side IPv6 address?

40
Questions & Answers / Re: "Request Error" with DDNS update
« on: August 22, 2015, 06:20:24 AM »
Adjustments have been made to cope with the flood of invalid requests, so the valid ones should be processed as normal at this time.

As a note, the vast majority of invalid requests use hostnames instead of tunnel IDs, and IPv4 endpoints that are obviously internal to a NAT.  When configuring your update on your devices, make sure you're using the proper values!  Also only update when there's a change.

41
Questions & Answers / Re: "Request Error" with DDNS update
« on: August 17, 2015, 11:49:39 AM »
We've seen an incredible increase in the number of requests from the "ez-ipupdate" agent, of which virtually all are invalid (RFC1918 IP updates, invalid hostnames, bogus data, update intervals of a minute or less, etc.)  A less blanket block on that agent is in the works, but when 99.9% of the requests are bad and at a very high rate, we had to do something in the meantime.

42
General Discussion / Re: Could not grab the file via IPv6 HTTP
« on: July 09, 2015, 07:40:27 AM »
Should be happier with SNI now.

43
General Discussion / Re: Could not grab the file via IPv6 HTTP
« on: July 08, 2015, 11:21:24 AM »
Yes, the test seems to dislike SNI at this time.  I'll make a note of it, and see if that can be improved.

broquea: I've made a few changes from when you last took it.  ;-)

44
IPv6 on Routing Platforms / Re: Cannot ping from Dlink 636L
« on: June 23, 2015, 10:56:46 AM »
U-verse released updated firmwares a year or so ago which wound up breaking 6in4 tunnels.  That said, in theory, they've deployed and enabled 6rd to many of their locations, so you might actually have v6 direct from AT&T available at this time.  Settings / LAN / IPv6 would be the place to check.

45
General Questions & Suggestions / Re: Some problems in my zone
« on: June 22, 2015, 02:21:02 PM »
CNAMEs override all other records at that level.  As such, your MX (along with everything else at that level) is masked by the CNAME.  Remove the CNAME, and the MX should become visible again.

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