09 June 2011

Happy IPv6 test day, part 2

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

08 June 2011

Happy IPv6 test day

There is a 'ipv6 readiness testing day' today, April June 8, 2011, and so it seems appropriate to post my personal checklist for putting a CentOS box up on that network fabric

  • Apply for an account with SixXs. Their reply takes a couple of days, as it is a volunteer run organization
  • Have a deployed, updated, and hardened unit at a routable static IPv4 address
  • Amend /etc/sysconfig/iptables to include a line passing the tunnelling protocol. I place the entry after the IPSEC protocol entries in a stock setup. Restart iptables
    ... 
    -A RH-Firewall-1-INPUT -p 50 -j ACCEPT
    -A RH-Firewall-1-INPUT -p 51 -j ACCEPT
    # vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
    -A RH-Firewall-1-INPUT -p ipv6 -j ACCEPT
    # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...
  • Strip out any previous efforts at disabling the ipv6 / net-pf-10 kernel modules from loading in /etc/modules.conf, and in the files sourced in /etc/modprobe.d/ . Then rebuild the modules dependency table: /sbin/depmod -a
  • Amend /etc/sysconfig/network to carry the following lines:
    #
    NETWORKING_IPV6=yes
    IPV6INIT=yes
    IPV6FORWARDING=yes
    IPV6_DEFAULTDEV=sit1
    #
    Which anticipates that the configuration details for the ipv6 tunnel will live in a file: /etc/sysconfig/network-scripts/ifcfg-sit1
  • and add that mentioned file: /etc/sysconfig/network-scripts/ifcfg-sit1 -- I have elided site-specific details as to IP addresses with: aa.bb.cc and aa:bb:cc placeholders
    #
    DEVICE=sit1
    BOOTPROTO=none
    ONBOOT=yes
    IPV6INIT=yes
    IPV6_TUNNELNAME="SixXS"
    #
    IPV6_AUTOTUNNEL=yes
    PHYSDEV=eth0
    IPV6_ROUTER=yes
    #
    IPV6TUNNELIPV4="38.229.76.3"
    # 38.229.76.3 is the remote end of the tunnel at the tunnel broker
    IPV6TUNNELIPV4LOCAL="198.aa.bb.cc"
    # 198.aa.bb.cc is the local ipv4 static IP
    IPV6ADDR="2604:aa:bb:cc::2/64"
    # 2604:aa:bb:cc::2/64 shows both the local gateway IP, and netmask
    # the remote end gateway IP is by convention, the :1
    IPV6_MTU="1280"
    TYPE=sit
    #

At this point, simply restarting networking should bring up the ipv6 link, and properly route it -- so: /sbin/service network restart

The interfaces will look something like this:

[herrold@nostname ~]$ /sbin/ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:01:02:aa:bb:cc
inet addr:76.aa.bb.cc Bcast:76.aa.bb.dd Mask:255.255.255.248
inet6 addr: fe80::201:aaff:bb05:cc16/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:11088057 errors:0 dropped:0 overruns:1 frame:0
TX packets:10668738 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1726307345 (1.6 GiB) TX bytes:3178496052 (2.9 GiB)
Interrupt:3 Base address:0x6f80

[herrold@hostname ~]$ /sbin/ifconfig sit1
sit1 Link encap:IPv6-in-IPv4
inet6 addr: 2604:aa:bb:cc::2/64 Scope:Global
inet6 addr: fe80::bbf2:cc1c/128 Scope:Link
UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1
RX packets:500 errors:0 dropped:0 overruns:0 frame:0
TX packets:502 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:53331 (52.0 KiB) TX bytes:62784 (61.3 KiB)

[herrold@hostname ~]$

To wrap this up, ipv6 hardening, and connection debugging are worthy topics, and it may well be that a cautious sysadmin wants to lock down /etc/sysconfig/ip6tables and examine how one has hardened /etc/hosts.deny ... But rather than rush out content (I have a couple of mailing list posts I need to re-work), I'll leave these for later posts, while you, gentle reader, go apply for an account at a tunnel broker