News items for tag ipv6 - Koos van den Hout

Some downloads from websites hosted on my ADSL link clog it a bit. Not for sites like this one, but for larger binary files that I just put up for a few hours for someone to download. So I'd like to limit the bandwidth. Some searching suggests mod_bw version 0.7 but I found it doesn't like IPv6 address ranges. Searching a bit more found a newer version (0.92) available at mod_bw downloads which works better.

Now to test it and see how my upstream bandwidth holds. So far it works in my tests.

Hey, just noticed my first Comcast IPv6 visitor in the logs for this site. Welcome! Consumer Internet connections in the US with IPv6, they do exist now. When is the rest coming!

Also notable: with valid reverse DNS records.

A real "why do I still bother with legacy IP" (and NAT) moment today. I tried to use the IRC DCC protocol to receive a file from someone and the client of the other party was running behind IPv4 nat. "Active" and "Passive" dcc failed. But we both can use IPv6 so I upgraded that IRC connection to v6 (I changed the OFTC serverlist to use irc6.oftc.net). This restored end to end connectivity and the file was transferred.

There is demand for VoIP over IPv6 so the excuse "there is no demand" or "you're the first one to ask" is no longer true: VoIP6 provider wanted in the Netherlands. Get in touch with them when you are serious.

Interesting reading about making services available over IPv6: RFC 6589: Considerations for Transitioning Content to IPv6. A quite practical document about transitioning services to IPv6, considerations and possible impact. I'd consider this document required reading for organisations active on the Internet who want to stay active.

With World IPv6 Launch Day coming up more and more places should be supporting IPv6. This time it is a "launch" and it should not be switched off the next day which should severely increase the urgency of fixing IPv6-related bugs.

Related news items:

• Akamai to launch service in April - Network world which should increase IPv6 traffic a lot.
• With World IPv6 Launch, IPv6 on by default will be the new normal - Ars Technica a good explanation of the current state, the availability of home routers which understand IPv6 and the plans of Comcast and Time Warner Cable (large cable ISPs in the US with IPv6 plans).

Remember the finger protocol? Once that was the way to publish information about yourself on the Internet before the whole worldwideweb thing and the concept of a 'homepage' started. But, finger gave/gives out too much information in the default settings, such as where you are logged in from (local terminal or network connection, complete with remote host name). I wanted to re-enable finger on my server at home, but did not want to 'leak' out this information. And I liked the concept of the 'people' command, which makes a list of users on multiple systems based on rwho data. But 'people' as a finger daemon likes to call the normal finger command when a name is given via the finger protocol, so finger user@host1@host2 would be forwarded, which is not what I like. The solution now is that I use cfingerd which does not give out information about sessions, hostnames and idle times. And cfingerd is in control, but calls people to create a list of logged-in users. End result: see for yourself, finger @koos.idefix.net. Or finger koos@koos.idefix.net. Temporarily not availabe via IPv6 because cfingerd gives a weird error when accessed via IPv6.

For those places where finger isn't even installed, the user-listing looks like:

koos@greenblatt:~$ people -H
User      Name                            Machine(s)
--------- ------------------------------- -------------------------------
koos      Koos van den Hout               greenblatt

A bit of history: Adam Curry once managed to cause severe load on a finger server by announcing the "Cyber-Sleaze report" available via finger curryco@panix.com. Within 4 days panix asked him to stop publishing information this way because of unprecedented traffic on the finger service. Source: Cyber Sleaze - Adam Curry - alt.internet.services. Adam started mtv.com and published information like this via finger, gopher and later the world wide web.

Yesterday somebody asked me about provider-independent addresses in IPv6, because of the old 'renumbering sucks' reason. At that moment I did remember that there is a sort-of provider-independent option, but it is relatively new and IPv6 purists frown upon it, so you probably will not get a provider-independent allocation just because you don't like renumbering. This does show the 'roots' of IPv6 being in the time when classless inter-domain routing and aggregation were seen as the best solution for routing table growth. But in the end: renumbering is not so nice, and can cause interruptions in internal reachability. With full NAT and just one external address renumber operations never affect internal services.

But, later I remembered there is a solution in IPv6 for this, because it is possible to configure multiple addresses on any interface in IPv6, and outgoing traffic will prefer to reach a service on the same class of address, with a preference set for each 'type' of address, as listed in /etc/gai.conf in Linux. And there are equivalent tables in other operating systems.

The solution is: assign all clients both a 'unique local' and a 'global' IPv6 address. The 'global' IPv6 address is the one which 'may change'. When announcing both address ranges via the router announce protocol, clients will configure both types. More about unique local addresses in Unique local address - Wikipedia English but the important here is that they are in the fc00::/7 IPv6 address range.

Publish the internal-facing services, such as file-servers, authentication-servers and time-servers with their unique local address and the external-facing services such as web-servers with their global address. Yes, some services will have both type of address. Views in DNS will help you hide those internal-only services.

Nice theory, but I had to test this! So I calculated an IPv6 unique local address range using bits of RFC 4193 Officially, fd00::/8 is the part in use for 'prefix generated from random numbers', but I tested with an address in the range fc00::/8. Little oops and being eager to test things there on my part. I configured radvd accordingly in /etc/radvd.conf:

interface eth0.3
{
   AdvSendAdvert on;
   prefix ::/64 {
                AdvOnLink on;
                AdvAutonomous on;
                AdvPreferredLifetime 604800; 
                AdvValidLifetime 2592000;
   };
   prefix fc5c:2186:e460:2::/64 {
                AdvOnLink on;
                AdvAutonomous on;
                AdvPreferredLifetime 604800; 
                AdvValidLifetime 2592000;
        };
   RDNSS 2001:980:14ca:42::694 {
   };
};   

The prefix :: line is to automatically copy the assignment which dhcp6c in prefix-delegation mode adds to it.

This causes the correct configuration on a client:

# ip -6 addr ls dev wlan0
3: wlan0:  mtu 1500 qlen 1000
    inet6 fc5c:2186:e460:2:21f:e1ff:fe45:2894/64 scope global dynamic 
       valid_lft 2591560sec preferred_lft 604360sec
    inet6 2001:980:14ca:2:21f:e1ff:fe45:2894/64 scope global dynamic 
       valid_lft 2591560sec preferred_lft 604360sec
    inet6 fe80::21f:e1ff:fe45:2894/64 scope link 
       valid_lft forever preferred_lft forever

I also had to configure the unique local address range on the home router/server, both as a 'service' IP and a 'network interface' IP. IPv6 services live on eth0.42, the interface to the wireless network is eth0.3.

# ip -6 addr add fc5c:2186:e460::694/128 dev eth0.42
# ip -6 addr add fc5c:2186:e460:2::1/64 dev eth0.3

And now I added a service with both type of addresses to DNS, and it works:

$ host resolver
resolver.idefix.net has IPv6 address 2001:980:14ca:42::694
resolver.idefix.net has IPv6 address fc5c:2186:e460::694
$ host www.google.com resolver
Using domain server:
Name: resolver
Address: fc5c:2186:e460::694#53
Aliases: 

www.google.com is an alias for www.l.google.com.
www.l.google.com has address 209.85.147.104
www.l.google.com has address 209.85.147.105
www.l.google.com has address 209.85.147.106
www.l.google.com has address 209.85.147.99
www.l.google.com has address 209.85.147.147
www.l.google.com has address 209.85.147.103
www.l.google.com has IPv6 address 2a00:1450:400c:c01::63

That is.. after I added the home unique local range to the acl in named.conf.options. Which confirms the source address of the unique local range is used. For a service which shows no unique local address, the global address is used:

$ host www.google.com resolver.xs4all.nl
Using domain server:
Name: resolver.xs4all.nl
Address: 2001:888:0:6::66#53
Aliases: 

www.google.com is an alias for www.l.google.com.
www.l.google.com has address 209.85.147.103
www.l.google.com has address 209.85.147.104
www.l.google.com has address 209.85.147.105
www.l.google.com has address 209.85.147.147
www.l.google.com has address 209.85.147.99
www.l.google.com has address 209.85.147.106
www.l.google.com has IPv6 address 2a00:1450:400c:c01::63

Now on documenting this I wonder what happens when radvd reconfigures itself and sees 2 addresses, one of which it is to pick up and one of which is in its own configuration. For now, this works. This may become unstable when the global address changes, which means radvd.conf will have to be generated in a more robust way from the prefix information found by dhcp6c. Learned: yes, this breaks when the global IPv6 address is removed by dhcp6c.

Update: This even works with a Linux-based router when the clients only have a global IPv6 address and the services are reachable on unique local addresses.

Update: A few weeks later the Internet connectivity was shortly interrupted, which means dhcp6c removes the global IPv6 addresses from the interfaces. So radvd started advertising the fc00::/7 address twice. To fix that both advertised addresses have to be in radvd.conf.

After starting with using rdnssd to use IPv6 resolvers on my laptop I sometimes note the following in the logs on the server:

Dec 14 17:55:24 greenblatt named[16213]: client fe80::21f:e1ff:fe45:2894%5#35985: query (cache) 'local/SOA/IN' denied

I guess my laptop uses link-local IPv6 addresses for the first few dns queries. Strange, because it only knows the address of the resolver because it has received a router announcement. The most logical explanation is that the system is still trying to detect duplicate addresses before actually assigning the global IP, but DNS traffic is already going out because some script in my browser is very anxious to fetch updates. Anyway, configuring the resolver to see fe80::/10 as a local network which is allowed to do queries does not help.

Google may be very careful with making their services available via IPv6, but internally they are going further already: Usenix: Google deploys IPv6 for internal network - ITWorld.

Google has learned that an IPv6 migration involves more than just updating the software and hardware. It also requires buy-in from management and staff, particularly administrators who already are juggling too many tasks. And, for early adopters, it requires a lot of work with vendors to get them to fix buggy and still-unfinished code.

The migration to IPv6 is not an L3 problem. It is more of an L7-9 problem: resources, vendor relation-ship/management, and organizational buy-in.

Paper: Deploying IPv6 in the Google Enterprise Network. Lessons learned. Haythum Babiker, Irena Nikolova, Kiran Kumar Chittimaneni.

The paper notes that a big problem with "IPv6 support" in networking devices means "support in software" which will cause CPU load at real usage. Some interesting bugs in IPv6 implementations were also showing, such as router announcement packets leaking from one wireless VLAN to the other. My best guess: a not-too-brilliant implementation of multicast.

Google also received the big vendor IPv6 lie:

When trying to talk to the ven-dors they were always saying - if there is a demand for IPv6 support at all, we’ve never heard it before.

That is what they tell every client with questions about IPv6.

Found via Google Deploys IPv6 For Internal Network - Slashdot.

Read somewhere today:

Just got a support call to add some IPv6 addresses to one of our mail clusters, since a customer needed to mail one of their partners in China, who did not have MX in IPv4 space...

IPv4 address exhaustion is REAL. And it is happening now. You need IPv6 to talk to the entire Internet.

I heard about rdnssd today at the NLUUG meeting I attended. I gave it a try on my laptop. As an ubuntu package it uses the resolvconf package. I had to change the /etc/resolvconf/interface-order file to use the rdnssd results before the dhcpv4 answers:

# interface-order(5)
lo.inet*
lo.dnsmasq
lo.pdnsd
lo.!(pdns|pdns-recursor)
lo
000.rdnssd
tun*
tap*
hso*
eth*
ath*
wlan*
ppp*
*

And now I get the resulting /etc/resolv.conf I want:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 2001:980:14ca:42::694
nameserver 10.42.2.1
search idefix.net koos.koffie.dot

And resolver traffic goes over IPv6.

Update 2011-11-25: Trying the same on a workstation on the wired network doesn't give the right result:

$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

Yes, empty. No data from rdnssd and no data from dhclient. Back to the working config...

Vandaag naar de NLUUG najaarsconferentie 2011 "Networking: IPv6 en de rest.." geweest. Inspirerend, gehoord over IPv6 (nieuwe dingen geleerd over DHCPv6 en over IPv6 unique local adresses). Daarnaast bijgepraat over dnssec, waar ik ook weer eens tijd in moet steken.

A real IPv6 portscan!

Sep 22 10:55:34 greenblatt kernel: [3664265.488791] FW reject: IN=ppp0 OUT= MAC= SRC=2001:0000:53aa:064c:3cf9:7720:bc59:4ca0 DST=2001:0980:14ca:0042:0000:0000:0000:0694 LEN=80 TC=0 HOPLIMIT=59 FLOWLBL=0 PROTO=TCP SPT=52215 DPT=1025 WINDOW=12200 RES=0x00 SYN URGP=0 
Sep 22 10:55:34 greenblatt kernel: [3664265.488874] FW reject: IN=ppp0 OUT= MAC= SRC=2001:0000:53aa:064c:3cf9:7720:bc59:4ca0 DST=2001:0980:14ca:0042:0000:0000:0000:0694 LEN=80 TC=0 HOPLIMIT=59 FLOWLBL=0 PROTO=TCP SPT=48673 DPT=445 WINDOW=12200 RES=0x00 SYN URGP=0 
Sep 22 10:55:34 greenblatt kernel: [3664265.500075] FW reject: IN=ppp0 OUT= MAC= SRC=2001:0000:53aa:064c:3cf9:7720:bc59:4ca0 DST=2001:0980:14ca:0042:0000:0000:0000:0694 LEN=80 TC=0 HOPLIMIT=59 FLOWLBL=0 PROTO=TCP SPT=49612 DPT=3306 WINDOW=12200 RES=0x00 SYN URGP=0 
Sep 22 10:55:34 greenblatt kernel: [3664265.554699] FW reject: IN=ppp0 OUT= MAC= SRC=2001:0000:53aa:064c:3cf9:7720:bc59:4ca0 DST=2001:0980:14ca:0042:0000:0000:0000:0694 LEN=80 TC=0 HOPLIMIT=59 FLOWLBL=0 PROTO=TCP SPT=44686 DPT=110 WINDOW=12200 RES=0x00 SYN URGP=0 
..
Sep 22 11:08:05 greenblatt kernel: [3664584.510834] FW reject: IN=ppp0 OUT= MAC= SRC=2001:0000:53aa:064c:3cf9:7720:bc59:4ca0 DST=2001:0980:14ca:0042:0000:0000:0000:0694 LEN=80 TC=0 HOPLIMIT=59 FLOWLBL=0 PROTO=TCP SPT=47639 DPT=1801 WINDOW=12200 RES=0x00 SYN URGP=0 
Sep 22 11:08:07 greenblatt kernel: [3664581.057958] FW reject: IN=ppp0 OUT= MAC= SRC=2001:0000:53aa:064c:3cf9:7720:bc59:4ca0 DST=2001:0980:14ca:0042:0000:0000:0000:0694 LEN=80 TC=0 HOPLIMIT=59 FLOWLBL=0 PROTO=TCP SPT=52005 DPT=301 WINDOW=12200 RES=0x00 SYN URGP=0 
Sep 22 11:08:07 greenblatt kernel: [3664581.078910] FW reject: IN=ppp0 OUT= MAC= SRC=2001:0000:53aa:064c:3cf9:7720:bc59:4ca0 DST=2001:0980:14ca:0042:0000:0000:0000:0694 LEN=80 TC=0 HOPLIMIT=59 FLOWLBL=0 PROTO=TCP SPT=45484 DPT=7800 WINDOW=12200 RES=0x00 SYN URGP=0 
Sep 22 11:08:08 greenblatt kernel: [3664581.282670] FW reject: IN=ppp0 OUT= MAC= SRC=2001:0000:53aa:064c:3cf9:7720:bc59:4ca0 DST=2001:0980:14ca:0042:0000:0000:0000:0694 LEN=80 TC=0 HOPLIMIT=59 FLOWLBL=0 PROTO=TCP SPT=42826 DPT=27356 WINDOW=12200 RES=0x00 SYN URGP=0 

I wonder which portscanner would use teredo..

whois 2001:0000:53aa:064c:3cf9:7720:bc59:4ca0

Querying for the IPv4 endpoint 67.166.179.95 of a Teredo IPv6 address.

#
American Registry for Internet Numbers NET67 (NET-67-0-0-0-0) 67.0.0.0 - 67.255.255.255
Comcast Cable Communications, Inc. COMCAST (NET-67-160-0-0-1) 67.160.0.0 - 67.191.255.255
Comcast Cable Communications, Inc. CHESTERFIELD-13 (NET-67-166-160-0-1) 67.166.160.0 - 67.166.191.255

In een interresante combinatie van spooknota en IPv6: Spooknota’s voor IPV6Register. Het lijkt er op dat je uiteindelijk betaalt om een informatiesite over IPv6 te mogen bezoeken.

Following the mp3 stream from Hx2 radio Hackerspaces signal from the Chaos communications congress and I suddenly notice something:

$ host broadcast.sonologic.net
broadcast.sonologic.net has address 82.94.245.7
broadcast.sonologic.net has IPv6 address 2001:888:2156::2:2:9

All available via IPv6.

It is well-known that all IPv4 address blocks are either allocated or reserved for very good reasons, but some IP addresses in logs still make me think 'huh?' when I see them, thinking they might be reserved when they are for sure given out now. Stuff like:

Jul  1 09:12:17 greenblatt sshd[841]: Invalid user data from 1.9.21.4
Jul  1 09:12:23 greenblatt sshd[846]: Invalid user data from 1.9.21.4
Jul  1 09:12:26 greenblatt sshd[849]: Invalid user data1 from 1.9.21.4
Jul  1 09:12:28 greenblatt sshd[851]: Invalid user data2 from 1.9.21.4
Jul  1 09:12:34 greenblatt sshd[858]: Invalid user data4 from 1.9.21.4
Jul  1 09:12:37 greenblatt sshd[862]: Invalid user data1 from 1.9.21.4

Even the ssh scanners are popping up in the 'new' IPv4 ranges. And a quite stupid one too.

I am at the surfnet office this afternoon, and that is a great opportunity to test my scripts for dynamic ipv6 addresses depending on network. Surfnet gives out 'real' IPv4 (no NAT) addresses on their wireless and IPv6 addresses.

Yes it works:

3: wlan0:  mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:1f:e1:45:28:94 brd ff:ff:ff:ff:ff:ff
    inet 145.96.2.161/22 brd 145.96.3.255 scope global wlan0
    inet6 2001:610:188:431:14b8:6159:f87f:20fd/64 scope global secondary dynamic 
       valid_lft 604014sec preferred_lft 85014sec
    inet6 2001:610:188:431:21f:e1ff:fe45:2894/64 scope global dynamic 
       valid_lft 2591994sec preferred_lft 604794sec
    inet6 fe80::21f:e1ff:fe45:2894/64 scope link 
       valid_lft forever preferred_lft forever

One downside: the 'old' dynamic address was deleted from the interface with my ssh sessions still running. Time to tweak the settings a bit more to fix this.
Second thought: Maybe a complete wireless disconnect / connect caused this. The current settings for temporary address lifetimes:

net.ipv6.conf.wlan0.temp_valid_lft = 604800
net.ipv6.conf.wlan0.temp_prefered_lft = 86400

604800 seconds is one week, 86400 seconds is one day.

I like having the 'predictable' IPv6 address for my laptop at home, but at the same time I was pondering the implications of having the same EIU-64 address everywhere. Which can be fixed by enabling the privacy extensions.

As I use wicd for connection management I had a look at Adding pre and post (dis)connection scripts - Wicd Wiki which showed clear options. The easiest way to 'recognize' my home networks is by assigned v6 range. So I created /etc/wicd/scripts/postconnect/ipv6privacychoice with:

#!/bin/bash

connection_type="$1"

if [ "${connection_type}" == "wired" ]; then
        v6prefix=`rdisc6 eth0 -q -1`
        if [ "${v6prefix}" = "2001:980:14ca:1::/64" ]; then
                sysctl net.ipv6.conf.eth0.use_tempaddr=0
        else
                sysctl net.ipv6.conf.eth0.use_tempaddr=2
        fi
elif [ "${connection_type}" == "wireless" ]; then
        v6prefix=`rdisc6 wlan0 -q -1`
        if [ "${v6prefix}" == "2001:980:14ca:2::/64" ]; then
                sysctl net.ipv6.conf.wlan0.use_tempaddr=0
        else
                sysctl net.ipv6.conf.wlan0.use_tempaddr=2
        fi
else
        echo "Unknown connection type: ${connection_type}"
        exit
fi

Too bad I'll be in a location with only legacy IP or completely 'disconnected' today, so I can't really follow everything around World IPv6 day.

But things are up and running. Things I noted sofar: The AMS-IX sFlow IPv6 stats seem to show a drop in IPv6 traffic. Caused by the Microsoft ipv6day patch? And the Akamai IPv6 Statistics show not a lot of traffic, given what Akamai should process in theory.

Update : DE-CIX traffic statistics (scroll down a bit for IPv6) show an uptake in IPv6 traffic.