Home Marzili floods Tap dance Dobby paradise IPv6 at home Cycling Blog About Hyams family website
Last update: 04.01.2014
IPv6 at home: Part 2 - First steps with IPv6 (page 1 of 3) Introduction Having determined which devices on my network support IPv6 (see part  1), the next step is to determine their IP addresses and how they are assigned. I’d also like to see which network services are active on IPv6 and if there are any differences compared to IPv4. For my network this means looking at the configuration of the following devices: Various notebooks and PCs running Windows 7 NAS/file server (based on OpenSuse 12.3) Various network printers (OKI B430dn, Canon MG6250 and MX410) Android smartphones and tablets (Android 4.2 / 4.3) I haven’t looked at the IPv6 functionality of my Zyxel router as it’s reconfigured in bridging mode. Besides, my teenage kids get annoyed if I fiddle with the Internet connection (strange how they notice this so quickly). I’ve also not looked in detail at the Dlink wireless access points, as they are actually wireless routers that are being misused as simple access points, i.e. most of the functionality isn’t being used – not even for IPv4. While preparing this article I’ve also added some comments about network scanning and operating system identification with nmap. Since this article has got a little long, I’ve added the following navigation links to simplify scrolling: Introduction to link-local addresses NAS/file server Oki Network printer Canon network printers Android smartphones / tablet Windows 7 IPv6 network scanning Operating system identification Conclusions Link-local addresses It is not my intention to describe the fundamentals of IPv6 addressing within these articles, there are plenty of books and Internet articles that already do that. Despite this, it turns out that a little knowledge of link-local addresses is needed, so I’ll describe this very briefly here. One of the features of IPv6 is that devices can configure themselves with link-local addresses automatically, even without supporting services such as DHCP. This is similar to the assignment of 169.254.x.x addresses in IPv4. Having a link-local address means that devices can at least communicate with other devices on the same subnet.  According to Wikipedia, in IPv6 the assignment of a link-local address is mandatory, even when routable addresses are also assigned. This means that all my IPv6 devices should, at a minimum, already have a link-local address. If you look at IPv6 books and articles you’ll find that the address range fe80::/10 is allocated for link-local addresses (i.e. top 10 address bits) and the next 54 bits are all zero, so devices have to assign themselves the bottom 64 bits. When I first heard about IPv6 many years ago, I was told that the address was based on the 48 bit MAC address. So if my device has a MAC address 11:22:33:44:55:66, then the link-local address is going to be fe80::11:22:33:44:55:66? No! It turns out that you have to insert an ff:fe in the middle and invert one of the bits. This will become clear in the examples below. To make things more complicated, privacy extensions have also been introduced to IPv6, which means that a device doesn’t have to base the link-local address on the MAC address, but can use a random address that can also change over time. This will become clear from the examples below. NAS/file server Let’s start with my NAS/file server, which is an old PC that I bought for a nominal amount on ricardo.ch. Since it was first installed, the functionality has grown and it now serves as a central mail and calendar server  too. It also does some network monitoring with Nagios. The server is running OpenSuse 12.3. Using ifconfig I can see the IPv6 addresses: Notice that 2 IPv6 addresses are assigned, a public address (2a02:2528:…) plus a link-local address (fe80::20c…). Since I now have access to the IPv6 Internet via SixXS (see part 3), I’ve manually assigned a fixed, public IPv6 address to my server. The link local address was automatically assigned by the operating system. In this particular case, the link-local address is based on the MAC address, i.e. the HWaddr 00:0c:29:17:48:FC has been mapped to fe80::20c:29ff:fe17:48fc. By default, newer versions of Opensuse allocate a random link-local address, but I’ve disabled this. I notice that ifconfig only displays the total number of received and transmitted packets on the interface, but without any breakdown into IPv4 and IPv6. Hopefully this information can be found with a suitable SNMP query, but I’ve not tried this. Ping Now let’s try a few pings, first of all localhost (::1) Doesn’t work. On Opensuse you have to use a separate ping6 command: Now let’s try and ping the link-local address: That’s not what I expected! A little bit of research showed that you have to specify the interface too, either using the -i option or by appending the interface name to the address: Out of curiosity I compared these response times to their IPv4 equivalents, i.e. pings to localhost and 192.168.1.20. The response times were virtually identical. This is an improvement over a previous test with OpenSuse 11.1, where IPv6 pings took nearly twice as long as an IPv4 ping. TCP port scan - localhost Now let’s try a few port scans for both IPv4 and IPv6. First of all, localhost. For completeness and also to get some idea of timing I decided to scan all ports from 1 to 65535. So, there are quite a few IPv6 services active, nearly the same number as under IPv4. Also, I notice that the IPv6 scan takes about 3 times longer than IPv4 (2.74 seconds against 0.96). Looking at the list of active IPv6 services, I notice that they all correspond to IPv4 services that I explicitly enabled while configuring the server, i.e. when I activated Apache, Exim, Cyrus, Samba etc. not only was the IPv4 service activated, but also the equivalent on IPv6.  Put another way, it seems that if you’re running a recent version of OpenSuse and you activate a service, then there’s a good chance it’ll be activated on both IPv4 and IPv6. The exceptions are SpamAssassin, NRPE, VNC and amavisd (running on TCP 10024). After some help from Google and also reading the man pages I eventually found the following: SpamAssassin: The only reference to IPv6 in the man pages is an option to suppress the use of IPv6 for DNS tests (--ipv4only), but this isn’t what I’m looking for. The -i option is used to specify the IP address, but the man page doesn’t explicitly mention IPv6. Out of curiosity I tried starting the spamd daemon manually with ::1 as an IP address and the daemon started correctly – listening on IPv6. So it seems that SpamAssassin can be made to listen on IPv6 after all. I assume it’s sufficient to edit the configuration file ( /etc/sysconfig/spamd  ) and add the appropriate -i option (NOTE: I haven’t tried this). NRPE: Support for IPv6 was only added to NRPE very recently. To quote from the Nagios web site: ”NRPE 2.15 was released earlier today [i.e. September 6, 2013]. The primary update in this version of NRPE is full support for IPv6. The NRPE daemon now has the ability to listen on IPv4 and/or IPv6 addresses. […]”. I’m still running version 2.14, so I guess it’s time to upgrade. VNC: I’m using x11vnc instead of the default version supplied with OpenSuse (the default version doesn’t support copy/paste). Apparently x11vnc does support IPv6 but this has to be explicitly activated with the -6 option. I haven’t tried this yet. Amavisd: Apparently amavis does support IPv6. Have a look at the man pages, especially the -s option. It might be sufficient to simply change the definition of inet_socket_port within the file /etc/amavisd.conf, although I haven’t tried this. UDP port scan - localhost Back in 2010, an attempt to perform an IPv6 UDP port scan resulted in an error message that it wasn’t supported. Times have changed, and the -sU option now works for IPv6 too: Let’s compare this to IPv4: Similar to TCP, there are also quite a few UDP IPv6 services active. Lacking from the list of IPv6 services are netbios-ns, netbios-dgm and ipp, which are all active on IPv4. The services listed as unknown are the avahi daemon, active on 34288 (IPv6) and 46575 (IPv4). Also, I notice that the IPv6 scan takes about twice as long as IPv4 (4.04 seconds against 2.61). Port scan - link-local Back in 2010, my initial attempt at a port scan of the link-local address resulted in an unusual and not particularly helpful error message “strange error from connect (22): Invalid argument”. It turned out that you had to append the interface name, e.g. nmap -6 fe80::20c:29ff:fe17:48fc%eth0. Fortunately this is no longer necessary and the IP address is sufficient: The list of open ports is virtually identical to the scan of localhost. The only difference is that postrgres is only listening to localhost and not link-local as well. I also notice that the scan takes nearly three times longer, i.e. 7.5 seconds compared to “only” 2.74 seconds for the scan of localhost. HTTP My server is running 2 main applications on http, one is Nagios, which is accessible under http://nas- nwmon/nagios, and the other is davical, whose configuration page is accessible under http://nas- srv/davical/admin.php. Since I haven’t configured any IPv6 hostnames in /etc/hosts yet (neither on this Windows PC nor on the NAS itself), let’s see what happens if I try to access these web pages with the IPv6 address: Notice how the IPv6 address has to be entered within square brackets (top of screenshot). More important though is that Nagios is accessible over IPv6 without any reconfiguration. Clicking on various links also works correctly with IPv6 – see highlighted text at bottom left of screenshot. The results for davical were not quite so good: Apparently davical is looking for a configuration file with a name which is based on how it was accessed. As a quick workaround, I copied the existing configuration file nas-srv-conf.php to 2a02:2528:ff00:8114::20-conf.php and tried again: It seems that this solved the problem, although a better solution is needed (such as the definition of a suitable hostname within /etc/hosts). Thunderbird / imap According to the results from the port scans earlier, the IMAP server is listening not only on IPv4, but also on IPv6. Since I’m using Thunderbird to read my Email, let’s try and reconfigure it for IPv6.  Since I haven’t defined any IPv6 entries in the hosts file, I’ve simply entered the IPv6 address in the server settings tab: Subsequent tests have shown that this works OK and it’s possible to read Emails over IPv6 without problems. I haven’t tested outbound Email with IPv6 as this normally goes directly via my ISP, which is only accessible with IPv4.
nas-srv:~ # ifconfig -a eth0      Link encap:Ethernet  HWaddr 00:0C:29:17:48:FC            inet addr:192.168.1.20  Bcast:192.168.1.255  Mask:255.255.255.0           inet6 addr: 2a02:2528:ff00:8114::20/64 Scope:Global           inet6 addr: fe80::20c:29ff:fe17:48fc/64 Scope:Link           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1           RX packets:6399418 errors:0 dropped:9 overruns:0 frame:0           TX packets:3426049 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:1000           RX bytes:7673880975 (7318.3 Mb)  TX bytes:7086490769 (6758.2 Mb)
nas-srv:~ # ping ::1 ping: unknown host ::1
nas-srv:~ # ping6 ::1 PING ::1(::1) 56 data bytes 64 bytes from ::1: icmp_seq=1 ttl=64 time=0.024 ms 64 bytes from ::1: icmp_seq=2 ttl=64 time=0.032 ms 64 bytes from ::1: icmp_seq=3 ttl=64 time=0.033 ms 64 bytes from ::1: icmp_seq=4 ttl=64 time=0.033 ms
nas-srv:~ # ping6 fe80::20c:29ff:fe17:48fc connect: Invalid argument
nas-srv:~ # ping6 -I eth0 fe80::20c:29ff:fe17:48fc PING fe80::20c:29ff:fe17:48fc(fe80::20c:29ff:fe17:48fc) from fe80::20c:29ff:fe17:48fc eth0: 56 data bytes 64 bytes from fe80::20c:29ff:fe17:48fc: icmp_seq=1 ttl=64 time=0.033 ms 64 bytes from fe80::20c:29ff:fe17:48fc: icmp_seq=2 ttl=64 time=0.035 ms 64 bytes from fe80::20c:29ff:fe17:48fc: icmp_seq=3 ttl=64 time=0.035 ms ^C --- fe80::20c:29ff:fe17:48fc ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 0.033/0.034/0.035/0.004 ms nas-srv:~ # ping6 fe80::20c:29ff:fe17:48fc%eth0 PING fe80::20c:29ff:fe17:48fc%eth0(fe80::20c:29ff:fe17:48fc) 56 data bytes 64 bytes from fe80::20c:29ff:fe17:48fc: icmp_seq=1 ttl=64 time=0.032 ms 64 bytes from fe80::20c:29ff:fe17:48fc: icmp_seq=2 ttl=64 time=0.036 ms 64 bytes from fe80::20c:29ff:fe17:48fc: icmp_seq=3 ttl=64 time=0.032 ms ^C --- fe80::20c:29ff:fe17:48fc%eth0 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.032/0.033/0.036/0.005 ms
nas-srv:~ # nmap -6 -p 1-65535 ::1 Starting Nmap 6.25 ( http://nmap.org ) at 2014-01-02 14:23 CET Nmap scan report for localhost (::1) Host is up (0.0000090s latency). Not shown: 65524 closed ports PORT     STATE SERVICE 22/tcp   open  ssh 25/tcp   open  smtp 80/tcp   open  http 110/tcp  open  pop3 139/tcp  open  netbios-ssn 143/tcp  open  imap 445/tcp  open  microsoft-ds 631/tcp  open  ipp 993/tcp  open  imaps 2000/tcp open  cisco-sccp 5432/tcp open  postgresql Nmap done: 1 IP address (1 host up) scanned in 2.74 seconds nas-srv:~ # nmap  -p 1-65535 127.0.0.1 Starting Nmap 6.25 ( http://nmap.org ) at 2014-01-02 14:24 CET Nmap scan report for localhost (127.0.0.1) Host is up (0.0000050s latency). Not shown: 65519 closed ports PORT      STATE SERVICE 22/tcp    open  ssh 25/tcp    open  smtp 80/tcp    open  http 110/tcp   open  pop3 139/tcp   open  netbios-ssn 143/tcp   open  imap 445/tcp   open  microsoft-ds 631/tcp   open  ipp 783/tcp   open  spamassassin 993/tcp   open  imaps 2000/tcp  open  cisco-sccp 5432/tcp  open  postgresql 5666/tcp  open  nrpe 5801/tcp  open  vnc-http-1 5901/tcp  open  vnc-1 10024/tcp open  unknown Nmap done: 1 IP address (1 host up) scanned in 0.96 seconds
nas-srv:~ # nmap -6 -sU -p 1-65535 ::1 Starting Nmap 6.25 ( http://nmap.org ) at 2014-01-02 15:54 CET Nmap scan report for localhost (::1) Host is up (0.000011s latency). Not shown: 65530 closed ports PORT      STATE         SERVICE 123/udp   open          ntp 177/udp   open          xdmcp 514/udp   open|filtered syslog 5353/udp  open|filtered zeroconf 34288/udp open|filtered unknown Nmap done: 1 IP address (1 host up) scanned in 4.04 seconds
nas-srv:~ # nmap -sU -p 1-65535 127.0.0.1 Starting Nmap 6.25 ( http://nmap.org ) at 2014-01-02 16:04 CET Nmap scan report for localhost (127.0.0.1) Host is up (0.0000080s latency). Not shown: 65527 closed ports PORT      STATE         SERVICE 123/udp   open          ntp 137/udp   open          netbios-ns 138/udp   open|filtered netbios-dgm 177/udp   open          xdmcp 514/udp   open|filtered syslog 631/udp   open|filtered ipp 5353/udp  open|filtered zeroconf 46575/udp open|filtered unknown Nmap done: 1 IP address (1 host up) scanned in 2.61 seconds
nas-srv:~ # nmap -6 fe80::20c:29ff:fe17:48fc Starting Nmap 6.25 ( http://nmap.org ) at 2014-01-02 16:13 CET Nmap scan report for fe80::20c:29ff:fe17:48fc Host is up (0.000010s latency). Not shown: 990 closed ports PORT     STATE SERVICE 22/tcp   open  ssh 25/tcp   open  smtp 80/tcp   open  http 110/tcp  open  pop3 139/tcp  open  netbios-ssn 143/tcp  open  imap 445/tcp  open  microsoft-ds 631/tcp  open  ipp 993/tcp  open  imaps 2000/tcp open  cisco-sccp Nmap done: 1 IP address (1 host up) scanned in 7.50 seconds
NOTE: This article is too long to fit in one page. Click the appropriate button to navigate.
Page 1 (this page) Page 3 (last page) Page 2 (next page)