Tuesday, June 5, 2012

Linux 3.2 shows IPv6 addresses used in route table

I'm running Ubuntu 12.04 with Linux 3.2.0. I just saw that "ip -6 route show" shows an enormous list of IPv6 addresses. After some research, it looks all IPv6 address that are used (by a webbrowser or any other program), get added to that list. The entries have a short life: after a few minutes, they're gone (if not re-visited). Maybe it's just a list of active IPv6 connections?

I had a look on my Ubuntu Server 11.10 (with Linux 3.0), and there the ipv6 route list just shows the usual default gateway and the local LAN addresses, and not all the IPv6 sites visited. So it's a change between Linux 3.0 and 3.2?

I don't know why that is done. Does it make IPv6 network communication faster? If so, why is it not done for IPv4 ("ip route show" does not show sites visited)? Or is it used to keep parameters for each destination (like the cwnd at the end: cwnd = "clamp for congestion window")?

Anyway: Apart from the official goal, how can you (mis)use this feature? Some thoughts:
  • you can see which of the sites you've visited have IPv6
  • you can create some statistics: will the list grow in the coming time (months, years) with more websites introducing IPv6?
  • you can see which sites are visited by other users and processes on the system. Remember: you don't need root rights for "ip -6 route show". I don't know if that is a great feature as seen from a privacy point of view
  • ...


Funny commands:

ip -6 route show | grep via | grep -vi default  | awk '{ print "host " $1 }'  | /bin/sh | grep -vi "not found"
ip -6 route show | grep via | grep -vi default  | awk '{ print "whois " $1 }' | /bin/sh | grep -i -e netname -e inet6num -e descr 


IPv6 route table on my system:

ubuntu@ubuntu:~$ ip -6 route show | grep via | grep -vi default
2001:470:0:64::2 via fe80::5267:f0ff:fed7:61fb dev wlan0  proto static  metric 1024  rtt 168ms rttvar 75ms cwnd 10
2001:610:188:301:145:0:2:10 via fe80::5267:f0ff:fed7:61fb dev wlan0  proto static  metric 1024  rtt 80ms rttvar 85ms cwnd 4
2001:610:510:0:192:42:113:60 via fe80::5267:f0ff:fed7:61fb dev wlan0  proto static  metric 1024  rtt 28ms rttvar 20ms cwnd 10
2001:680:12:130::3e29:130a via fe80::5267:f0ff:fed7:61fb dev wlan0  proto static  metric 1024 
2001:680:12:130::3e29:1330 via fe80::5267:f0ff:fed7:61fb dev wlan0  proto static  metric 1024  rtt 30ms rttvar 16ms cwnd 10
2001:6a8:3c80::39 via fe80::5267:f0ff:fed7:61fb dev wlan0  proto static  metric 1024  rtt 34ms rttvar 10ms cwnd 10
2001:720:418:cafd::20 via fe80::5267:f0ff:fed7:61fb dev wlan0  proto static  metric 1024 
2001:888:0:18::80 via fe80::5267:f0ff:fed7:61fb dev wlan0  proto static  metric 1024 
2001:888:2000:63:194:109:35:48 via fe80::5267:f0ff:fed7:61fb dev wlan0  proto static  metric 1024 
2001:41d0:2:bb58:dead:beef:8637:e45b via fe80::5267:f0ff:fed7:61fb dev wlan0  proto static  metric 1024  rtt 248ms rttvar 227ms cwnd 10
2406:da00:ff00::1715:b9ae via fe80::5267:f0ff:fed7:61fb dev wlan0  proto static  metric 1024 
2406:da00:ff00::3211:f660 via fe80::5267:f0ff:fed7:61fb dev wlan0  proto static  metric 1024 
2406:da00:ff00::b849:f31c via fe80::5267:f0ff:fed7:61fb dev wlan0  proto static  metric 1024 
2620:0:1c18:0:face:b00c:0:7 via fe80::5267:f0ff:fed7:61fb dev wlan0  proto static  metric 1024 
2a00:1450:4007:802::1012 via fe80::5267:f0ff:fed7:61fb dev wlan0  proto static  metric 1024  rtt 46ms rttvar 32ms cwnd 10
2a00:1450:8005::68 via fe80::5267:f0ff:fed7:61fb dev wlan0  proto static  metric 1024 
2a02:26f0:7:1:8000::eed via fe80::5267:f0ff:fed7:61fb dev wlan0  proto static  metric 1024 
2a02:26f0:7:1:8800::eed via fe80::5267:f0ff:fed7:61fb dev wlan0  proto static  metric 1024 
2a02:26f0:7:1:8d00::236 via fe80::5267:f0ff:fed7:61fb dev wlan0  proto static  metric 1024 
2a02:26f0:7:1:8f00::236 via fe80::5267:f0ff:fed7:61fb dev wlan0  proto static  metric 1024 
2a02:26f0:7:1:9100::eed via fe80::5267:f0ff:fed7:61fb dev wlan0  proto static  metric 1024 
2a02:26f0:7:1:9700::236 via fe80::5267:f0ff:fed7:61fb dev wlan0  proto static  metric 1024

Comments are welcome!

Update:

Info from Iljitsch van Beijnum https://twitter.com/#!/iljitsch and http://www.muada.com/ : the above is "route cloning". Info from an IBM site:


Route cloning
Route cloning allows a host route to be created for every host that a system communicates with.

When network traffic is about to be sent, a search is done of the routing table to find a route to that host. If a specific host route is found, it will be used. If a specific host route is not found, a network route or the default route may be found. If the route that is found has the cloning flag, 'c', set, a host route for the destination will be created using the gateway from the route that is being cloned. Subsequent routing table searches for that destination will find the cloned host route. Cloned routes have the 'W' flag set. These routes will time out and be deleted from the routing table if they are unused for route_expire minutes. You can modify route_expire by using the no command.

The route cloning feature is used mainly by the path MTU discovery protocol within AIX® to allow it to keep track of path MTU information for every destination it communicates with. If the network options tcp_pmtu_discover or udp_pmtu_discover (settable with the no command) are 1, the cloning flag is turned on for all network routes on the system. In AIX 4.3.3 and later, path MTU discovery is on by default.


1 comment:

Anonymous said...

The information from Iljitsch van Beijnum is not completely correct.

The "cloned" routes do exist, but they are stored in a different table, and not shown by default: ip -6 route show table cache

The ones you see in the default table are static, and they are added due to a bug in NetworkManager.