[clug] Problem getting a working IPv6 connection
sjjf at himi.org
Sat Feb 2 01:47:13 MST 2013
On Sat, Feb 02, 2013 at 05:01:27PM +1100, Craig Small wrote:
> On Sat, Feb 02, 2013 at 02:04:55PM +1100, Simon Fowler wrote:
> > int. +------+ eth +-----+ adsl +---+
> > -----|Server|-----|modem|------|ISP|
> > net +------+ +-----+ +---+
> > | PPPoE |
> > +- - - - - - - - - - - - +
> Are you sure you're pinging using the global address and not the link
> address? Also use the -n flag with ping6 as it sometimes has problems
> reverse resolving.
> I have a gogo/gw6c tunnel but the idea is much the same. I have a
> "tunnel" address of /128 and a "LAN" address of /64
> ip -f inet6 addr show | grep global
> inet6 2001:44b8:62:180::1/64 scope global
> inet6 2001:44b8:61::6f/128 scope global
simon at lassus:~$ ip -f inet6 addr show
7: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qlen 3
inet6 fe80::50b6:b3b7:8c89:f2e/10 scope link
valid_lft forever preferred_lft forever
The PPP link comes up with a link scoped address, with another link
scoped address on the remote end (in this case
When I ping the remote address, I get a response:
simon at lassus:~$ ping6 -c 2 -I ppp0 fe80::224:14ff:fe9a:a410
PING fe80::224:14ff:fe9a:a410(fe80::224:14ff:fe9a:a410) from
fe80::50b6:b3b7:8c89:f2e ppp0: 56 data bytes
64 bytes from fe80::224:14ff:fe9a:a410: icmp_seq=1 ttl=64 time=36.0
64 bytes from fe80::224:14ff:fe9a:a410: icmp_seq=2 ttl=64 time=66.8
--- fe80::224:14ff:fe9a:a410 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 36.021/51.434/66.848/15.415 ms
> The first being the LAN address, the second being my tunnel address.
> Your addresses should be 2001:44b8:something as you use Internode too.
> If you see your pings with addresses with things like fe80:whatever then
> thats a link local address, its not going to go anywhwere.
Yeah, the /56 they assigned me is indeed under 2001:44b8.
> Then try (you will have to replace the addresses with yours):
> ping6 -n 2001:44b8:61::6f
> this is your tunnel address, failure means your tunnel is messed up
> ping6 -n 2001:44b8:61::6e
> one less than your tunnel, failure means the tunnel is messed up
> ping6 -I 2001:44b8:62:180::1 -n 2001:44b8:61::6e
> -I eth0 didn't work for me (used tun address).
> ping same as before, but using source address of your LAN. failure
> means most likely YOUR end is messed up, ip6tables or forwarding
> ping6 www.internode.on.net
> pinging from your tunnel to beyond, failure often means your routing
> (route 2000::/3 via tun) is wrong
> ping6 -I 2001:44b8:62:180::1 -n www.internode.on.net
> ping from your LAN to beyond, failure is funky filters on your end
> OR their return routing is wrong.
> All the time you are doing this, you should have a tshark/tcpdump on
> your tunnel interface.
> tshark -i tun icmp6
Thing is, I'm not using a tunnel - I'm using a native dual stack
setup. My link to Internode isn't being assigned global addresses
(though I can easily assign it one myself - it doesn't make any
difference). I can ping the far end, but if I try and ping a global
address I get nothing:
simon at lassus:~$ ping6 -c 3 -I 2001:44b8:317e:8a01::1 -n
PING www.internode.on.net(2001:44b8:69:2:1::100) from
2001:44b8:317e:8a01::1 : 56 data bytes
--- www.internode.on.net ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2015ms
> mtr -6 is another fine tool for checking where its dying, its not that
> good for the what though.
traceroute6 behaves exactly the same as ping6 - no responses. If I
try to hit an IPv6 only site (i.e. ipv6.google.com) it simply times
out, with tcpdump showing a string of syn packets going out with no
I'm totally at a loss with this.
PGP public key Id 0x96263cef
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 490 bytes
Desc: Digital signature
More information about the linux