Slashdot Mirror


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."

7 of 70 comments (clear)

  1. Re:amusing fact by Anonymous Coward · · Score: 2, Informative

    here's another amusing fact
    the swiss don't, as a group, speak swedish.

  2. Re:amusing fact by Anonymous Coward · · Score: 1, Informative

    Right, because Swedish implies 'sweden,' whereas the Swiss are from Switzerland.

  3. Re:No need for destination options by sleeper0 · · Score: 2, Informative

    Implemented by hping2

    you can either do
    hping 1.2.3.4 -e your_message_here
    or
    hping 1.2.3.4 -E file-to-embed

    have fun!

  4. how about chatting over ping? by avel599 · · Score: 5, Informative

    "sonar"

    From the description of the Debian package:

    Description: console chat via ICMP (ping) echo-request packets sonar implements a peer to peer chat using ICMP (ping) echo-request packets, which means nearly stealth communication between two hosts without a central server.

    It has an ncurses-based interface with basic support for multiple windows and chats with different peers. It is a reference implementation for the u23 project of the Chaos Computer Club Cologne (http://koeln.ccc.de)

  5. Re:amusing fact by Anonymous Coward · · Score: 1, Informative

    Make that four: fr, it, de, rm.

  6. Re:again? by Cato · · Score: 4, Informative

    So many half-truths, so little time...

    Point 1 re 'Cisco sucks at IPv6' - do you have any data to back this up? Cisco seem to be doing fine with IPv6 deployments so I don't believe this is a real issue. More recent Cisco routers (7600, 10000, 12000 series) are hardware-based and will do IPv6 in hardware. Those that are software-based will forward IPv6 exactly like the other non-IPv4 protocols they have supported for years (DECnet, SNA, etc) - Cisco started out with multiprotocol routing not just IP. I'd be surprised if there is a big difference in performance - certainly there'll be more memory references with IPv6 addresses, but the IPv6 header (less the addresses) is shorter and simpler than the IPv4 header, so software-based routers may actually go faster on IPv6. Hardware-based routers should go at wire speed, basically.

    Point 2 - there are already 1 billion cell phones in the world, and perhaps 30% of those are already IP-enabled. If you add in VoIP phones at home, and the myriad of new devices such as TiVOs, you can easily see how a mere 4 billion addresses is not enough - remember that India and China alone have 2 billion people. NAT is a hack that prevents simple deployment of more complex applications that aren't merely client to server - P2P apps work much more easily without NAT.

    Point 3 - routing tables too large. Routing tables won't grow in size as you imply - if anything they are smaller for the true core routers, since IPv6 was designed to scale better using CIDR-like techniques for route aggregation, i.e. only a short prefix is stored and fewer prefixes should be needed. Your proposal for using the Ethernet-style MAC address doesn't work for ADSL, leased lines, and many other non-Ethernet media.

    Point 4 - this is true for MTU-sized packets, but of course the host can send larger packets (frequently 1500 bytes or so), reducing this overhead. A 1 to 3 % overhead doesn't sound like much given IPv6's other advantages.

    The fact that IPv6 allows stupid hacks like this is irrelevant. IPv6 is going to happen, it's just a question of time - my ADSL ISP already offers IPv6 as a checkbox option at no extra cost.

  7. Re:again? by psmears · · Score: 3, Informative

    I would have ignored this as a troll, but it's been modded "+4 Interesting" so it's probably worth providing some perspective to the points raised..

    1. Cisco routers suck at IPv6

    Even if true, this can hardly be described as a shortcoming with the protocol (though I agree it might be a problem in its deployment).

    2. There are too many addresses

    In what way is it a problem to have too many addresses available? It's not compulsory to use them all ;-). Indeed it's necessary to have them, since it's not possible to allocate the addresses in a way that doesn't waste addresses, and that's also scaleable, since it must be possible to perform aggregation in a way that reduces the size of the routing tables...

    NAT is not a solution to everything. In particular it prevents a lot of peer-to-peer type applications (and I don't just mean downloading MP3s - IP telephony is a good example!)

    3. IPv6 addresses are too large.

    Erm... 128 bits is four times the size of IPv4's 32 bits. That means that the routing tables will take up at most four times what they do at the moment. Even assuming 200,000 prefixes (an overestimate according to this, the full FIB can be stored in under 10Mb. The full BGP table (including attributes) would obviously be larger - but we're hardly talking "extreme amounts of memory"!

    4. The IPv6 header is too large

    This is plain misleading. For most links the MTU is 1500 bytes or larger, so the difference is closer to 1%. For links where the overhead is significant (e.g. dial-up links) it's normal to use PPP header compression, which all but eliminates the extra overhead.