Questions[6rd](server)

Long story short, I am having issues with IPv6 using a 6rd tunnel with my ISP, Charter Business. They offer a 6rd tunnel that I think I have properly set up, but the server doesn’t reply to every IPv6 request. When the server has the network interfaces idle with no traffic for about 10 minutes, then IPv6 stops accepting inbound connections. to re-allow it, I must go into the server, and make it do a outbound IPv6 connection (normally a ping) to start it back up. Whats weird though i that if I run iptraf when its not working, it still shows a inbound IPv6 packet… the server is just not replying, and I can’t figure out why. Also, if I try to access my server over IPv6 from a house about 1 mile away on the same ISP, it is never able to connect. it always times out, but again the iptraf shows a IPv6 inbound packet. Again, it just does not reply. To test if my server is accessible through IPv6 I always have to use my vzw 4g phone (they use IPv6) or ipv6proxy dot net.

Here is all of the configuration information my ISP gives on there tunnel server:

6rd Prefix = 2602:100::/32
Border Relay Address = 68.114.165.1
6rd prefix length = 32
IPv4 mask length = 0

Here is my /etc/network/interfaces for IPv6 (used x's to block real addresses)

auto charterv6 
iface charterv6 inet6 v4tunnel
        address 2602:100:189f:xxxx::1
        netmask 32
        ttl 64
        gateway ::68.114.165.1
        endpoint 68.114.165.1
        local 24.159.218.xxx
        up ip link set mtu 1280 dev charterv6

here is my iptables config

filter
:INPUT DROP [0:0]
:fail2ban-ssh – [0:0]
:OUTPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:hold – [0:0]
-A INPUT -p tcp -m tcp —dport 22 -j fail2ban-ssh
-A INPUT -m state —state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m multiport -j ACCEPT —dports 80,443,25,465,110,995,143,993,587,465,22
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp —dport 10000 -j ACCEPT
-A INPUT -p tcp -m tcp —dport 5900:5910 -j ACCEPT
-A fail2ban-ssh -j RETURN
-A INPUT -p icmp -j ACCEPT
COMMIT

and last here is my ip6tables firewall config

filter
:INPUT DROP [1653:339023]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [60141:13757903]
:hold – [0:0]
-A INPUT -m state —state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m multiport —dports 80,443,25,465,110,995,143,993,587,465,22 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp —dport 10000 -j ACCEPT
-A INPUT -p tcp -m tcp —dport 5900:5910 -j ACCEPT
-A INPUT -p ipv6-icmp -j ACCEPT
COMMIT

So Summary:

1. iptraf always shows IPv6 traffic, so its always making it to the server

2. server stops replying on IPv6 after no traffic for awhile (10 minutesish) until a outbound connection is made, then the process repeats.

3. server is NEVER accessable vi same ISP (yet iptraf still shows IPv6 request)

Notes: When I try to access it from the same ISP from across town, even with iptables and ip6tables allowing ALL inbound traffic, this is what iptraf shows.

IPv6 (92 bytes) from 97.92.18.xxx to 24.159.218.xxx on eth0
ICMP dest unrch (port) (120 bytes) from 24.159.218.xxx to 97.92.18.xxx on eth0

It's strange it does this even with the IPv6 address being set in the hosts file to the servers domain name. With iptables set up normally with the above configurations it only says this:

IPv6 (100 bytes) from 97.92.18.xxx to 24.159.218.xxx on eth0

Also, another thing I noticed. When I am able to access my server, all the IPv6 requests show this

IPv6 (100 bytes) from 68.114.165.1 to 24.159.218.xxx on eth0

which means they are going through the 6rd relay, yet when on the same ISP requests show to come from the honest source IP, which makes me think routes might have something to do with this.

I'm REALLY stuck on this, and any help would be GREATLY appreciated.

EDIT: Don't know if this will help or not, but here is my routes.

root@XXXXXXX:~# route -A inet6
Kernel IPv6 routing table
Destination                    Next Hop                   Flag Met Ref Use If
::68.114.165.1/128             ::                         U    1024 0     1 charterv6
2602:100::/32                  ::                         Un   256 0     0 charterv6
fe80::/64                      ::                         Un   256 0     0 charterv6
fe80::/64                      ::                         U    256 0     0 eth1
fe80::/64                      ::                         U    256 0     0 eth2
::/0                           ::68.114.165.1             UG   1024 0    30 charterv6
::/0                           ::                         !n   -1  1    32 lo
::1/128                        ::                         Un   0   3    47 lo
2602:100:189f:xxxx::1/128      ::                         Un   0   1    50 lo
fe80::189f:xxxx/128            ::                         Un   0   1     0 lo
fe80::21b:21ff:fe98:456a/128   ::                         Un   0   1     0 lo
fe80::21b:21ff:feab:bd3c/128   ::                         Un   0   1     0 lo
ff00::/8                       ::                         U    256 0     0 charterv6
ff00::/8                       ::                         U    256 0     0 eth1
ff00::/8                       ::                         U    256 0     0 eth2
::/0                           ::                         !n   -1  1    32 lo

First 6to4:

6to4 allows IPv6 Packets to be transmitted over IPv4. It's used to connect two IPv6 'islands' - not enable IPv4 to talk to IPv6 or vice versa. IPv6 address 2002:AABB:CCDD:: becomes IPv4 address AA.BB.CC.DD and you slap a IPv4 packet header onto the IPv6 header, and forward that sucker off through the IPv4 network.

If I send a packet from one IPv6 Island in the 2002:AABB:CCDD:: space to another, my local 6to4 border router will recieve it, wrap it in IPv4 to AA.BB.CC.DD and forward it there. AA.BB.CC.DD is another 6to4 border router on an island who unwraps the IPv4 and sends it to the IPv6 address.

If I send a packet from an IPv6 Island in 2002:AABB:CCDD:: to a native IPv6 address like 2054::45, it will go to my border router who wraps it in IPv4 to 192.88.99.1 - the IPv4 anycast 6to4 Relay Router address. The nearest relay router (which could be run by anyone) will get it and unwrap it and forward it to the IPv6 address specified. To reply, 2054::45 will reply to my 2002:: address, which will be routed to the nearest relay router (who advertises it handles 2002::/16). The relay router will then wrap it in IPv4 to the AA.BB.CC.DD address where it goes to my border router, is unwrapped and sent to me.

I think I understand that right. It's 6rd I'm having problems with.

Sending a packet from my IPv6 Island to another 6rd island is the same as sending to a native IPv6 address - right? Because the ISP's 6rd router is in its assigned IPv6 address space, the IPv6 routers don't know it's a 6rd island.

If the 6rd island I'm trying to contact isn't connected to the broader IPv6 Internet - there's no way to reach it, right? It would need to go over IPv4, but my 6rd border router doesn't know how to turn an arbitrary IPv6 address into an IPv4 address... does it? And on the reverse trip, there's no 6rd relay router in the IPv6 internet to translate an IPv6 packet to what looks like a normal IPv6 address into IPv4 and send it to the right location.

Inside a single ISP:

6rd island - [6rd Border Router] - IPv4 ISP Internet - [6rd Border Router] - 6rd Island 

This works fine, because the ISP controls the routes and can add routes to the 6rd Routers saying "If you're trying to reach 2054::something, send it over IPv4 to a.b.c.d. But I don't understand how 6rd routes over the broader IPv4 or IPv6 Internet.