TCP/IP Over HTTP
Nick Towers sends news of a nifty new RFC that has just come out - RFC 3093, the Firewall Enhancement Protocol, promises to reduce the hassle of setting up a firewall by tunneling any TCP/IP application over HTTP.
← Back to Stories (view on slashdot.org)
Because TCP/IP over HTTP was so fucking subtle I could have beat you over the head with it.
In fact, theres still time. Open the door when I knock, theres a good chap.
Floppy disks!
:-)
:-)
I bet it could be done with a module to the Linux kernel.
Seriously. You have a box with no network card or other connectivity except a floppy drive. You fire up Netscape and try to access Slashdot.org.
It writes the TCP syn packet to the floppy and beeps. You take the disk and put it into a box with real connectivity. It then reads the packet off the disk and sends the request. Slashdot responds and you have a TCP connection. It writes the confirmation to the disk and you take it back to the other box.
The unconnected box sees there's a connection and writes a packet containing the HTTP request. Then you take the disk over to the other box and it sends it and gets the responce. Probably the whole page would come without any further disk swaps, except the images.
So you take the disk, which now has the Slashdot home page, to the unconnected box and it gets read in via the TCP floppy stack. Netscape then requests the immages, so the Syn packets for those TCP connections all get written to the disk.
Repeat the previous couple steps for all the images. Repeat the whole process every time you access a story or other doc!
Heck, you could even do telnet connections that way, if you run the disk back and forth between every few words you type. And you wouldn't see what you type until you bring the disk back with the responce.
Question to kernel gurus: Am I correct in assuming that that would not be terribly difficult to implement? If I didn't have more important things to do, I'd almost be motivated to try it.
I havn't tunneled full tcp/ip, but I often set up services on http/https ports to get past a certain over-restrictive firewall. Gotta wonder what the people at the network center are thinking when they see an ssl connection open for 4 hours.
If you look at the IPP (Internet Printing Protocol, RFC 2567), you'll notice that it's a protocol designed to encapsulate printing in HTTP POST operations. The motivation for this? Ease of administration, since so many firewalls out there already allow HTTP out, it makes remote printing much easier for end users. Of course, the fact that HTTP is basically a client-driven, instantaneous response protocol totally inappropriate to things like delayed spooled printing and reporting of asynchronous printer error conditions hasn't ever stopped the IETF from forging ahead with this.
All hail the Printer Working Group!
Now, *that* was *really* boring...
t_t_b
--
I think not; therefore I ain't®
I'm on PJ's "enemies" list! Are you?
Me thinks you're completely right.
jesus christ, enough man
Well, ok, the particular protocol is. But the reality is there are a staggering number of (slightly) more specialized protocols designed to do exactly this.
Very interesting how "well used/abused" (depending on your perspective) HTTP is, and how stupid many firewalling policies are.
I think this RFC is actually a parody of SOAP, as chronicaled in Bruce Schneier's June 2000 Crypto-Gram.
-"Zow"
Hmm.. Seems I forgot
RFC748 - Telnet randomly-lose option.
*sigh*
---
- RFC3093 - Firewall Enhancement Protocol (FEP).
- RFC3092 - Etymology of "Foo".
- RFC3091 - Pi Digit Generation Protocol.
- RFC2795 - The Infinite Monkey Protocol Suite (IMPS).
- RFC2551 - The Roman Standards Process -- Revision III.
- RFC2550 - Y10K and Beyond.
- RFC2549 - IP over Avian Carriers with Quality of Service.
- RFC2325 - Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2
- RFC2324 - Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0).
- RFC2323 - IETF Identification and Security Guidelines.
- RFC2322 - Management of IP numbers by peg-dhcp.
- RFC2321 - RITA -- The Reliable Internetwork Troubleshooting Agent.
- RFC2100 - The Naming of Hosts.
- RFC1927 - Suggested Additional MIME Types for Associating Documents.
- RFC1926 - An Experimental Encapsulation of IP Datagrams on Top of ATM.
- RFC1925 - The Twelve Networking Truths.
- RFC1924 - A Compact Representation of IPv6 Addresses.
- RFC1776 - The Address is the Message. S. Crocker.
- RFC1607 - A VIEW FROM THE 21ST CENTURY. V. Cerf.
- RFC1606 - A Historical Perspective On The Usage Of IP Version 9.
- RFC1605 - SONET to Sonnet Translation.
- RFC1438 - Internet Engineering Task Force Statements Of Boredom (SOBs).
- RFC1437 - The Extension of MIME Content-Types to a New Medium.
- RFC1313 - Today's Programming for KRFC AM 1313 Internet Talk Radio.
- RFC1217 - Memo from the Consortium for Slow Commotion Research (CSCR).
- RFC1216 - Gigabit network economics and paradigm shifts.
- RFC1149 - Standard for the transmission of IP datagrams on avian carriers.
- RFC1097 - Telnet subliminal-message option.
Did I miss any?---
What about httptunnel?
-rozzin.
Great idea guys, right along the spirit of WebDAV. The unfortunate part is, that you efforts will be defeated with a software upgrade for firewalls from vendors. ...... inconvenienced). Firewalls work, and have a place in the Internet. However, Firewalls are built to protect from external threats, not internal ones. Our proposed protocol does not break the security model of the Firewall; it still protects against all external risks that a particular Firewall can protect against. For our protocol to.....
I find this statement most troubling. A firewall protects the outside, and the inside. The firewall protects the outside by preventing external intruders from gaining unauthorized access to the internal network. The firewall also protects employees from themselves in many cases by keeping them from using unauthorized services that may 1, bring the network to its knees by crunching the bandwidth available. Or 2, By stopping a sabetour/employee from committing industrial espionage.
If you firewall traversal protocol went through. It wouldn't allow more invoations. It would just cause firewall companies to upgrade their software to screen the packets on port 80 for only true web traffic. That is all.
Firewall vendors support you because, you will force companies to pay for costly major upgrades to their firewall.
Cheers,
Tomas
===========
CmdrTaco et al can take pride in the fact that everything2 was cited as a reference in RFC3092 for its entry on "Prince Foo". I had my personal 15 minutes of fame last year with RFC2795 (reference number one, no less).
proof, n. A demonstration that a conclusion is implied by certain premises and axioms.
TCP via HTTP? Hah... see RFC 1149, "Standard for the transmission of IP datagrams on avian carriers", i.e. IP over carrier pidgeons. That one came out 4/1/1990. I also vaguely remember seeing something about TCP via UUCP on around this time of year in the mid-90s... TCP via UUCP would presumably have lower latency than RFC 1149, but still be a bit of a pain for interactive use.
Guess what the "Daylight" means?
(actually, you could choose a lot more than those, but I don kno whi yod wa-whallaballa bing bang shleebin gurkin flam, flam, flam, flam,
gooooooooooooooooone...
--
Vidi, Vici, Veni
I'm laughing.... are you a troll?
The AF on avian carriers beats this hands down.
Not to mention the follow-up RFC update with QoS
"JSockets® is a general purpose 'firewall tunneling' product used to deliver Java applets and business objects from the application server to the general Internet. It provides full-duplex communication support and allows a client to listen for connections from other JSockets clients. Essentially, we have rewritten TCP/IP to run over HTTP."
I didn't read the article, but I'm guessing (based on the rest of the comments here) that this is an April fools' joke. Regardless, this isn't all that interesting - HTTP proxies can already proxy random TCP connections. I don't remember the exact protocol, but you connect to the proxy and send something like this:
... and then anything you send through that connection to the proxy will be sent to the other machine, and vice versa. It's kinda neat. I don't know if this is a standard thing, but at least Junkbuster and Squid support it. Helped me out a bit before I had set up NAT and only had one box connected to the internet on my local network - I hacked up BeAIM to go through junkbuster :) Worked great. On a related note, this is why open source software is good. Otherwise I wouldn't have been able to use an AIM client (some might argue that this is a good thing though...)
CONNECT some.other.server:theport
Anyway, I don't think it would take a lot of voodoo to get the kernel to handle this transparently.
--
Great! Now I can tunnel into Internet Explorer!
Oh wait, that wasn't funny.
I guess they don't realize that some people actually do this? VTCP/Secure from Infoexpress does in fact have a mode that tunnels over HTTP.
I do believe I have been inspired... I am going to begin coding immediately and the entire implementation shall be written in.... ash!
Parrot is obviously the language this should be implemented in!
It's only software!
RFCs 3091 (Pi Digit Generation Protocol) and 3092 (Etymology of "Foo") are also available. Looking over the comments here, they're probably funnier, too.
It's a bug in Microsoft's development libraries. There was a discussion about it on Bugtraq, with a link to a FAQ . It's not a Y2K bug, so no one will bother tracking the productivity lost as a result, which is too bad, because it could be really big. And yes, changing the clock on your computer at work does count as lost productivity.
Boss of nothin. Big deal.
Son, go get daddy's hard plastic eyes.
Expanding a vast wasteland since 1996.
So I can run Java VM on NT on Solaris on Linux on NT on Solaris. Then I symlink /dev/random to a cron script that submits stories to /.
"Everything is adjustable, provided you have the right tools"
of course you realize that, at this point, depending what media you're transmiting this over, you can't fit anything more than headers into a packet. and maybe not even that.
sean
RFC 2795 (Infinite Monkey Control Protocol) is by far the best RFC I've ever read.
You are so wrong. HTTP uses TCP. Therefore, TCP over HTTP would be fine, technically (if senseless)
As for your assertion that TCP could not be implemented on top of UDP anyway, think about this --- TCP is implemented on top of IP. IP is an _unreliable_ protocol as well. It's perfectly possible to implement a reliabl protocol on top of UDP or any other unrealiable protocol using the types of mechanisms TCP does.
(Although I was hoping for a goatse.cx story....)
----
"Here to discuss how the AOL merger will affect consumers is the CEO of AOL."
grep -ri 'should work'
You mean the 31 Sunday in March? I had that problem today on one of my Windows 98 SE boxes, but this is the first time it has happened on here. Really strange.... Any ideas?
Man is born free; and everywhere he is in chains.
Has anyone else noticed that /. has not changed their time in accordance with daylight savings?
Man is born free; and everywhere he is in chains.
Wait a minute...let's look at those odds again:
1 out of 100 tests is inaccurate. No tests give a false negative. That means that, out of every 100 tests, 1 is a false positive.
Out of every 100,000 tests is a true positive.
By a, 1,000 out of every 100,000 tests will be a false positive.
Therefore only 1 out of every 1,000 people who test positive will have the disease.
So, in other words, I'm going to get the same number of projects done as I was before--none of 'em!
Wanna see my resume? I'm looking for a summer job.
Grrr....remind me to apply a cluestick to FrontPage at the earliest convenience. The problem, quite simply, is that our "wonderful" personalweb server is no longer accessible to post via any method other than FrontPage (so far as I can determine...it certainly isn't SMB-accessible anymore). So I'm limited to posting with FrontPage, which leaves me somewhat at its mercy for links...grrr....this is why I like Emacs much, much better for HTML tasks.
granted, I am a blooming idiot for not checking that first, but I threw the page up in .5 seconds while I was in a lab (no FP on my personal PC, thank God) and forgot that FrontPage likes to do things like that.
Why no HTML? It's not a layout language, and all the people I've talked to have preferred either Word or PDF format.
Okay, I now have my resume up on my box, rather than the local "personal page" server. That should work (no FrontPage involved this time).
I would hope most companies have a program runnign to sync the time with a master server.
My brain is dribbling out of my ears ...
Thankfully, desktop supercomputers like the one mentioned here exist to carry us into the brave new world of security by massively recursive recursion. :)
Get off my virtual lawn, you damned virtual kids!
I have seen firewalls that are overly strict, but they allow HTTP or HTTPS through them. If you have a host on the outside and a client on the inside, you can setup a PPP connection using stunnel between the two machines. Then you can do anything you like (including display a browser from the outside host back, run icq, etc. The cool thing is, if you use stunnel you can encapsulate it over https. This gives you the ability to have a secure, non-monitored, encryted connection to the outside host.
Goto www.stunnel.org and you'll actually find examples of tunneling ppp (and thus tcp/ip) over HTTPS.
--
Twivel
No, with TCP there doesn't have to be a one to one relation between packets. Actually, with TCP you don't even have much control about wich data will be put in which packet, since the TCP/IP stack will take care of this and splits the stream into packets.
Oh, and BTW:
IP has the function to fragment large packets.
Hey, I just found a way to tunnel HTTP over TCP! Oh, wait. Never mind.
Compaq Australia had a good one last year too. They took out a big full colour advertisement in the Sydney Morning Herald (one of the more respectable newspapers in Sydney) advertising a new technology for their laptop computers, to charge themselves by dialling up to the internet and using the power from the phone line to charge their batteries. It was really quite clever and had me going for a while. It's great to see that they had the balls to do it on such a grand scale too.
I'd go for a one-week orgy if there were no false positives. Given the circumstances, though, I'd probably just settle for two days worth.
43rd Law of Computing: Anything that can go wr
Just remember, in order to truly understand recursion, we must first understand recursion.
-
They originally called them Standard Time and Savings Time, but the abbreviations were too confusing.
--
Free Software: Like love, it grows best when given away.
Actually I believe this would be possible, but totally useless. You could possibly develop some sort of queuing system that be able to "qeue" incomming / out going packets. then make it alternate with PUT/GET requests. Again this would serve no real purpose. Anyone else? could this be possible or am I too stoned to relize that it isn't?
I think we've read enough bull for one April Fools. Isn't there any REAL news that's actually true?
"If anyone needs me, I'm in the angry dome."
I know almost nobody will read this, but don't miss the other RFCs released on April 1st, 2001. True gems like the Pi Digit Generation protocol, that states "One REQUIRED PIgen service is defined as a stateless TCP service. A server listens on TCP port 314159.".
:-)
And also, don't miss this very interesting RFC called the Etimology of foo, with more than useful information about the foobar!
At least, these are _technical_ April Fools jokes
You're tired of Slashdot ads? Get junkbuster now!
Um, your resume is on your j: drive. This is obviously not internet accessible. Also, why not provide a version in HTML or PS? Word is a nasty proprietary format.
I'd like you to show the audience exactly what TCPv4 is. My bet is you'd find it a bit of a struggle. IPv4 yes, but TCP, probably not.
you dumbass those links just point to a drive letter. I'm sure as hell not hiring you.
Only the State obtains its revenue by coercion. - Murray Rothbard
generally speaking... wouldn't you send your http information over tcp/ip... soooo... why would you go through all the trouble of trying to get you tcp/ip data into an http data which is going over tcp/ip... to me, this just sounds like a complicated solution to a simple problem. It's probably going to cause more problems in the process as well. And man... how big is the stack going to be when everything is done too?
OK, now I realize, it was suppose to be funny. Gee, when did I lose my sense of humor?
i dont know enough about either tcp or http, so i have to ask, could you even encapsulate tcp in http when http is stateless?
slashdot: where everyone yells sarcastic metaphors to themselves to understand the issue
You can run PPP over GNU httptunnel. The same thing, really, but no joke.
You are so wrong. HTTP uses TCP. Therefore, TCP over HTTP would be fine, technically (if
He's wrong, but, so are you (although in a much more subtle manner). HTTP is supposed to be transport independent. You could do it over a raw teletype if you wanted to. But when you use HTTP on the web, you are making TCP connections
Rate me on Picture-rate.com
"and dear god does this website suck now." -- CmdrTaco
Many wireless devices don't have TCP/IP, since it's not worth implementing it-- they're just there for HTTP, so they use an easier transfer protocol more suitable to wireless. That means, though, that on a lot of those clients you don't have TCP/IP, which certainly cuts down on hackability. This might be an easy way to implement TCP/IP, without having to hack their proprietary protocol. Yeah, it'd probably be slow as hell on a wireless e-mail client, but....
I like that the email address was sob@harvard.edu
hehe I had to laugh when I read this:
;)
TCP_UP - The 16-bit TCP Urgent Pointer, encoded as the hex representation of the value of the field. The hex string MUST be capitalized since it is urgent.
Heeehehehe... I can just imagine someone actually reading this and trying to immpl. it hehe.. oh the horror.
Chris
-- Humans, because the hardware IS the software.
Maybe we should mod up troll posts to +5, haha, that'd be a funny April Fools! Well, at least funny when compared to the Slashdot postings. :)
Still, it would certainly be possible to tunnel TCP over UDP just as it is possible to use IP as the transport for TCP.
Someone of the German computer magazine c't even experimented with TCP-over-DNS. (The background is that a company provided a toll-free 0800 number for IP access but with firewalls so that you could only access support web servers ... and resolve arbitrary domain names. No, it wasn't an April issue.)
Claus
You can already do this with SECSH and PPP.
Claus
QUiCK, STOP P0STING!!!
It's an April Fools Joke. The RFC was written 1, APRIL 2001. It is not written well, and it was obviously done in a hurry.
It mentions many times over that "we respect the right of people to use a firewall"; yet the RFC proposes circumventing a firewall completely at every level. It is a JOKE.
What's more is, and I'm sure somebody could argue this; but HTTP uses UDP connections. The entire TCP/IP Protocol suite requires TCP connections which are more complicated than simple UDP - using HTTP a true TCP connection is impossible.
The pranksters are probably network admins themselves, and thought it would be funny to write an RFC that claims employees on an internal network are actually smart enough to decide which of their programs are good - which is why the mention, "Best of all, no need to bother a network admin".
Just thought I'd mention it so I can start hating every idiot who posts on this one.
Ace
"Wanna see my resume? I'm looking for a summer job."
Hope you're not looking for a job in computers, but I wouldn't know because the link to your resume points to a file on your hard drive; probably behind an un-firewall enhanced firewalled system.
Or it could just be you don't have a webserver running on J:\.
Ace
Listen up people this is the next big thing! Although it's still in draft the idea is to print packets on A4 papers and mail them to destination, reassembe and scan... the best thing is that it can switch to a special mode to send emails! I think I should patent it... Edo
Mi domando chi à il mandante di tutte le cazzate che faccio - Altan
Wait ... Spam does that now with the ask off questions.
we are doomed
Check out the Vinny the Vampire comic strip
"It is a greater offense to steal men's labor, than their clothes"
It would be a huge security problem to say the least. Virtually uncontrolled outbound traffic.
IP over HTTP implementation:
http://www.nocrew.org/software/httptunnel.html
Sparks:Gadget:Beer Maker
With the Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)
Unfortunatly the way we're going now the protocol may actualy become useful one day....
Imagine, BeCoffee, All your coffee needs catered for using fully RFC compliant software, order your coffee anytime any where from over the internet. Never have to wait for instant coffee again !
-- Conexant/Rockwell Modem HOWTO http://linuxdoc.org/HOWTO/Conexant+Rockwell-modem
Errr.. What? There ís no connection between xml and http (excluding SOAP), you could as well send any arbitrary ascii-based format.
Save your wrists today - switch to Dvorak
You really have no grasp on basic mathematics do you?
Stop contaminating the gene pool.
You go to the doctor for a test to see whether you have a certain very deadly disease. One in a hundred thousand people have this disease. This test is 99% accurate and NEVER gives a false negative.
I know I'd spend my time figuring out how a test can be 99% accurate and NEVER give a false negative.
So with all of the RFC's you could transmit TCP/IP over HTTP which is over TCP which is over IP which is being transmitted by avian carriers!
Hello!
:-)
I would like to comment on this subject.
Now I have read the RFC and all the posts here and I am beginning to suspect that it is a April fools joke.
Yours truly,
Homer Simpson
--------
Heh, I just wanted to be another one who made the "discovery", and needed to show everyone that I am clever.
--------
And to think, only 50 years ago, the same type of people were evading a stone wall by tunneling an escape path under the penitentiary.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
XML is a much better place to start because it already tunnels through HTTP (port 80). All that remains to do is establish a parser on the server side and a parser on the client side to convert the traffic back into TCP/IP.
But no matter what the approach, the overhead would mean this is only useful when all options have been exhausted. (e.g., You have an application that goes straight TCP/IP and cant be changed AND the firewall administrator will not open another port for you.)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~ the real world is much simpler ~~
--- -- - -
Give me LIBERTY, or give me a check.
The one funny thing to come out of all these april fools posts is the amount of people who think theyre smart by discovering that the posts are indeed april fools jokes and must share their discovery with the rest of slashdot
Ok, let me get this straight: You start with IPv4, run TCPv4 over that, make a standard HTTP connection, and tunnel TCPv4 through that. Why stop there? Why not tunnel IPv6 over the tunnelled TCP connection? Then you can run TCPv6 over the IPv6 connection, and make a HTTP connection through it all!
it could give a false positive every now and again.
or something, just ignore me.. i'm going to go stare at a shiny object now.
end communication
It's daylight saving...no "s".
Er... Well, y'know. You can't make an omelette without um... destroying a forest. Or something.
My only political goal is to see to it that no political party achieves its goals.
Trolls throughout history:
Trolls throughout history:
Jonathan Swift
Duh! Again, I go away on a honeymoon, and I instantly forget what day it is... Jeez... TCP/IP over HTTP...
I do believe I have been inspired... I am going to begin coding immediately and the entire implementation shall be written in.... ash!
*Chuckles to Doggy_Door_Man*
I'm done with sigs. Sigs are lame.
If Rob Malda owned Google, would Google mess with the search results to make life worse? I read slashdot to get news. Not to be entertained by an obviously bored CmdrTaco.
samrolken
How would UDP over HTTP work?, how the heck can you have an unreliable protocol over HTTP? As soon as you try to drop one damn UDP packet, you'd get a 'network unreachable.' Or would it be a 404, page not found? Damn I miss DECNET. (On the plus side, you could have traceroute implemented by hyperlinks.)
When EVERY STORY is an April Fools day joke, it just gets really fucking boring and after the first 'joke' people begin to suspiciously eye all other content assuming its a joke by default. Thus any humor those other jokes may have had is pretty much lost.
Next year you might want to try having ONE April Fools Day joke that is Slashdot specific and then linking all the other cool jokes people submit from other sites as one big quickie post.
There are quite a few commercial products that use this trick.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
RFC 31337 you better recognize
360 degrees of Karma
That's The April Fools Limitation Protocol. It can be very handy when implemented around this time of year.
Ok, ok. Don't get all worked up about it - it's obviously a joke. Here's what I found near the bottom:
3.4 TCP Header Compression
Compressing TCP headers in the face of a protocol such as this one
that explodes the size of packets is silly, so we ignore it.
4.0 Security Considerations
Since this protocol deals with Firewalls there are no real security
considerations.
5.0 Acknowledgements
We wish to thank the many Firewall vendors who have supported our
work to re-enable the innovation that made the Internet great,
without giving up the cellophane fig leaf of security that a Firewall
provides.
You can accomplish anything you set your mind to. The impossible just takes a little longer.
On both counts (HTTP runs on TCP/IP and this is a joke) however he is correct that there are solutions to tunnel TCP/IP through HTTP and through other things. I know it sounds silly at first but there are many uses. I'll point out one of the more common ones, L2TP. Suppose I work at a major instutition and want access to their network from home. Well as it happens both they and I have phatty internet conenctions. Great, I can use those right? Errr, well except that is a security risk, since our data is sensitive. So, what do we do? Setup a virtual private network (using L2TP). Basically, I connect to a server at work using TCP/IP, then I and it establish a L2TP connection. Encapsulated in that encrypted L2TP connection is TCP/IP packets, that it then decrypts and routes tot eh corperate network. The point of the excersie is, of course, that I can use an encrypted stream to access the resources. The point of the encapsulation is that then EVERYTHING I do is encrypted, wether the application supports encryption or not. As far as all my apps know, they are communication via TCP/IP. However those TCP/IP packets are taken, encrypter, encaplulated in other TCP/IP packets, then sent out to the destination where they are reformed. As such I have created a network that is secure and acts like a private point-to-point link, but done it using the public internet and encryption.
You go to the doctor for a test to see whether you have a certain very deadly disease. One in a hundred thousand people have this disease. This test is 99% accurate and NEVER gives a false negative.
Unfortunately (horrors) you test positive.
Given these dismal odds, how will you spend your last days on Earth? Put another way, which of your coding projects will you scramble to finish?
--
"May the forces of evil become confused on the way to your house"
--
"May the forces of evil become confused on the way to your house"
-George Carlin
Actually it works pretty good. I mean you jump in the tunnel of HTTP and down you go. And you get switched by ftp to the atm to the rfc to the isd to the isp to the ipx to the spx to the oh my I've gone cross-eyed again.
Look at the date on the RFC (Request for Comments) itself. It's April 1. April Fools Day. I have a sneaking suspicion that someone is trying to put one over on us.
Give us goatsex instead.
I submitted this but /. wouldn't publish. Try this - only for the lonely...
The Compaq Personal Gene Analyser"