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 5 ... 27
Questions & Answers / Re: tunnel broker endpoint update broken?
« on: October 14, 2015, 10:43:04 PM »
IP isn't pingable.

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

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

General Discussion / Re: Stuck on Admin Cert
« on: October 14, 2015, 05:12:22 PM »
If I run drill against, 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.

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 80
Trying 2620:106:e002:f00f::21...
Connected to
Escape character is '^]'.

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

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

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.

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.

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.

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

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.

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.

44 is based off data from public sources, and not views from within HE itself, as to avoid bias.

A network (normally) announces its own routes, and the routes of its customers to a peer.  A network (usually) would announce its complete routes (including those learned from a peer) to a customer.  There are some variances on these, but that's pretty much the rule for 99.9% of those relationships.

So in the case where you have networks A and C peering with B: A sees B's routes, and B's customer's routes; C sees B's routes and B's customer routes; and B sees both A and C's routes and A and C's customer routes.  If B announces A to C, then B is providing transit for A.  If this is not something intended by A, then this is a leak, and extremely poor form for B to do and is a big faux pas (and sometimes cause for A to depeer B).

'Static'.  As SLAAC assigns usually based on the machine's MAC address and you wind up changing out a NIC, your address will change.  If you really want static, RA and DHCPv6 if you're looking for more centralized management.  SLAAC for systems that don't provide services, DHCP for those that do.

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