I've found, on the net, a number of references to people who have found odd packets on their firewall or system logs, originating at 127.0.0.0/24 and to 108.122.0.0, usually with the IPv6 hop-by-hop option set. The replies are generally reassuring: for example, one of the reasons that these messages are spotted by system administrators on Solaris boxes is due to a misconfiguration in Solaris.
However such 'mis'configurations are fortuitous. Repeated packets to 108.122.0.0 are evidence that an attacker is attempting to use your machine as an unwitting host for attacks on others. Almost certainly someone unknown to you has root on your machine. They'll have logged in, they're probably sniffing your passwords, or putting "warez" in your html directories.
Whatever the circumstance, packets to 108.122.0.0 are suspicious: I'll explain why later. These packets are generated by a certain DDoS client operating erroneously. A DDoS client is a compromised machine which has has software installed so that it, and others like it, can be controlled centrally, and commanded to attack a third-party who has angered the attacker.
I will not identify the DDoS system here to avoid unduely drawing the attention of malware writers to this page, as it could be used to correct the fault here-described, but a good google for terms herein should put you on the right tracks. In particular, indexing engines are probably not clever enough to know that the name of the system concerned means wire which has barbs in a Teutonic language.
If you are seeing such traffic, I strongly advise you to remove the machine concerned from the network, unless it is mission-critical, and in all cases to attempt detection of rootkits or DDoS systems on your machine. As utilities will almost certainly have been hacked, the tools available to your are minimal. tcpdump is vital, and usually in-tact. Run tcpdump -vvvXX ip proto \\icmp and look for response packets, ten seconds apart about once a minute, to unknown addresses, and containing the strings skillz or ficken, from 127.0.0.0/24. You can also check for these in the firewall logs, if you block ICMP (ping etc). This is the definitive diagnosis. If you are seeing these packets regularly, there is one positive point, the client has been unable to establish communicaiton to the handler.
However, this traffic has been carefully designed not to be easily spottable. What you saw, the packets from 127.0.0.0/24 to 108.122.0.0, with IPv6 hop-by-hop set (sometimes called as "ip protocol 0") are a result of a poorly coded part of the DDoS system handling errors badly. In particular, as described above, the system communicates stealthily using ICMP echo-response packets. Its checking is poor, and it responds to most ICMP packets which are incoming as commands from its controller.
If its outgoing packets (the definitive diagnosis above) fail to reach their destination, your firewall or router will legitimately send an ICMP packet, describing the failure, in response. This is one of the legitimate uses of ICMP. The DDoS system incorectly interprets the response as a command to attack. A correct response from many firewalls, in particular, is interpreted as a command to attack 108.122.0.0 for a short peroid of time. You will notice that 108 and 122 are l and z in ASCII. The legitimate error response includes the covert outgoing packet in its reply, and those two letters in the original message fall into what the client treats as the "where to attack" field. The zeros are form the padding immediately following the word skillz.
108.122.0.0/16 is unallocated, and always has been, as far as I can tell. It is part of a big block which is held in reserve. This is one of the reasons these packets are sometimes rejected. This is fortunate! Also the packet "encodes" a very short attack, it seems. They occur in flurries of a few thousand, slightly less often than one a minute.
Other features of the DDoS system make these packets strange. A further bug in the software means that the IP type of the flood is set to zero (presumably through either a misguided belief that hop-by-hop can make an IPv4 packet more destructive, or just a failure to think of a better value for these loitering and purposeless packets). Many firewalls take objection to this option, and reject the packet.
Also, the system chooses the originating address of the packet to be 127.0.0.0/24, (ie 127.0.0.x for any x). If it correctly named the machine, then the attacker would be able to identify which "zombies" were attacknig its machine, so instead these fake addresses are used. These show up on many systems (including solaris boxes as mentioned above) as being illegitimate source addresses.
When you are convinced your machine has been attacked, you should call in a security expert, your system administrator, or helpline. If you are knowledgable in this field, this page will take you to the resources you need.
The above is not definitive in diagnosis, though it's pretty damn close. You should check for the ICMP packets above.
In summary, then:
If you would like further information, and can convince me of your bona fides, email me at dans@chiark.greenend.org.uk. I can certainly not guarantee a timely response, though; so don't rely on me as your tech support!
Our attacker covered his tracks with the suckit rootkit, as seems to be standard practice, these days. Therefore most of the detection tools on the above analysis page will not work (lsof, netstat, etc). tcpdump doesn't seem to have been intercepted though, and would be complex to fake convincingly. The presence of the odd packets emitted by this tool were actually what alerted me to the rootkitting.
For example, these messages look like being from people who may been hacked: