Messaging Over IPv6 Headers
elias miles writes "A guy from the Swiss Unix Users Group made a cool utility that lets you chat over IPv6 packet headers. Not useful, but it's a nice hack.
Read the article and download joe 6 pack."
← Back to Stories (view on slashdot.org)
As in the "radio stations" which broadcast some OTP numbers / instructions for spies / whatever, why not make this broadcast public keys of those whom you know along with your normal traffic. Then you could run a modified Joe Sixpack in the background and gather the keys that way.
Or broadcast DNS information (suitably protected), creating a distributed naming service without DNS servers :-)
The motivation behind broadcasting is that if all the rest of the world is against you, your odds are so small that you will lose. But if the bad guys only get like 1 % of the rest of the world, you have a chance of winning. Supermegaprobabilisticexpialidocius!
This is known as a covert channel. Depending on what is going on this is useful or a security risk. For example, an employee could smuggle out data from a network possibly under the radar of most IDSes and the eyes of net admins. Replace employee with political prisioner, or spy, or whathave you.
espo
The Joe 6 Pack uses IPv6 destination options to specify a special option that contains the chat message...
The actual IPv6 packet being sent is an ICMPv6 echo-reply packet that seems to contain all nulls.
This makes the destination option seem a bit redundant...
You could implement this using nothing but ICMP (over either IPv4 or IPv6).
In the ICMP echo data, build some kind of header:
(4 bytes) magic identifier, i.e. 0xBAADF00D
(n bytes) message
(4 bytes) CRC-32 checksum of the previous n+4 bytes
The CRC-32 checksum is there to differentiate between "chat-pings" and "real pings".
I started to implement this as a special ping program (so you could do something like ping 1.2.3.4 --msg hi!) and maybe will finish it when I'm less busy.
void*x=(*((void*(*)())&(x=(void*)0xfdeb58)))();
- Cisco routers suck at IPv6.
Many of cisco's routers use the router's CPU to process IPv6 packets instead
of the fast-path. The reasons for this are explained in the next few points.
While Juniper's routers are substantially better at IPv6 than cisco's,
IT managers are often restrained by insane corporate policy that dictactes
the use of cisco.
- There are too many addresses.
There are 16.7 million addresses per square metre of the earth's surface,
including the oceans. This is overkill. The world does not need more than
the 4 billion addresses available with IPv4, and I challenge you to come up
with an application that requires that many. Assuming that you can actually
come up with one, it could easily be solved with
Network Address Translation, or NAT as it is commonly known.
- IPv6 addresses are too large.
An IPv6 address is 128 bits in size - 64 bits of which are reserved for
addressing hosts, and 64 bits of which are reserved for routing. One thing
that is cool with IPv6 is address autoconfiguration. Take your 56-bit
MAC address on your ethernet card, ask for 64-bits of network prefix,
bang it together with EUI-64 and you are set. The problem with a 64-bit
network prefix is that routing tables become massive. Just do the math and
you'll see that extreme amounts of memory are required to hold routing
tables.
- The IPv6 header is too large.
An IPv4 header compact at 20 bytes in length, while the IPv6 is bloated at
40 bytes. That's right people, each one of your IP packets has twice as
much overhead as before. While this may not sound much, IP networks have a
requirement that the minimum MTU supported must be 576 bytes. That means
that where you might have got 556 bytes of data in your IP packets, you now
get 536 bytes. This means that downloading stuff will take 3.4% longer.
Sure, IPv6 allows for nice hacks like those described in this article, but is it really ready for prime time?