Slashdot Mirror

For those who don't know what you're referring to, like the AC who commented: search in this for "evil bit".

It's IP over Avian Carrier, you insensitive clod! http://www.faqs.org/rfcs/rfc1149.html

Then we have to become pidgeon fanciers then and follow RFC 1149.

Fortunately Godzillagrams (sense 1) haven't been supported by IPv4 for a very long time.

Try reading the The Godwins Law FAQ

The point of Godwins Law is that once a thread degenerates into comparisons with Hitler that thread is effectively over, and can be killfiled by the participants without risk of losing any useful information.

This leads to the tradition that mention of Nazis in a thread by a participant automatically makes them lose the argument (http://www.jargon.net/jargonfile/g/GodwinsLaw.html)

What if the whole point of the article is about real world Nazis? Is there no point in reading it?

Try reading the The Godwins Law FAQ

The point of Godwins Law is that once a thread degenerates into comparisons with Hitler that thread is effectively over, and can be killfiled by the participants without risk of losing any useful information.

This leads to the tradition that mention of Nazis in a thread by a participant automatically makes them lose the argument (http://www.jargon.net/jargonfile/g/GodwinsLaw.html)

Maybe he is using Avian Carriers?

I heard that this "security fix" is the addition of support for the Evil Bit.

There's a whole RFC on this:
http://www.faqs.org/rfcs/rfc1178.html

Interesting read...it specifically says:
'Don't choose a name after a project unique to that machine.'

I agree with the reasoning, but on large scale DNS deployments, I can also see this being a nightmare... I just use arbitrary names, nothing too hard to spell.

How can you tell if someone is using a secure SSL connection for work related purposes (Email, large file transfers, terminal services) and someone that is using SSL for bit torrent?

You can hazard a guess using traffic analysis. Bit torrent (and other P2P apps) use a different pattern of connections to normal browsing because the torrent clients also act as servers for many simultaneous external clients, and it's very difficult to conceal that, even if the content of the connections is hidden by encryption. (Of course, such analysis cannot detect the legal status of the data being transferred. Not unless the EVIL bit is set in the packet headers...)

This seems to me to be in the spirit of RFC 2549, "IP over Avian Carriers with Quality of Service". I should suggest this as an idea for the AF09 RFC.

I wonder how the speed compares to 2549-compliant methods of delivery?

Snails should be just another layer of slowness for
http://www.faqs.org/rfcs/rfc1217.html system!

Yep, this is exactly the sort of situation that IP Multicast was created for. It has been part of the IP RFCs since forever. Maybe more incidents like this will convince more ISPs to configure their routers to support it, so we could start using it.

I wrote an email parser about five years ago, and I can tell you that there is a good compromise to the problem you describe in the email standards implemented by virtually all mail clients (MUAs).

The header "format=flowed" lets you send text/plain messages that look great whether you are reading it with telnet or pine or with Thunderbird or any other modern MUA. The main rfc for email, RFC 2822, explains that the sending MUA should, but is not required to, break up paragraphs into lines of less than 78 characters terminated by a carriage return/line feed. If you specify the "format=flowed" header described in RFC 2646, you allow the receiving client to rewrap the email according to the receiving user's preference. Typically modern MUAs will rewrap format-flowed plaintext email to the window size.

The specification states that lines ending with a space and then a CLRF are to be treated as part of a single paragraph that can be rewrapped. Hard breaks are then done by terminating the line with a simple CLRF with no preceding space.

Most modern MUAs that I have dealt with can (and typically by default) send format-flowed email that has the standard line breaks every 78 characters for the benefit of clients that cannot rewrap, and contain contextual clues for newer mail clients to seamlessly reformat the message body. For example, Apple's Mail.app by default sends multi-part MIME messages, one part containing the rich text email and the other part containing format=flowed text/plain. No matter what email client the recipient is using, at least one of those options will look acceptable.

You can find a pretty good write-up of this at Dan's Mail Format Site.

I wrote an email parser about five years ago, and I can tell you that there is a good compromise to the problem you describe in the email standards implemented by virtually all mail clients (MUAs).

The header "format=flowed" lets you send text/plain messages that look great whether you are reading it with telnet or pine or with Thunderbird or any other modern MUA. The main rfc for email, RFC 2822, explains that the sending MUA should, but is not required to, break up paragraphs into lines of less than 78 characters terminated by a carriage return/line feed. If you specify the "format=flowed" header described in RFC 2646, you allow the receiving client to rewrap the email according to the receiving user's preference. Typically modern MUAs will rewrap format-flowed plaintext email to the window size.

The specification states that lines ending with a space and then a CLRF are to be treated as part of a single paragraph that can be rewrapped. Hard breaks are then done by terminating the line with a simple CLRF with no preceding space.

Most modern MUAs that I have dealt with can (and typically by default) send format-flowed email that has the standard line breaks every 78 characters for the benefit of clients that cannot rewrap, and contain contextual clues for newer mail clients to seamlessly reformat the message body. For example, Apple's Mail.app by default sends multi-part MIME messages, one part containing the rich text email and the other part containing format=flowed text/plain. No matter what email client the recipient is using, at least one of those options will look acceptable.

You can find a pretty good write-up of this at Dan's Mail Format Site.

XP SP3 sends out DHCP packets with Option 43 data (including Microsoft's "Vendor Specific Information"), which Service Pack 2 (SP2) did not. However, Option 43 data is not compatible with 5200 series router's original definition, which causes the problem (as reported from a notice from Billion)

RFC2132 says: "Servers not equipped to interpret the vendor-specific information sent by a client MUST ignore it (although it may be reported)."

It seems to be a Billion's fault...not Microsoft's

You have to wait till the pills-over-IP protocol RFC is published and implemented...

Or you could just use RFC 1149 and send them as an attachment.

p.s. To mods: who the heck modded parent flamebait. You need to get a new sense of humour.

The problem is that a lot of people have grown up with the "throw more hardware at it to make it run faster" mentality since all they know is Microsoft products.

Whats significant about 3142?

I found this LAPA flight and this on IPv6-to-IPv4

Someone has to counteract the nonsense and lies and the descriptions of Linux that are 10 years out of date.

Before the world wide web, when the internet was mainly news groups, uucp and email (with pling addresses, because there was no dns for routing.

According to RFC 921, the host table was to be decommissioned in September 1984, although it notes that hadn't been done yet. I don't think they were off by much, however, so that was a long time before the WWW.

Or perhaps by "the internet" you meant the Matrix (Quarterman coined the term long before the movie...)? At that point, the ARPANET and Internet were mainly for academic institutions and large technology companies; most other organizations and individuals had UUCP connections for e-mail and netnews. In the late 1980's Internet connections started being offered to a wider set of users, but I think there was still a period between that point and the point at which consumer ISPs started appearing.

This is where internet2 is currently. It doesn't mean it will be in a couple of decades.

Or perhaps not, if, instead, Internet2 remains as a dedicated network and the technologies developed for it filter down to the mainstream Internet.

Yes we are. Have you been living under a rock or did you communicate using RFC1149 exclusively? :P

I use threads a fair amount, because they are there. But I kinda wish path expressions would catch on. Let the compiler sort out the scheduling given the constraints - that's the kind of scut work computers are good for anyway.

That's probably true, but I've run into situations where partitioning needs have changed and I have needed to grow/shrink file systems accordingly. I suppose that's fairly rare, and that many home users would use ext4 or something instead. Although the EVMS docs (http://www.faqs.org/docs/evms/whyexpandshrink.html) say that "Expanding and shrinking volumes are common volume operations on most systems." Its table of legal operations is out of date though, as I know that ext2/3 can be expanded online...

(Talk about self-image in this case! growl)

Another issue: Even if they're transmitting, how hard are they doing it, and how hard are we listening?

I mean, if you look at thei figures for the SETI project and how far away they'd be able to detect another planet with identical transmission patterns to the earth(well, in the past a number of years equal to their distance).

It's well under a hundred ly. Heck, 'I love lucy' doesn't make it past Pluto in recognizable strength! source.

Oh yeah, you can get 720 light years of range - while transmitting at .1 HZ and 22 Terrawatts of EIRP! That, at least to me, indicates a rather extraordinary amount of effort. For a spherical transmission you're talking about 22k nuclear plants. Heck, even with a very directional transmitter, effectively aiming it at us, you're still looking at putting at least one huge power plant behind it.

Even for smaller efforts, you're talking a LOT of power.

I'm a bit surprised that I haven't seen the old equation(I'm paraphrasing it)

X1 chance of a solar system having planets
X2 chance that a solar system with planets, having planets in the zone suitable for life
X3 chance that the planet in the zone has the right composition to support life
X4 chance that life developes
X5 chance that, life having developed, that intelligent life develops
X6 chance that, intelligent life developing, that they become a technological civilization capable of using radio, and either transmitting to be found or listening hard enough to hear us.

Put all that together with stuff we're finding out about how relatively rare a solar system like ours is and even the vast amount of stars tends to make the odds of one being in our detection zone very, very small.

Far enough out, as a matter of fact, that I figure that if lightspeed is indeed a hard limit, if we don't find a method to accellerate like in most SciFi, that 10% of LS for a ship is being optimistic.

In such a scenario I figure that by the time a civilization is good enough to travel between stars to colonize other systems it's beyond the need or want for planets.

That's per weight. I said size--this means volume. That also makes it far more difficult to dissipate the heat generated, as you now have both increased the distance heat has to travel out of the coils, and decreased the thermal resistivity of the coils.

But it gets worse! Aluminum has serious longevity problems. From http://www.faqs.org/faqs/electrical-wiring/part2/section-16.html
"During the 1970's, aluminum (instead of copper) wiring became quite popular and was extensively used. Since that time, aluminum wiring has been implicated in a number of house fires, and most jurisdictions no longer permit it in new installations....The main problem with aluminum wiring is a phenomenon known as "cold creep". When aluminum wiring warms up, it expands. When it cools down, it contracts. Unlike copper, when aluminum goes through a number of warm/cool cycles it loses a bit of tightness each time. To make the problem worse, aluminum oxidises, or corrodes when in contact with certain types of metal, so the resistance of the connection goes up. Which causes it to heat up and corrode/oxidize still more."

While it may be the case that the internet would be a happier place if everyone agreed to avoid generating "backscatter," people seem to consistently ignore the fact that "backscatter" is not a misconfiguration but rather a strict adherence to the standard. RFC 3461 (which is responsible for outlining delivery status notification for SMTP) is pretty clear that any failure to deliver a message in which the sending MTA has not specifically set the NOTIFY parameter to not contain "FAILURE" must result in a bounce. (RFC3461 sec. 5.2.6) http://www.faqs.org/rfcs/rfc3461.html Can we really jump down google's throat for adhering to an accepted standard instead of a loosely defined "best practice" which exists in direct violation of standards?

These guys are morons and should go read up on multicasting.

It was designed for precisely this type of traffic. P2P would benefit enormously if it went across multicast channels instead. But that would assume the routers of the ISP supported multicasting, and most probably do not.

Yea, but is it RFC compliant?

1. There are often other ways to do it, e.g. multiple processes communicating over sockets, or multiple processes that share memory.
2. Threads are hard to get right. Really, really hard.

If these people take years to get it right, what makes you think *you* can get it right in a reasonable time?

The irony is that threads are only practical (from a correctness/debugging point of view) when there isn't much interaction between the threads.

By the way, I got that link from Drepper's excellent "What Every Programmer Should Know about Memory." It also talks about how threading can slow things down.

Hence, article summary: "let's make an evil bit."

http://www.faqs.org/rfcs/rfc3514.html

maybe you should read up on what MTBF actually means. this provides a nice simple explanation: http://www.faqs.org/faqs/arch-storage/part2/section-151.html

Things don't need to be heated in space, they need to be cooled. Radiation is generally not a very efficient way to get rid of waste heat, so it's usually quite warm in any enclosed space. So no, you can't really keep stuff cool without active refrigeration, which generates heat of its own that has to be radiated, so you don't want to do any more than necessary.

It was worth a good laugh at least ;)

I haven't paid much attention to this as I don't use BitTorrent that much to download to my house, where I have Comcast. I typically download to my colocated box with BitTorrent, and then download via FTP to home once it completes.

However, a thought occurred to me, as a work-around until this issue is "fixed." The problem, from what I've read, is that Comcast is sending spoofed TCP RST packets. I'm assuming this causes the peers to tear down, or at a minimum have to re-establish a TCP session.

How much overhead would it add to add TCP MD5 signatures? I know we use this with BGP so that no one can fake RSTs which would cause routing peers to drop and major routing flaps (RFC 2385).

Could TCP MD5 signatures just be added to RST packets? What method would be used to share the key (and how to prevent a man-in-the-middle attack?)? I just use BGP and TCP MD5 signatures already built into Cisco products, I didn't design any of it and don't have time to look into these details, however it seems to me that it would solve the problem.

I'm not sure if TCP MD5 signatures work with NAT, so that may be a problem if they do not. Perhaps MD5 is too old, and SHA or something else should be used instead - again, I don't know the technical details, but someone should use the same principle to solve this RST problem, especially if BT is ever going to be a major business software deployment model.

formalize a community sneakernet.

You're late. RFC 4838 does just that.

http://www.faqs.org/faqs/astronomy/faq/part4/section-15.html

Will answer your question much better than I could.

That's what I thought too, but from RFC 791, http://www.faqs.org/rfcs/rfc791.html

> The time is measured in
> units of seconds (i.e. the value 1 means one second). Thus, the
> maximum time to live is 255 seconds or 4.25 minutes. Since every
> module that processes a datagram must decrease the TTL by at least
> one even if it process the datagram in less than a second, the TTL
> must be thought of only as an upper bound on the time a datagram may
> exist.

This is a random-access device. The codebook encryption method is pretty much your only option unless you intend to re-crypt the entire downstream content because a one-byte write altered the chaining dependencies. In telecom apps, most of the data is streaming, and chaining cyphers are very appropriate. For static storage with an arbitrary data-order access opportunity, chaining cyphers would cause dramatic reductions in throughput, to the point of making the device unusable.

AES in ECB mode is less secure than (ECB + salt) or CBC mode. However CBC mode is inappropriate for this device. That doesn't make ECB suddenly "insecure."

Pirates would simply specify a bit in the IP header. Logically, it would be implemented like RFC 3514

Indeed, as another replier said, there is already an Internet2. However, even before that, "internets" was a valid term. See RFC 1918, titled "Address Allocation for Private Internets".

Dude, you need to upgrade your service to IP over carrier pidgeon with Quality of Service.

This reminds me of RFC 1149.

Well,

In a more primitive form, it's the Sun/IETF-driven XDR format http://www.faqs.org/rfcs/rfc4506.html. Many other binary protocol uses and respects parts of the XDR-format, even if not completely. XDR however is in no way general-purpose, as it does not include enough information about the implementing formats in order to make extensible simple formats based on them.

Then there's EBML - Extensible Binary Metadata. It's a bit underspecified, does leave room for extensible protocols, semantically resemble XML in many ways, very fast to implement, but do have some shortcomings in terms of flexibility, and neither does include sufficient metadata to do intelligent things by just watching a message/document. Also it can never implement some kind of generic editor.

Then there's my own little dormant project, runestone. http://runestone.sourceforge.net/ It kindof combines the greatest strengths of XML, with the strengths of binary languages, and then some. It implements extensibility on two levels, both on the same ad-hoc decentralized level as XML, but the format itself is from start designed to be modular and extensible (although in a more synchronized central-control fashion). It allows for features like semi-transparent encryption, compression, checksumming and cryptographic authentication. It's pretty much written with XMPP and SVG in mind, and features things like arrays of uniform data-types, (Excellent for a graphics-format like SVG) prefix-length encoding of all datatypes with variable length, allowing an XMPP-server to "fast-zap" over things in the communication it doesn't need to know. (Like the payload of messages). But it also would enhance protocols like HTML quite a bit by, I.E. faster parsing, embedded inline binaries (like images without an auxiliary http fetch), and options to authenticate parts of a transferred data-stream.

Most important of all, the Runestone format would allow for generic content editor, much like a text-editor is pretty generic for many formats today, but in a way that does not mix information with visual representation. (I.E. your editor not only could, but MUST choose indentation and other styling according to it's own or your preferences). The format simply won't contain them. I think this feature, above all, is critical for a general-purpose binary format.

Other than that, a general-purpose binary format could allow for some very neat indexing opportunities whereas indexers doesn't really need to understand the semantics of a specific document-type, but only the syntax which itself when using the index some of the semantic may be guessed from the syntax. I.E. looking for everything where "author=John Doe", indifferently of document type, based on any document that somewhere in it has an attribute with the value John Doe.

Also, things like version-control of more arbitrary data would be possible, through tree-deltas. Could improve things like ODF a little.

I'm not saying Runestone is the way to go. It's not even, contradictionary to it's name, a format set in stone yet anyways. But I DO think some of the possible characteristics of a binary generic language somewhere along that spirit could prove _very_ useful.