[GTER] Ubiquitous IP

Frederico A C Neves fneves em registro.br
Segunda Abril 1 14:39:01 BRT 2002


                                                    D. Waitzman        bs"d
                                                    BBN Technologies
                                                    1 April 2002

                             Ubiquitous IP

Status of this Memo

   This memo defines Experimental Protocols for the Internet community.
   It does not specify Internet Standards of any kind.  Discussion and
   suggestions for improvement are requested.  Distribution of this memo
   is unlimited.  This memo is not an RFC.

Copyright Notice

   Copyright (C) David Waitzman (2002).  All Rights Reserved.

Abstract

   The Internet Protocol has become ubiquitous and can run over
   basically anything.  As an example, see RFC 1149, "A Standard for the
   Transmission of IP Datagrams on Avian Carriers".  This memo documents
   a number of new methods of transmission of IP datagrams.

   This is an experimental, not recommended, standard.

Overview and Rationale

   While IP can run over anything, the increasing use of firewalls
   threatens to make it impossible for some users to communicate.  The
   Internet philosophy has a fundamental belief that ability of all end
   systems to communicate with each other is of paramount importance.
   The only exception to this is the communication of SPAM, which is
   getting bad enough to make some of us in the Internet control room
   want to turn off the big switch that allows email to go through.

   This memo documents a number of new ways that IP can be encapsulated,
   thus increasing the ability of all to communicate.

   A number of the ideas take advantage of the fact that it is perfectly
   valid in IP for communications to be unidirectional.  Unlike
   protocols such as ATM with hard state and the associated set up
   phases requiring bidirectional communications, IP can be used for
   effective communications with just one packet.  This allows "passive
   networking" whereby fixed value IP packets are encapsulated on some
   medium for later transmission.


Waitzman                                                       [Page 1]

Not an RFC                    Ubiquitous IP                 1 April 2002

IP over IM

   Instant Messaging (IM) is widely implemented and there is ongoing
   work at standardizing the messaging formats.   IM is frequently
   allowed through firewalls.  IM therefore is a perfect vehicle for
   tunneling IP.  With a little end system work, a fairly high bandwidth
   channel can be created.  The IP packets merely need to be "ascii
   armored" for transmission as an IM.  With the use of font changes,
   such as bold face, a primitive priority labeling system can be
   applied at the link (aka IM) level.

IP over Bar Code

   IP over Bar Code is a variant of IP over Cellulose.  Consider the
   difficulty for supermarket staff to update the cash register
   computers with every different product's bar code information,
   because many new products arrive every week.  Note that as bar code
   technology increases, the storage capacity of the information
   increases.  This leads to a first cut solution of putting a URL to
   product information in the bar code.  This has the flaw in that is
   relatively inflexible.  With IP over Bar Code, the bar code
   encapsulates a sequence of IP packets to update the cash register, as
   needed, from the supplier's web site and possibly the supermarket
   chain headquarters web site.  An IM packet can even be in the bar
   code to flash to the cashier's monitor to check for a valid ID of the
   purchaser for liquor and other age controlled products.

   A variation with even more power is to have Active Networks packets
   in the bar code.  The purchase of a phone card could trigger an IP
   packet, to the Telephone company associated with the card, to
   activate the card in their network.

IP over Covert Channels

   T e us  o  C ve     an el  is  nt res i g    he c   le  e is   e
   imit d b t r  e a    ab e.  M re i   rm tio  i  av i ab   v ht p: /ww
   . s .go /     x    . t l

IP over PI

   The following encapsulation was suggested by an Enron Network
   Architect:

   Pi, the transcendental number, has infinite length but it is possible
   to determine the value of an arbitrary digit of Pi.  As any IP packet
   can be encoded as a sequence of numbers, it is possible to devise a
   sequence of equations that generate the indexes into Pi that
   correspond to an arbitrary IP packet.  Since Pi is well known, you
   don't need to transmit it.  Therefore, IP over Pi can be sent without
   sending the actual data, thus preserving it to be resold multiple
   times.


Waitzman                                                       [Page 2]

Not an RFC                    Ubiquitous IP                 1 April 2002



IP over SPAM

   If you look at many of the SPAM messages you receive, you will note a
   funny sequence of apparently random characters often appears in the
   subject line or the last lines of the message.  This is actually IP
   over SPAM.  A message, say from a politically undesired group, is
   compressed, encrypted, and encoded in a variant of uuencoding.  It is
   then split amongst multiple SPAM messages and broadcast out.  As SPAM
   reaches almost everybody, this solves the problem of the politically
   undesired group organized into distinct cells finding each others'
   email addresses, as the email addresses are forced to change due to
   surveillance by majority political parties.

IP over IETF List

   The IETF mailing list has a very low signal to noise ratio, with
   reoccuring religious battles and other nonsense.  IP Packets, encoded
   using MIME, can be broadcast into the IETF list and will rapidly
   reach most IETF members.  An equivalent to ICMP Destination
   Unreachable messages will be received as many "Out of the Office"
   messages.  The resulting increase in traffic on the list will likely
   not be noticeable amidst all the other junk traffic.

IP (Active Networks) over Active Roadways

   Also known as Smart Packets for Smart Roads for Dumb Drivers.

   Smart roads involves putting low powered directional transmitters in
   roadways to communicate information to drivers and/or their cars.
   For maximum flexibility, this can be done with IP packets.  An
   example is transmitting the current traffic regulations pertaining to
   that roadway or an upcoming intersection, such as "No left turn 7am
   to 9am".  This is particularly useful in times of inclement
   visibility by the driver, and would show the message in a heads up
   display (aka pop up window).

IP over Tin Cans

   This is an old idea whereby IP is sent over a taut wire between two
   tin cans.  Vibrations from a speaker impinging on a can at one end of
   the wire travel down the string to the other can and cause a
   corresponding vibration.  The latest revision from the IEEE now
   mandates the use of aluminum cans, as actual tin cans are obsolete.

   While the underlying technology is simple and easy to replicate, the
   encoding and decoding of IP packets is not trivial.  Old experiments



Waitzman                                                       [Page 3]

Not an RFC                    Ubiquitous IP                 1 April 2002


   piping the IP packets through /dev/audio on Suns generated packets
   fine, but the receiver logic was never debugged.

   Excessive line noise due to stuff left in the cans means FEC (Food
   Error Correction) is critical.

IP over Cosmic Strings

   This is conceptually a variation of IP over Tin Cans.  It again is a
   point to point technology.

   Cosmic strings have strange properties and possibly not-quite-finite
   length.  It is also believed that the propogation time through the
   string may not be bound by the speed of light.  The endpoints of the
   string, in order to have a stable base for transmitting and receiving
   packets, may need to be dark matter based.  Thus while the technical
   hurdles to implement the technology are high, the payoff is huge.
   (Please consider this paragraph to be prior art to any patent claims
   over the next few hundred years with this technology.)

IP over matter spiraling into a Black Hole

   When matter spirals into a black hole, huge bursts of X-rays are
   emitted.  With careful control over the injection rate, a bit
   encoding, similar to that used on ethernet, can be used to encode IP
   in the X-ray bursts.  The advantage to this scheme is that it is a
   truely Universal broadcast medium.  Firewalls, unless they include
   sufficient lead or other dense material, can not filter the signals.

   Media companies are particularly excited about the development of
   media formats that can only be read via spiraling into a black hole.
   These have a natural "play-once" property.

   One technical challenge to address is encoding a potentially infinite
   TTL in a finite length IP packet.

   There is some discussion in yet another MPLS subworking group about
   tunneling through the black holes.  VC firms, even in 2000, were
   suprisingly cautious about funding startups in this area.  The last
   known exploration of this space was a Disney funded VC in 1979.

   There is a endian-like issue to consider.  An often repeated fallacy,
   which we will assume to be true for getting this thesis done, is that
   funnel spirals go in different directions (clockwise versus counter-
   clockwise) in the northern versus southern hemispheres.  The
   direction of the spirals can affect the phase of the bursts.
   Therefore, this memo mandates that the southern hemisphere of a black
   hole only be used.



Waitzman                                                       [Page 4]

Not an RFC                    Ubiquitous IP                 1 April 2002


References

   Waitzman, D., "A Standard for the Transmission of IP Datagrams on
   Avian Carriers", RFC 1149, 1 April 1990.

   Waitzman, D., "IP over Avian Carriers with Quality of Service", RFC
   2549, 1 April 1999.

Acknowledgments

   Bergen Linux Users Group (http://www.blug.linux.no/rfc1149/) for
   showing me that even the craziest ideas are implementable by the open
   source community.

   BBN Department 7B for letting me practice my humor.

IANA Considerations

   It is unlikely that the IANA will be asked to assign any numbers for
   these protocols.  If IANA is asked, we are sure that the laughter
   will make it worth the trouble.

Security Considerations

   Many of the encapsulations mentioned in this memo are completely
   insecure.  Experience has shown that this doesn't bother most
   Internet users.  Therefore, security would be desirable but it is
   hard so let's avoid it.

Author's Address

   David Waitzman
   BBN Technologies
   10 Moulton Street
   Cambridge, MA 02138

   Phone: (617) 873-1656
   EMail: djw em bbn.com












Waitzman                                                       [Page 5]





More information about the gter mailing list