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!

Pages: [1] 2 3 ... 10
 1 
 on: April 28, 2017, 08:02:00 AM 
Started by maleks - Last post by royce
@kcochran, given the CA/B forum vote that @lasaine already cited, I'm working on a list of the status of provider CAA support here:

https://gist.github.com/roycewilliams/1710ade469c05eb0b090d268470aa741

Can you tell us whether there is an explicit feature request / RFE for CAA record support, and/or if there is an updated ETA from your post in January 2016?

[ Edit: fixed typo in handle for kcochran / @kcochran ]

 2 
 on: April 27, 2017, 11:35:44 PM 
Started by snarked - Last post by snarked
Either for the HE app and/or for the tunnel-broker web site:

It would be nice for a person to be able to ping the "nearby" tunnel endpoints (as an automated tool) in order to determine which endpoint(s) appear to be the nearest.  Due to the way network peering with other ISPs is done, the geographically nearest endpoint may not be the nearest in network latency terms.  Existing tunnel-broker clients could use this to compare their current tunnels to that of alternatives, especially when new endpoints are enabled.

By "nearby", I would suggest limiting a given ping to those endpoints on a given continent.  Users in North America and Europe, having multiple endpoints (10+ each), would benefit the most.

For example, someone in Las Vegas, NV (USA) would expect Los Angeles, Denver, or Phoenix to be the closest, but if his ISP doesn't peer with HE in the western U.S., the closest may be an east-coast tunnel server.  Such a person would use the proposed tool to ping ALL North American sites and get the latency results.

Of course, users should still manually choose their tunnel endpoints.  Adding such a tool will enable such users to make a more informed decision.

PS:  I am aware that the "looking glass" can ping, but it is limited to 3 sites, and furthermore, it lists HE's router sites, not necessarily the tunnel-broker endpoints.

 3 
 on: April 23, 2017, 09:22:49 PM 
Started by phipac - Last post by chcenter

You just use IPV6ADDR_SECONDARIES to add as many ip you need

---extras from ifcfg-eth0 file---
IPV6INIT=yes
IPV6ADDR_SECONDARIES=2001:xxxx:xxxx::11f/124
IPV6ADDR=2a06:xxxx:0:x::2/120
IPV6_DEFAULTGW=2a06:xxxx:0:x::1

 4 
 on: April 23, 2017, 12:45:00 PM 
Started by desunet - Last post by desunet
Seems to be back to normal:

Code: [Select]
traceroute to cloudflare.com (2400:cb00:2048:1::c629:d7a2), 30 hops max, 80 byte packets
 1  edgeroute.desu.ne.jp (2001:470:e955:1::1)  0.960 ms  1.191 ms  1.518 ms
 2  desunet-1.tunnel.tserv14.sea1.ipv6.he.net (2001:470:a:c9c::1)  21.799 ms  16.891 ms  12.076 ms
 3  ve225.core1.sea1.he.net (2001:470:0:9b::1)  22.891 ms  23.449 ms  23.452 ms
 4  13335.se.equinix.com (2001:504:12::1:3335:1)  23.457 ms  23.438 ms  23.408 ms
 5  2400:cb00:28:1024::a29e:6832 (2400:cb00:28:1024::a29e:6832)  23.388 ms 2400:cb00:28:1024::a29e:687a (2400:cb00:28:1024::a29e:687a)  23.363 ms 2400:cb00:28:1024::6ca2:f458 (2400:cb00:28:1024::6ca2:f458)  23.339 ms

 5 
 on: April 23, 2017, 07:49:26 AM 
Started by fabrix - Last post by cholzhauer
Normally 6in4 won't work with CGN. 

 6 
 on: April 22, 2017, 07:06:36 PM 
Started by fabrix - Last post by fabrix
I had everything configured to use tunnel broker and I had it working. my router had an IP address that I could use with the DDNS and what not, just recently the address of the router changed to an ipv4 private address ex. 192.168.0.2 now I have to reconfigure the settings because it is saying that the DDNS cannot use a private IP address. I have been looking around to see if I could find an answer for the changes that need to be made but could not find much that was helping.
Does anybody have any ideas on how to make it work again?
I would appreciate your help.

 7 
 on: April 21, 2017, 08:00:07 PM 
Started by desunet - Last post by desunet
For some reason, Cloudflare's anycast IPs are routing through Germany:

Code: [Select]
traceroute to cloudflare.com (2400:cb00:2048:1::c629:d7a2), 30 hops max, 80 byte packets
 1  edgeroute.desu.ne.jp (2001:470:e955:1::1)  1.334 ms  1.545 ms  1.003 ms
 2  desunet-1.tunnel.tserv14.sea1.ipv6.he.net (2001:470:a:c9c::1)  17.089 ms  12.327 ms  21.911 ms
 3  ve225.core1.sea1.he.net (2001:470:0:9b::1)  26.343 ms  26.878 ms  26.881 ms
 4  100ge10-2.core1.msp1.he.net (2001:470:0:2a0::2)  63.758 ms  64.423 ms  64.113 ms
 5  100ge13-1.core2.chi1.he.net (2001:470:0:18e::1)  62.497 ms  62.465 ms  62.848 ms
 6  100ge3-2.core1.nyc4.he.net (2001:470:0:298::2)  100.217 ms  99.758 ms  91.656 ms
 7  100ge7-2.core1.lon2.he.net (2001:470:0:2cf::1)  174.850 ms  172.179 ms  164.847 ms
 8  100ge7-1.core1.fra1.he.net (2001:470:0:37::2)  154.861 ms  153.743 ms  154.023 ms
 9  cloudflare.anc.kleyrex.net (2001:7f8:33::a101:3335:1)  149.524 ms  149.655 ms  150.100 ms
10  2400:cb00:71:1024::a29e:57d6 (2400:cb00:71:1024::a29e:57d6)  154.868 ms 2400:cb00:71:1024::a29e:5238 (2400:cb00:71:1024::a29e:5238)  155.384 ms  154.182 ms

With IPv4, I get the proper endpoint in Seattle:

Code: [Select]
traceroute to cloudflare.com (198.41.214.162), 30 hops max, 60 byte packets
 1  edgeroute.desu.ne.jp (44.26.108.1)  1.579 ms  1.535 ms  1.850 ms
 2  44-24-246-0.ip.hamwan.net (44.24.246.0)  6.902 ms  6.807 ms  6.972 ms
 3  209.189.196.65 (209.189.196.65)  7.993 ms  10.623 ms  10.618 ms
 4  ge0-0-0-1-thbr06.threshinc.net (209.189.202.199)  10.591 ms  10.586 ms  10.573 ms
 5  six.as13335.com (206.81.81.10)  10.552 ms  10.105 ms  10.075 ms
 6  198.41.214.162 (198.41.214.162)  9.771 ms  6.900 ms  7.033 ms

This results in poor bandwidth (about 2 megabits/second) and applies to every Cloudflare site I tried that had an AAAA record for its domain, such as medium.com (same traceroute through Frankfurt).

Is anyone else seeing this?

 8 
 on: April 20, 2017, 03:33:11 PM 
Started by pimzand - Last post by divad27182
If you look in the "Packet Details" frame (the middle one), you should see both "Internet Protocol Version 4" and "Internet Protocol Version 6".  The former is the IPv4 header saying it's content is protocol 41.  The later is the protocol 41 content, which is to say the first IPv6 header.  Since Wireshark always shows the most decoded form, you will see this as IPv6 traffic.  If you really wanted to, you could disable the IPv6 decoder.

--David

 9 
 on: April 20, 2017, 03:24:12 PM 
Started by KNBu5ZMdbR - Last post by KNBu5ZMdbR
Ok.   I figured it out.  The Example Configurations page says:

> NOTE: When behind a firewall appliance that passes protocol 41, use the IPv4 address you get from your appliance's DHCP
> service instead of the IPv4 endpoint you provided to our broker.

when I removed the "local" line entirely, ifup'd and ifdown'd the interface and started radvd, things worked again.

Phew.  I'm crazy about IPv6 and use it all over the place, even my printer is addressed by ipv6.  So I'm lost without it.

 10 
 on: April 20, 2017, 09:05:43 AM 
Started by KNBu5ZMdbR - Last post by KNBu5ZMdbR
I think it's no longer a service and can't be stopped.  Here are the settings I have:


$ sudo ip6tables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Pages: [1] 2 3 ... 10