In my first post in this small series, I closed without addressing matters of securing an IPv6 connection, and in matters of debugging where a connection failure is occurring. Thinking about it, the diagnostic post needs to come first, because tightening down a conneciton can cause hard to diagnose symptoms. So, on to diagnosis ...
We examined the interface results last time. Looking at just the routing related to ipv6 is straightfowrard as well:
Some familiar tools:
/sbin/ifconfig eth0
/sbin/ifconfig sit1
/sbin/route -A inet6
So using those tools:
[herrold@hostname ~]$ /sbin/ifconfig sit1
sit1 Link encap:IPv6-in-IPv4
inet6 addr: 2604:aa:bb:cc::2/64 Scope:Global
inet6 addr: fe80::4cf2:1c/128 Scope:Link
UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1
RX packets:1691 errors:0 dropped:0 overruns:0 frame:0
TX packets:1693 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:177195 (173.0 KiB) TX bytes:210468 (205.5 KiB)
[herrold@hostname ~]$ /sbin/route -n -A inet6 | grep 2604
2604:aa:bb:cc::/64 :: U 256 1658 0 sit1
2604:aa:bb:cc::/128 :: U 0 0 2 lo
2604:aa:bb:cc::2/128 :: U 0 1691 1 lo
[herrold@mailhub ~]$
That is a pretty ordinary routing table for a non-gateway endpoint. Off-box traffic (to the '/64' netmask) is handed to the sit interface, and local traffic (to the '/128') retained on the local lo interface
We use a unfamiliar tool: ping6 -- The common '127.0.0.1' localhost has a new form under ipv6:
ping6 ::1 -c 2
and testing
[root@hostname ~]# ping6 ::1 -c 2
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=0 ttl=64 time=0.157 ms
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.132 ms
--- ::1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.132/0.144/0.157/0.017 ms, pipe 2
[root@ostname ~]#
And we can ping by IP on the 'Global' link, both on the local end, and remotely with differing transit times for the packets:
Looking at the network connections, we examine the tunelling interface:
[root@hostname ~]# /sbin/ifconfig sit1
sit1 Link encap:IPv6-in-IPv4
inet6 addr: 2604:aa:bb:cc::2/64 Scope:Global
inet6 addr: fe80::4cf2:1c/128 Scope:Link
UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1
RX packets:1714 errors:0 dropped:0 overruns:0 frame:0
TX packets:1731 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:179587 (175.3 KiB) TX bytes:215180 (210.1 KiB)
[root@hostname ~]# ping6 2604:aa:bb:cc::2 -c 2
PING 2604:aa:bb:cc::2(2604:aa:bb:cc::2) 56 data bytes
64 bytes from 2604:aa:bb:cc::2: icmp_seq=0 ttl=64 time=0.135 ms
64 bytes from 2604:aa:bb:cc::2: icmp_seq=1 ttl=64 time=0.137 ms
--- 2604:aa:bb:cc::2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.135/0.136/0.137/0.001 ms, pipe 2
[root@hostname ~]# ping6 2604:aa:bb:cc::1 -c 2
PING 2604:aa:bb:cc::1(2604:aa:bb:cc::1) 56 data bytes
64 bytes from 2604:aa:bb:cc::1: icmp_seq=0 ttl=64 time=55.1 ms
64 bytes from 2604:aa:bb:cc::1: icmp_seq=1 ttl=64 time=53.7 ms
--- 2604:8800:100:bb::1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 53.781/54.473/55.165/0.692 ms, pipe 2
[root@hostname ~]#
Turning to DNS and name resoluton, it is quite familiar. One does not need an IPv6 link to query nameservers and receive back results, as they will answer questions _about_ ipv6 hostnames ('AAAA' records) to any authorized inquirant. Try these:
dig +trace www.ipv6.sixxs.net
dig www.kame.net aaaa
I get answers like this:
[herrold@centos-5 ~]$ dig www.kame.net aaaa
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> www.kame.net aaaa
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45595
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3
;; QUESTION SECTION:
;www.kame.net. IN AAAA
;; ANSWER SECTION:
www.kame.net. 85164 IN CNAME orange.kame.net.
orange.kame.net. 85164 IN AAAA 2001:200:dff:fff1:216:3eff:feb1:44d7
;; AUTHORITY SECTION:
kame.net. 85164 IN NS mango.itojun.org.
kame.net. 85164 IN NS orange.kame.net.
;; ADDITIONAL SECTION:
mango.itojun.org. 2364 IN A 210.155.141.200
mango.itojun.org. 2364 IN AAAA 2001:2f0:0:8800:206:5bff:fe8d:940
mango.itojun.org. 2364 IN AAAA 2001:2f0:0:8800::1:1
;; Query time: 1 msec
;; SERVER: 10.16.1.112#53(10.16.1.112)
;; WHEN: Thu Jun 9 17:17:20 2011
;; MSG SIZE rcvd: 195
[herrold@centos-5 ~]$
which is certainbly a mess to read -- let's trim out the interesting parts:
[herrold@centos-5 ~]$ dig www.kame.net aaaa
;; ANSWER SECTION:
www.kame.net. 85164 IN CNAME orange.kame.net.
orange.kame.net. 85164 IN AAAA 2001:200:dff:fff1:216:3eff:feb1:44d7
Which is the familiar information: a CNAME record is pointed in fact at a AAAA record at a ipv6 -type IP. We can ping (ping6) it by IP:
[root@hostname ~]# ping6 2001:200:dff:fff1:216:3eff:feb1:44d7 -c 2
PING 2001:200:dff:fff1:216:3eff:feb1:44d7(2001:200:dff:fff1:216:3eff:feb1:44d7) 56 data bytes
64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=0 ttl=52 time=246 ms
64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=1 ttl=52 time=256 ms
--- 2001:200:dff:fff1:216:3eff:feb1:44d7 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 246.833/251.705/256.577/4.872 ms, pipe 2
[root@hostname ~]#
or ping it by name, as DNS is working:
<[root@hostname ~]# ping6 www.kame.net -c 2
PING www.kame.net(2001:200:dff:fff1:216:3eff:feb1:44d7) 56 data bytes
64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=0 ttl=52 time=227 ms
64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=1 ttl=52 time=244 ms
--- www.kame.net ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1008ms
rtt min/avg/max/mdev = 227.291/235.678/244.066/8.401 ms, pipe 2
[root@hostname ~]#
Some other examples to try as 'beacons' might include:
ping6 2604:8800:100:9a::1 -c 2
ping6 2001:200:0:8002:203:47ff:fea5:3085 -c 2
ping6 ftp.ipv6.uni-muenster.de -c 2
ping6 -I eth0 ipv6.google.com -c 2
So the familiar diagnostic methods of examining interfaces, checking routing, testing connectivity by IP, and connectvity after resolution by name are all present
