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


My IP is A:B:C:D::2/128, while the routed /64 is A:B:E:F::/64 .

And you are right, others IP could be A:B:C:G::2/128, or even A:B:C:D:H::2/128, although the latter is becoming inconvenient.quickly. So I guess the /48 subnet could provide 64k single endpoints.

So I think my real question is: Why is my endpoint IPv6 address not inside my routed /64 subnet?

Actually, that can be done, but it requires such painful routing rules on both ends that it isn't worth doing.  The issue is that their router's endpoint IPv6 address would then also need to be in your routed /64 subnet, but would not be truly in that subnet.  As I said, painful routing rules.


Yesterday I applied for a HE IPv6 tunnel, and got one. The default tunnel consists of an IPv6 address, ending on ::2, and a routed /64 subnet. What struck me is that the address is in a different /48 subnet than the routed /64 subnet. That means that a whole /48 subnet is burned just to provide my router an IPv6 address.

As my former Sixxs IPv6 address and subnet had the same peculiarity, I guess there is a technical reason for that. Which one?

Not quite right.

You got A:B:C:D::2/64 for your router, and A:B:E:D::/64 as your subnet. 

This means there is a /64 for your router to their router communication, and a /64 for your use.  And then, presumably, each tunnel through that HE node gets is own unique D value, and shares the A:B:C:: and A:B:E:: subnets.

Admittedly, it might have been a better use of resources to give out A:B:C:0:0:0:D:2/112 for the router and A:B:C:D::/64 for the subnet, but it's probably better just not to try to explain using /112 (or even /126 or /127) subnets.


General Discussion / Re: Unable to establish Ipv6 connectivity
« on: March 13, 2017, 05:28:34 PM »
While I don't know the full details of 6in4, I'm not sure how well it will work through the NAT firewall. 

6in4 has no issue with NAT as long as the router knows what's going on and is able to pass the traffic without bothering it.
In which case, an obvious suggestion is: you might try putting the windows machine in the DMZ.

you might try putting your address in the localaddress= value. [guessing]

That'll make things worse, the 192.x is appropriate here.
I guess that means it is a bind address.  I found that omitting it on my Linux box did not affect functionality.

General Discussion / Re: Unable to establish Ipv6 connectivity
« on: March 13, 2017, 04:27:37 PM »
Well, I would think the following two lines are suspect:

netsh interface ipv6 add v6v4tunnel interface=IP6Tunnel remoteaddress=

   IPv4 Address. . . . . . . . . . . :

While I don't know the full details of 6in4, I'm not sure how well it will work through the NAT firewall. 

You might try seeing if you can configure the tunnel directly on the TP Link router.
You might try securing your windows box and plugging it straight into the internet connection.  (This might at least let you get to the next step...)
you might try putting your address in the localaddress= value. [guessing]

--David G

(I stayed stuck at Explorer for 2 years on this issue.  Then I tried 6to4 and was Sage within two days. :) )

Edit: strike wrong suggestion.

In any case, I'll try targetting that address tomorrow.  (I've already done my points for today.  :-) )
Well, I tried it, and I removed the duplicate address I was suggesting, and it worked.  The other major differences were:
  • my addresses were in lower case
  • I had one more hop before reaching
  • My traceroute doesn't assume the target's address gets the target's name, so the last line was:
    9 (2a02:920:212e:1::213)  131.990 ms  132.554 ms  126.184 ms
Frankly, I would not have thought any of these would cause problems, but it gives me more things to test.   ;)


Edit: correct list formatting

Edit: Upper case didn't make it fail.  Nor did lack of hostnames.

Edit: It appears that the line before the first trace line is important.  It appears that it having a hostname they can resolve is not.

The parser is somewhat simplistic at times.  You might try changing:
  6 2001:7F8:D:FE::247 108 msec 104 msec 104 msec
Code: [Select]
  6 2001:7F8:D:FE::247 (2001:7F8:D:FE::247) 108 msec 104 msec 104 msec

I can definitely tell you that if an entry uses the alternate IPv4 derived address formatting, it is rejected.  I.e. if that address were written 2001:7F8:D:FE:: it would definitely be rejected, even though it is perfectly valid and equivalent.

In any case, I'll try targetting that address tomorrow.  (I've already done my points for today.  :-) )

--David G

IPv6 on Linux & BSD & Mac / RIP on IPv6 for Linux?
« on: March 03, 2017, 07:22:21 PM »
Once upon a time, I worked on a network of SunOS computers.  They all ran "routed" implementing the RIP protocol.  They all routed everything right.  At some point our network administrators decided that the 3 packets per router per minute was too much traffic on our network, and shut it down.  Routing problems started.

Does anyone known of a comparable lightweight routing daemon for IPv6 and IPv4, for the Linux (debian) platform?  As far as I'm concerned, Quagga or Zebra is to heavy.  I tried "babeld", but it was too much based on hosts instead if networks.

I'm looking for something that is single process, single thread, small executable, minimal configuration, and capable of running on every node in the network, including the non-routing nodes.  (Non-routing nodes should just be receive only, except for an initial broadcast like in RIP.)   Ideally, it could also replace radvd.

--David G

Questions & Answers / Re: Testing protocol 41
« on: February 24, 2017, 04:34:09 AM »
Does there exist any linux tools which can test if protocol 41 gets through the network (4G) and my router?

I have access to linux boxes outside my network which can be used as endpoints.
But as my home network has no public IP; it is on Carrier grade Nat, the connections have to be initiated from my network to my external hosts.

nmap can do it, to some extent. 

You can try something like:
Code: [Select]
nmap -sO -p 1,6,17,41 hostname
The downside is that it can't always distinguish open from filtered.


Well, in my case, the command I use reads something like:

Code: [Select]
wget --auth-no-challenge -q -O- --http-user=my_username --http-passwd=my_password ''
It turns out this is safe to run at any time.  It just tells you that there is no change ("nochg").  On the other hand, you should not run it too frequently


Edit: If you just go the advanced tab on the tunnel details page, it will provide a URL to use.

Edit2: I think the other part of the equation (at least for me) is to omit the specifying the local IP address in the configuration.  Linux will use your local address as needed.

I think you want "Dyn-compliant Endpoint Updates" at


General Discussion / Re: False negative for traceroute submission?
« on: February 10, 2017, 07:42:45 AM »
Here's the traceroute:
Code: [Select]
14 (::ffff:  154.563 ms  154.812 ms  154.436 ms

My guess is the ipv4 check matched for hop 14?

Yes, and it turns out if you rewrite that line as:
Code: [Select]
14 (::ffff:5756:47a3)  154.563 ms  154.812 ms  154.436 ms
then it works.  They check the form, not the content.

Suggest a Test! / IPv6 DNS lookup
« on: February 07, 2017, 09:45:05 AM »
How about doing a DNS lookup using IPv6.

In order to do this, one would need a DNS zone that is deliberately NOT delegated to, on a server that only accepts IPv6 requests.  Then the testee would fetch something from the server, and enter that as evidence of test completion. 

I suggest that it be a TXT record, using a domain name like <username>.hurricane-electric-certification-test.  and that the value be a nonce, followed by a hash of the nonce, username, and a secret shared between the dns server and the test server.  This would prevent sharing answers, or taking too long to enter the answer.


Pages: 1 2 3 [4]