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

Pages: [1] 2 3 4
On my main actual interface, I gave a static IPv6 ip '2001:470:1f06:282::4' to the interface. And for the gateway IP, I gave the IPv6 ip which is working on my Linux machine in this case '2001:470:1f06:282::2', is that what I was supposed to do?

I believe 2001:470:1f06::/48 is the transit networks off the New York City tunnelbroker.  You cannot give any other addresses on that subnet.  i.e. 2001:470:1f06:282::4 is improper.  You are assigned a second subnet, probably 2001:470:1f07:282::/64 that you may allocate addresses in, and have your machine that is 2001:470:1f06:282::2 route to and from.

IPv6 on Routing Platforms / Re: BGP Default Route Only
« on: October 17, 2017, 08:52:54 AM »
BGP is what you do to not have default routes.  You could tell BGP to not set the routes on your local machine, but you would probably only do that if you are doing some routing research (and you aren't).

Questions & Answers / Re: Problems configuring Tunnel
« on: October 15, 2017, 07:37:41 PM »
Im using just Lan 1 by the way, the Lan 2 is not used at all!

If you have and are not using the /48, you should cancel the request for it.  Those are a somewhat limited resource and you should not get one and not use it.

Questions & Answers / Re: Problems configuring Tunnel
« on: October 07, 2017, 06:50:09 PM »
And the fact that they DON'T delegate, but DO have well setup DNS, means that JDH1986JDH could just use domain name
for his server.  Admittedly, if he changes his configuration before completing certification, he might need to do the reset operation and start over.

edit: Not sure if that's his current address.  He later showed one for a different account.

Questions & Answers / Re: Problems configuring Tunnel
« on: October 07, 2017, 06:42:03 PM »
Actually, if you only intend to have one machine there, then the hassle is setting up the routed /64.

I've actually considered doing just this with my laptop.  I haven't, but I might.  Actually, I sort of wish that you could request no routed /64, and a tunnel /126.  Then I wouldn't feel I was wasting resources.

Questions & Answers / Re: Problems configuring Tunnel
« on: October 07, 2017, 06:33:33 PM »
You need to assign an IPv6 address to your LAN've only assigned one to your tunnel.

Make sure you use an address out of your routed /64, not the tunnel /64

Actually, it is perfectly valid to use the tunnel /64 address, as long as you use your end of it.  It may not be ideal, but it is valid, and if you don't want to setup another /64, then you do not need to.

Indeed, if you can get an IPv6 address out of (or any other IPv6 tester), that will do to identify your machine.

JDH1986JDH: You should be aware that later tests are that you have an IPv6 reachable email server, and that it has IPv6 DNS.

IPv6 on Linux & BSD & Mac / Re: Tunnel on Mac OS X 10.12.6
« on: September 23, 2017, 10:34:19 AM »
It sounds like a DNS problem to me.  "not found" and "can't find" seem indicative.  I would expect a different error if it can't reach the server.

Did you change your DNS as part of the setup?  and if so, did you forget to restart the browser?

Was the browser started when you only had IPv4, so that it is only querying for IPv4 addresses?

IPv6 Basics & Questions & General Chatter / Re: ipv6 via gray ip
« on: September 03, 2017, 05:48:38 PM »
hi. how to make ipv6 if my provider give me inet with ip address (aka grey ip address)? so only dedicated ip4 address can help avoid this trouble? thanks
  • It is called a "Private Use" address, not "grey".
  • If they use a one-to-one NAT, you might be able to do it with a tunnel.  Try repeatedly (including with hours delay).  Try other address reporting services.  If it never changes, you might have one-to-one NAT.  Or maybe the provider only has one public address.
  • Your best bet may be to see if your provider provides IPV6.  Try the autoconfiguration methods, and DHCPv6.  And ask them.  And if they don't provide IPv6, ask them to.

wget -O - | sh

Of course, if you have ANY security concerns, you will not do this at all!

Questions & Answers / Re: Tunnel wont start. General Trouble Shooting?
« on: August 18, 2017, 06:10:30 PM »
Can you paste the output of ifconfig and the commands you used to start the tunnel?

Is your ISP blocking proto41? Is your router?
# ifconfig
eno1      Link encap:Ethernet  HWaddr f8:b1:56:cd:d5:1a 
          inet addr:  Bcast:  Mask:
          inet6 addr: 2001:470:d:bb3::1/64 Scope:Global
          inet6 addr: fe80::194e:35aa:8817:f95a/64 Scope:Link
          RX packets:39178902 errors:0 dropped:1 overruns:0 frame:0
          TX packets:31747934 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:7471397493 (7.4 GB)  TX bytes:12864750080 (12.8 GB)
          Interrupt:20 Memory:f5100000-f5120000

I suspect you have two problems.

1) You are behind a NAT firewall, so data might not reach you.  If you haven't already, try configuring your gateway as the DMZ.  Also, try starting with traffic from inside (see problem 2), and hoping that the firewall opens a session for you.

2) You are behind a NAT firewall, so the provided configuration is not quite right.  Packets might not even be being sent.  Try removing the "local" definition in "/etc/network/interfaces".  (I think "local" is about bypassing the routing tables for the IPV4 traffic.)  Also, run dmesg to check for errors from the kernel.

Isn't "ifup he-ipv6" suppose to start the tunnel?
Is your ISP blocking proto41? is there a way to test for this and how do I turn this off on a cisco asa?

"ifup he-ipv6" does start the tunnel, but doesn't tell any non-debian user anything.  Try running "ifup -v he-ipv6", which shows the actual commands used, along with other activities if-up performs.

I would also recommend trying packet capture (wireshark) on the external interface of your host.  See if packets are sent or received.  See if there are error packets or rejects.   etc...

I can't help you with the protocol blocking question.


Questions & Answers / Re: Why IPv6 AXFR transfer is not supported?
« on: August 01, 2017, 05:26:30 PM »
I wrote in, talked a bit, and they found out the problem I was having.  It turns out that
  • You should send the NOTIFYs to  The other I don't think matter, or work at all. does not work at all.
  • You MUST send the NOTIFYs with a source address equal to one of the registered master addresses.  This I had to be told by staff, and is apparently what causes a "Refused" error.

Yes, IPv6 notifications do work, at least if you get your source address correct.  IPv6 transfers do work.


Questions & Answers / Re: Why IPv6 AXFR transfer is not supported?
« on: August 01, 2017, 11:19:52 AM »
At this point, I would suggest packet sniffing the network connection to determine if the request is being lost or ignored, or if it has an error.  If the former, I would suspect you have network problems.  If the later, I would suspect DNS configuration problems.  Since the error talks of retries, I suspect the network problems.

OK, I decided to test before posting, and now I am really confused.  I can't seem to get an update to go through, though I have seen the transfer to slave happen.
I can report that returns error "refused" (5), ns2 through ns5 return error "not implemented" (4), and seems to not respond at all.

At this point, I suspect a problem inside's DNS, and plan to write in.

One possible solution to the deadlock:
  • setup your own temporary DNS server for the domain in question.  Make sure it lists the DNS servers. (It will only need to be there for a few minutes.)
  • create a slave zone pointing to your DNS server.
  • convert the slave zone to a master.
  • get rid if the temporary DNS server.
At this point, the DNS zone exists, even without being delegated to.   :-)

I think there was a note about writing to one of the support addresses ( or as an alternative.


I did some debugging with wireshark:
What is wrong here?

Well, several packets from the remote server were lost.  The remote webserver tried to end the connection normally after 5 seconds of inactivity.  A TCP retransmission was initiated, and some (but not all) data was successfully resent.  Then (assuming TCP's rules haven't changed since IPv4) either the remote machine was rebooted, or it's TCP stack is broken or at least poorly configured, as those are the only way you get a RST in 120 seconds.  [I wouldn't bother with this issue.] 

Both ends seem to be sending a payload length (inside all the headers) of 1208, with an overall packet length of 1280, and you did receive such a packet.

Well, TCP did always require only a non-zero probability of successful delivery from it's lower level, but it never really behaves well unless it gets a very high probability of successful delivery.  Maybe you have a noisy connection (which seems unlikely with current technology).  Most of the dropped packets appear to be incoming.  If so, you might be able to tune your TCP stack to be more aggressive at sending and requesting retransmissions.  Unfortunately, that is just a workaround.

As for the underling problem?  Your guess is as good as mine, but I would suspect it isn't MTU, as the payload 1208 overall 1280 packets went both ways successfully (#4, #10).

General Questions & Suggestions / Re: certificate
« on: June 23, 2017, 08:44:17 PM »
-1 on this.  If you want to check the certificate, install CACert's root certificate.

(Personally, I don't understand how "Let's Encrypt" got into the lists... but then that could apply to most of the listed CAs.)

By the way... it looks like Let's Encrypt does not use a Let's Encrypt certificate.  Should anyone?

Pages: [1] 2 3 4