Temporary or Rogue IPv6 addressesRecently I noted a couple of plain wrong IPv6 addresses assigned on my computers starting with 4006
inet6 addr: 4006:627:c0a8:b229:ba27:ebff:fe54:e182/64 Scope:Global
inet6 addr: 4006:41d5:c0a8:b229:ba27:ebff:fe54:e182/64 Scope:Global
inet6 addr: 4006:7bdc:c0a8:b229:ba27:ebff:fe54:e182/64 Scope:Global
inet6 addr: 4006:a1c7:c0a8:b229:ba27:ebff:fe54:e182/64 Scope:Global
inet6 addr: 4006:d2eb:c0a8:b229:ba27:ebff:fe54:e182/64 Scope:Global
inet6 addr: 4006:6497:c0a8:b229:ba27:ebff:fe54:e182/64 Scope:Global
inet6 addr: 4006:1b90:c0a8:b229:ba27:ebff:fe54:e182/64 Scope:Global
inet6 addr: 4006:e687:c0a8:b229:ba27:ebff:fe54:e182/64 Scope:Global
inet6 addr: 4006:dcba:c0a8:b229:ba27:ebff:fe54:e182/64 Scope:Global
inet6 addr: 4006:b147:c0a8:b229:ba27:ebff:fe54:e182/64 Scope:Global
inet6 addr: 4006:f643:c0a8:b229:ba27:ebff:fe54:e182/64 Scope:Global
inet6 addr: 4006:e666:c0a8:b229:ba27:ebff:fe54:e182/64 Scope:Global
inet6 addr: 4006:3067:c0a8:b229:ba27:ebff:fe54:e182/64 Scope:Global
inet6 addr: 4006:6a6c:c0a8:b229:ba27:ebff:fe54:e182/64 Scope:Global
Others also observed ipv6 addresses starting with 4011, 8006 and 8011. In my case this happens on a Fritz Box 7340, but reports have
shown this happens on other routers as well. While several sites describe this issue, no cause or remedy is provided. As this is
something happening at my network as well I wanted to know what is going on.
Network setupMy home network consists of a raspberry pi running linux, a windows 7 desktop with several linux vm's on it, a windows 8 laptop (also running some linux vms) two iPads and 5 mobile phones - all behind a single Fritz Box 7340. (the pi and desktop are connected via the wire.)I am running dual stack IPv4 and IPv6 on my network. The causeThe common start of all addresses currently is4006:xxxx:c0a8:b229 sometimes the last 4 positions are different, and the rest of the addresses present on the machines
depends on the machine having the address.While reading the post IPv6-Präfix 4006:: im Heimnetz on the kdgforum it became clear that the Fritz Box invalidates all wrong IPv6 addresses for 3 router advertisement cycles by sending the prefix with a valid lifetime of 7200 sec and a preferred lifetime of 0 sec. (The 7200 sec valid lifetime is used because of a bug in Vista.) While this explains why all computers get addresses with this prefix, this does not make clear what client uses this address and why it uses this address. Analysis of the shown IPv6 address prefix shows that (in my case) these consist of 4006:random:c0a8:b229. I noted that this could be some part of an IPv4! packet, therefore I hex decoded the constant part. c0a8:b229 corresponds to 192.168.178.41 which indeed could very well be an valid IPv4 address on my network. Looking up the IPv4 address in the Fritz Box showed that this address is of one of my iPads so I decided to start a capture of the wlan interface (ath0) in the Fritz Box using http://fritz.box/capture.lua and use that particular iPad. Digging through the captured file using WireShark showed the cause of this behavior quite nicely: When things go wrong the following happens i have observed this twice: 0000 bc 05 43 ea be 92 78 7e 61 ee 16 83 86 dd 45 00 ..C...x~ a.....E. 0010 00 40 3e a3 40 00 40 06 a0 bd c0 a8 b2 29 40 e9 .@>.@.@. .....)@. 0020 a7 9c f1 29 00 50 f1 41 81 59 00 00 00 00 b0 02 ...).P.A .Y...... 0030 ff ff 32 fc 00 00 02 04 05 b4 01 03 03 05 01 01 ..2..... ........ 0040 08 0a 49 3b fb 58 00 00 00 00 04 02 00 00 ..I;.X.. ......This is an malformed IPv6/IPv4 packet containing the offending IPv6 or valid IPv4 address. When looking closely the Ethernet frame indicates this is an IPv6 packet (type 86 dd) while the IP packet indicates this is an IPv4 packet (the 4 right behind the 86 dd). Indeed the Fritz Box replies within 6 ms with a router advertisement, invalidating the wrong IPv6 address. 0000 33 33 00 00 00 01 bc 05 43 ea be 92 86 dd 60 00 33...... C.....`. 0010 00 00 01 00 3a ff fe 80 00 00 00 00 00 00 be 05 ....:... ........ 0020 43 ff fe ea be 92 ff 02 00 00 00 00 00 00 00 00 C....... ........ 0030 00 00 00 00 00 01 86 00 ba 9e ff 48 07 08 00 00 ........ ...H.... 0040 00 00 00 00 00 00 03 04 40 c0 00 00 1c 20 00 00 ........ @.... .. 0050 00 00 00 00 00 00 40 06 a0 bd c0 a8 b2 29 00 00 ......@. .....).. 0060 00 00 00 00 00 00 03 04 40 c0 00 00 1b 3d 00 00 ........ @....=.. 0070 00 00 00 00 00 00 40 06 01 1b c0 a8 b2 29 00 00 ......@. .....).. 0080 00 00 00 00 00 00 03 04 40 c0 00 00 1b 3c 00 00 ........ @....<.. 0090 00 00 00 00 00 00 40 06 3e 38 c0 a8 b2 29 00 00 ......@. >8...).. 00a0 00 00 00 00 00 00 03 04 40 c0 00 00 19 cb 00 00 ........ @....... 00b0 0e 10 00 00 00 00 20 01 09 80 37 6d 00 01 00 00 ...... . ..7m.... 00c0 00 00 00 00 00 00 19 03 40 c0 00 00 04 b0 fd 00 ........ @....... 00d0 00 00 00 00 00 00 be 05 43 ff fe ea be 92 05 01 ........ C....... 00e0 00 00 00 00 05 dc 18 01 00 08 00 00 07 08 18 02 ........ ........ 00f0 40 08 00 00 1c 20 40 06 a0 bd c0 a8 b2 29 18 02 @.... @. .....).. 0100 40 08 00 00 1b 3d 40 06 01 1b c0 a8 b2 29 18 02 @....=@. .....).. 0110 40 08 00 00 1b 3c 40 06 3e 38 c0 a8 b2 29 18 02 @....<@. >8...).. 0120 40 08 00 00 07 08 20 01 09 80 37 6d 00 01 01 01 @..... . ..7m.... 0130 bc 05 43 ea be 92This is the breakdown of the malformed packet:
Ether : bc 05 43 ea be 92
78 7e 61 ee 16 83
Type : 86 dd (IPv6)
Then the IP packet
IP version: 4
Hdr Len: 5
TOS 00
Total length 00 40
id 3e a3
flags+fragment offset 40 00
TTL: 40
Protocol: 06 (TCP)
header checksum: a0 bd
Source ip: c0 a8 b2 29 (192.168.178.41)
dest ip : 40 e9 a7 9c (64.233.167.156)
Source port: f1 29
Dest port: 00 50 (80)
sequence no: f1 41 81 59
ack no: 00 00 00 00
hdr len: b
reserved: 0
TCP flags: 02 (SYN)
Window size: ff ff
TCP checksum: 32 fc
Urgent: 00 00 02 04
Data:
05 b4 01 03 03 05 01 01 08 0a 49 3b fb 58 00 00 00 00 04 02 00 00
It must be noted that 14 microseconds (yes micro not milli!) before this wrong IPv4 TCP SYN for an HTTP connection an IPv6 TCP SYN for another HTTP connection is created, for some reason the Ethernet header
for the IPv4 packet is wrong!
This means that there probably is a race condition in the iPad or in the FritzBox or maybe even both!
SolutionWhile it would be best to fix the race condition altogether this may be very difficult. As this problem may be present in many different clients, given the other reports on this problem it would be very nice if the FritzBox would be updated to no longer send Router Advertisements when a malformed packet is received.As the prefixes 4006, 4011, 8006 and 8011 are observed it should be expected that different platforms are affected as the first part of observed prefix (40) correspond to the TTL commonly used on everything except Windows, and the other part (80) to the TTL of windows. The second part corresponds to TCP (06) and UDP(11). To capture traffic on a fritz box, one can use the http://fritz.box/html/capture.html url. a UUID generator on the web If you have improvements, contact information on the homepage of this host. An agent adding logging to your java programs at runtime The uptime of home.famkruithof.net |