Hurricane Electric's IPv6 Tunnel Broker Forums

Advanced search  

News:

Welcome to Hurricane Electric's Tunnelbroker.net forums!

Pages: 1 ... 8 9 [10]
 91 
 on: December 23, 2019, 11:28:51 AM 
Started by funtoo - Last post by funtoo
Might as well post my radvd.conf as well:

# RADVD with no DHCPd6 configuration
interface brwan {
      AdvSendAdvert on;
      AdvLinkMTU 1480;
      MinRtrAdvInterval 60;
      MaxRtrAdvInterval 180;
      prefix 2001:470:39:56::1/64 {
            AdvOnLink on;
            AdvRouterAddr on;
            AdvPreferredLifetime 600;
            AdvValidLifetime 3600;
      };
};

 92 
 on: December 23, 2019, 11:27:26 AM 
Started by funtoo - Last post by funtoo
But my routed /64 *is* 2001:470:4b:56::/64.

Here is my tunnel configuration straight from the tunnelbroker control panel:

Creation Date:Dec 12, 2019
Description:
IPv6 Tunnel Endpoints
Server IPv4 Address:184.105.250.46
Server IPv6 Address:2001:470:39:56::1/64
Client IPv4 Address:192.150.253.83
Client IPv6 Address:2001:470:39:56::2/64
Routed IPv6 Prefixes
Routed /64:2001:470:4b:56::/64
Routed /48:Assign /48
DNS Resolvers
Anycast IPv6 Caching Nameserver:2001:470:20::2
Anycast IPv4 Caching Nameserver:

I need the /128 route for it to function as I described.

If I'm doing something wrong, I don't understand, so please explain.

 93 
 on: December 23, 2019, 11:17:10 AM 
Started by funtoo - Last post by cholzhauer
You have two IPv6 allocations...one is the tunnel /64 that you really shouldn't use other than to create the tunnel and the other is the routed /64 that you use to assign addresses to other hosts in your LAN.  If you have more than one subnet in your LAN, you should request a /64.

So, in short, a second host in your network should NOT have an address in 2001:470:39:56::/64, it should be in your routed /64

 94 
 on: December 23, 2019, 11:16:21 AM 
Started by funtoo - Last post by broquea
Our side is configured as /64, so your side is configured /64. This has been working for nearly 20 years now, so yeah...

Only BSD systems wanted the /128 as part of the command, regardless of prefix size.

If you are configuring your LAN with either static/DHCP6/RADVD you should be using your routed /64 or /48, not the link /64. That is true for IPv6 as it is for IPv4. Stop bridging the p2p link allocation, that is silly. We already statically route you subnet(s) for LAN usage.

 95 
 on: December 23, 2019, 11:12:06 AM 
Started by funtoo - Last post by funtoo
Hello all/HE staff,

Correct me if I'm wrong, but I think the commands that the tunnelbroker example config prints out are incorrect, or potentially sub-optimal. For my tunnel, this is what 'example configurations' prints out for linux-net-tools:

modprobe ipv6
ip tunnel add he-ipv6 mode sit remote 184.105.250.46 local 192.150.253.83 ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:39:56::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6
ip -f inet6 addr

I am going to propose that this is wrong, that the "ip addr add" command should have a /128 on the address, and not a /64.

If you are using your /64 and handing out IP addresses via radvd, then your /64 will be local (ie. not on the other side of the he-ipv6 tunnel.) So this route is incorrect.

Using /128 will result in just a route to the ::2 address only. But without, your entire /64 will be assumed to be on the 'wrong' side of the tunnel. This actually does not create problems when you are just setting up routing for a single machine that has a tunnel on it, but if you are advertising routes on your LAN, this route is incorrect.

Using /128, along with radvd, I get the correct routes:

mork ~ # ip -6 route
2001:470:39:56::1 dev brwan proto kernel metric 256 pref medium
2001:470:39:56::2 dev 6to4 proto kernel metric 256 pref medium
2001:470:39:56::/64 dev brwan proto kernel metric 256 expires 30sec pref medium

In this case, I am using radvd on bridge brwan.

I'm relatively new to IPv6, so hopefully I'm not making a fool of myself here, but it seems like correcting the example commands to have /128 will result in a Linux routing configuration that will work for the host *and* bridged devices, whereas the current config just breaks when you have other devices on your LAN utilizing the tunnel.

Looking forward to feedback. Also note -- this /128 fix was what I needed to successfully configure the tunnel on the host as well as for the bridged LAN with radvd.



 96 
 on: December 18, 2019, 07:02:36 AM 
Started by shirakun - Last post by broquea
No emails from you into our system. I've mailed out to you via the ticket for your BGP tunnel.

 97 
 on: December 17, 2019, 11:51:42 PM 
Started by shirakun - Last post by congziyuan
Hello and the same problem, I sent the email with LOA on Dec 5, 2019 and it is still Pending.
Could you please help me🙏
And thanks for your awesome service!

 98 
 on: December 13, 2019, 10:06:05 AM 
Started by holgermarzen - Last post by holgermarzen
My workaround: I was able to book a public ip address for a small monthly fee.

 99 
 on: December 12, 2019, 01:23:49 AM 
Started by deags - Last post by kasperd
Is DoH and DoT something which BIND on Ubuntu Sever 18.04 LTS can be configured to do? If it is, I'd happily support it on the DNS64 servers in my pool.

My searches so far have only lead to suggestions which involve an additional proxy layer and I suspect that would interfere with BIND's ability to choose a NAT64 close to the client.

 100 
 on: December 11, 2019, 02:56:01 PM 
Started by nov30th - Last post by boab
Thank you all for this thread.
I was getting refused "good 127.0.0.1" until I enabled external ping responces.
Can now progress with my isp failure auto-recovery

Pages: 1 ... 8 9 [10]