Slashdot Mirror

If you look at the top of RFC2616, you might notice that W3C is mentioned several times.

ocalhost (127.0.0.1) has a 32-bit subnet mask, so 127.0.0.1/32

It may be setup this way on your computer's network settings but the RFC says the whole /8 is valid is part of the loopback:
http://www.faqs.org/rfcs/rfc3330.html

Please, show me the gigantic bodies of evidence of one species evolving into another. The elusive transitional fossil.

*sigh* I'll give you the link, but I doubt you will really read it and accept it. See the fifth question.

and is communicating solely by carrier pigeon.

Well at least RFC1149 is safe then. At least he knows what the intarwebs is.
http://www.faqs.org/rfcs/rfc1149.html

http://www.faqs.org/faqs/scientology/spam-team-faq/

Don't forget what the Religion of New Age Peace did to USENET.

Ron Hubbard - the founder of Scientology - has been quoted as saying that if you want to get rich, you start a religion. ( http://www.faqs.org/faqs/scientology/skeptic/start-a-religion-faq/ ) Well, that's what he did. You have to pay just to learn about it and the deeper you go, the more you spend. It's designed to dupe people into giving the Church of Scientology gobs of money. I truly feel sorry for anyone that's been sucked in by it. It's like believing that Star Wars is real (the movie, not the missile defense system...).

The internet is way ahead of you, it already operates on carrier pidgeons:
http://www.faqs.org/rfcs/rfc1149.html

As an addition even if you code shines how does your process look, do you really know how your company uses or plans to use its data?

Senior programmers not only know their code they have the experience of applying that code in their field. They've certainly fried their share of monkeys and have learned from it, know how to avoid it, and if it happens again how to keep employed afterwards. They have learned communication skills and what makes a boss happy (maybe some nice commas in the thousand number results, or what to show and what not to.) They also have learned the system and like Chief Engineer Scott, can usually tell something is going wrong long before most notice.

Your logins screens may be the best user interface everyone has seen; but when the billing system is loosing money somewhere in the satellite stores coupon validation redemption routines it does not solve the real issues at hand.

Then you'll need to read up on RFC 2324.

Just remember to mount these drives noatime to avoid a write every time you read a file.

For that matter, noatime is a sensible default for any desktop OS. When was the last time you actually searched for files you hadn't accessed in six months?

Does your semaphore tower conform to RFC 4824? :-)

No, what I wrote was true.

http://www.faqs.org/faqs/astronomy/faq/part6/section-12.html
I haven't completely read what you linked yet, though I will at some point to give this a more proper reply. But was that article just drawing the bubble around the Earth in light years and commenting on the reach our radio signals? Or coming up with a cherry picked scenario to show how it could work? If you read what you quoted of me it says "typical radio transmissions virtually disappear well short of a single light year". And that is 100% accurate.

If you look at the bottom of the link I just posted you'll see that even using Arecibo AM signals vanish at less then 1 AU. FM at a few AU. To get into lightyears you're getting into much higher frequencies and the signals have a lot more power behind them. Which aren't "typical". "I love Lucy" isn't going to make it to our nearest stellar neighbors, nor is 100.9 KISS FM. Unless they have a dish the size of a small moon powered by a star.

So yes, what I wrote was true. The most logical frequencies for local communication do not lend themselves to be pick up from far away. Now, if our goal was to send signals far away, and someone at the other end knew it was coming and listened for it, yeah, we could send signals no problem. That's basically SETI on our end looking for it. But now you're into a needle in a haystack unless the other end is doing nothing but spamming the galaxy with high frequency "here we are" signals. Which we aren't doing, so I don't believe we should assume anyone else is either.

You may want to send a comment to RFC 1149 as the RFC doesn't take into account this form of packet loss.

You know, users could really help the *AA and government if they would simply set the evil bit on all internet traffic that potentially infringed on someone's copyright...

That would make content filtering a snap!

Well, you could read the section where the quote appears, and the previous section where some of the problems are laid out.

Well, you could read the section where the quote appears, and the previous section where some of the problems are laid out.

1- keepalive : IBM's SNA has an efficient keepalive mechanism. TCP has one but I never saw it working properly.

Uh, no? Please do correct me if I'm wrong, but keepalives are not at all part of the TCP/IP "church". In fact, keepalives are outside the TCP state machine, and I've seen some really interesting behaviors caused by poor implementations of this poor idea.

Poor idea? Well, yes: One of the points of TCP is to be able to survive temporary or intermittent "disappearance" of the underlying network. Keepalives expose these failures, breaking the TCP model.

For more on keepalive badness, please refer to section 4.2.3.6 of RFC 1122 (HTML); to RFC 2525 (HTML), which documents a number of known problems with the implementation of TCP keepalives; and to http://tcp-impl.grc.nasa.gov/tcp-impl/list/archive/0367.html for more on why TCP keepalives are a bad idea (and not even implemented the same way on all systems!).

Some of the bad behavior I've seen? This one is cool....

Server and client, both on HP-UX 6.5 (yeah, I know...). Both ends have sockets set to use keepalives (remember the old ISODE code? Used keepalives over TCP to mimic an X.25 analog that wasn't necessary in a TCP network! deep sigh). Every morning, recycle the server via cron. But server won't come back up, claims socket is in use.

Problem? Server shuts down, tells kernel to close socket. Kernel on server tells client that it is closing, both drop into wait state. Socket will close when client sends its close message. BUT! During the wait state, one end (doesn't matter which) sends the other an ACK. WTF? A keepalive.

Due to a bug in how the HP-UX 6.5 networking libraries handled the TCP state machine violation (an ACK at this point is illegal), the close sequence is forgotten, and the two machines exchange ACKs until one is rebooted. Servver's port is never released by kernel, therefore server cannot come back up. Until client machine or server machine (doesn't matter which) is rebooted.

Sigh. Two days with a network analyzer and a lot of WTF, this can't be moments. IIRC, they fixed this in 7.0, broke it briefly later, but fixed it for good in 8.0 and above.

And don't even get me started on the fact that TCP keepalives are still the default in OpenSSH, despite known security concerns with having a keepalive outside the security envelope, and therefore injectable by an attacker.

1- keepalive : IBM's SNA has an efficient keepalive mechanism. TCP has one but I never saw it working properly.

Uh, no? Please do correct me if I'm wrong, but keepalives are not at all part of the TCP/IP "church". In fact, keepalives are outside the TCP state machine, and I've seen some really interesting behaviors caused by poor implementations of this poor idea.

Poor idea? Well, yes: One of the points of TCP is to be able to survive temporary or intermittent "disappearance" of the underlying network. Keepalives expose these failures, breaking the TCP model.

For more on keepalive badness, please refer to section 4.2.3.6 of RFC 1122 (HTML); to RFC 2525 (HTML), which documents a number of known problems with the implementation of TCP keepalives; and to http://tcp-impl.grc.nasa.gov/tcp-impl/list/archive/0367.html for more on why TCP keepalives are a bad idea (and not even implemented the same way on all systems!).

Some of the bad behavior I've seen? This one is cool....

Server and client, both on HP-UX 6.5 (yeah, I know...). Both ends have sockets set to use keepalives (remember the old ISODE code? Used keepalives over TCP to mimic an X.25 analog that wasn't necessary in a TCP network! deep sigh). Every morning, recycle the server via cron. But server won't come back up, claims socket is in use.

Problem? Server shuts down, tells kernel to close socket. Kernel on server tells client that it is closing, both drop into wait state. Socket will close when client sends its close message. BUT! During the wait state, one end (doesn't matter which) sends the other an ACK. WTF? A keepalive.

Due to a bug in how the HP-UX 6.5 networking libraries handled the TCP state machine violation (an ACK at this point is illegal), the close sequence is forgotten, and the two machines exchange ACKs until one is rebooted. Servver's port is never released by kernel, therefore server cannot come back up. Until client machine or server machine (doesn't matter which) is rebooted.

Sigh. Two days with a network analyzer and a lot of WTF, this can't be moments. IIRC, they fixed this in 7.0, broke it briefly later, but fixed it for good in 8.0 and above.

And don't even get me started on the fact that TCP keepalives are still the default in OpenSSH, despite known security concerns with having a keepalive outside the security envelope, and therefore injectable by an attacker.

Exactly. There are much better technologies available for that purpose. I'm sure we can find a way to adapt this technology from network communications to file systems.

I'm surprised such a router isn't readily available, especially with the new "evil bit" in RFC 3514: http://www.faqs.org/rfcs/rfc3514.html :P

If only we had some way to differentiate "good traffic" from "bad traffic". Something like RFC 3514...

I don't know about coffee, but there's an official standard for IP datagram transmission via carrier pigeon:

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

Just because sendmail, exim, and postfix don't adhere to the RFC doesn't mean that qmail shouldn't either. If the protocol needs to be changed, then change the protocol. Ignoring the protocol just because someone else already did just leads to problems down the road.

Like it or not, the protocol specifies that lines must end with CRLF. RFC 2821 says:

2.3.7 Lines

      SMTP commands and, unless altered by a service extension, message
      data, are transmitted in "lines". Lines consist of zero or more data
      characters terminated by the sequence ASCII character "CR" (hex value
      0D) followed immediately by ASCII character "LF" (hex value 0A).
      This termination sequence is denoted as in this document.
      Conforming implementations MUST NOT recognize or generate any other
      character or character sequence as a line terminator. Limits MAY be
      imposed on line lengths by servers (see section 4.5.3).

      In addition, the appearance of "bare" "CR" or "LF" characters in text
      (i.e., either without the other) has a long history of causing
      problems in mail implementations and applications that use the mail
      system as a tool. SMTP client implementations MUST NOT transmit
      these characters except when they are intended as line terminators
      and then MUST, as indicated above, transmit them only as a
      sequence.

The problem with non-latin characters is technical, not merely political, and moving to a UN organisation won't make the technical issues go away. You would have to come up with something which doesn't break existing implementations, but is simulataneously sufficient enough that you won't have to revamp it again in ten years time. When somebody comes up with a working implementation for this that won't break thinsg across the globe, and if ICANN rejects it on political reasons, then one could start discussing it.

This has already been done in the form of RFC3492 punycode . The biggest problem with using Unicode for domain names is that is makes phishing attacks to bogus sites harder to detect because of the large number of similar looking characters in the system. Current browsers take some steps to mitigate this problem but they all do it in different ways. The main problem now is not technical but the human tendency for greed and dishonesty.

is Lego. (or Lego Bricks to be _really_ picky)

Thanks for providing links to the RFCs. That helps me understand where you're coming from.

As for the relevence of TCP RFCs, they're very relevant. What we're talking about is how to respond to a TCP SYN, which by it's very nature is a TCP operation. A connection exists on the client's end the moment it sends a SYN. It's not in 'established' state, but is in 'SYN-SENT' state and entered in the connection table. The server doesn't need to acknowledge a connection attempt to tell the client to tear down it's connection. I totally agree with you for non-TCP protocols, but TCP is different.

See RFC 1122 which states in part;
    " A Destination Unreachable message that is received MUST be
                        reported to the transport layer. The transport layer SHOULD
                        use the information appropriately; for example, see Sections
                        4.1.3.3, 4.2.3.9, and 4.2.4 below. A transport protocol
                        that has its own mechanism for notifying the sender that a
                        port is unreachable (e.g., TCP, which sends RST segments)
                        MUST nevertheless accept an ICMP Port Unreachable for the
                        same purpose."

The RFCs you've provided also support my explanation -- RFC 792 states;
"If, in the destination host, the IP module cannot deliver the
            datagram because the indicated protocol module or process port is
            not active, the destination host may send a destination
            unreachable message to the source host."
Note that it MAY send an unreachable. It's not required. In my experience, most stacks will send a type 3 code 3 in response to UDP attempts to closed ports, but never TCP.

RFC 1812 also states;
" Routers MUST be able to generate the Redirect for Host
      message (Code 1) and SHOULD be able to generate the Redirect for Type
      of Service and Host message (Code 3) specified in [INTERNET:8]."
Note 'SHOULD' which in RFC parlance means it's not required.

Under the section "5.3.9 Packet Filtering and Access Lists" which seems most related to our discussion;
"The router SHOULD allow an appropriate ICMP unreachable message to be
      sent when a packet is discarded. The ICMP message SHOULD specify
      Communication Administratively Prohibited (code 13) as the reason for
      the destination being unreachable."
Again, it's not a requirement, but it's recommended.

There are three ways in which the "Bcc:" field is used. In the first case, when a message containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is removed even though all of the recipients (including those specified in the "Bcc:" field) are sent a copy of the message. In the second case, recipients specified in the "To:" and "Cc:" lines each are sent a copy of the message with the "Bcc:" line removed as above, but the recipients on the "Bcc:" line get a separate copy of the message containing a "Bcc:" line. (When there are multiple recipient addresses in the "Bcc:" field, some implementations actually send a separate copy of the message to each recipient with a "Bcc:" containing only the address of that particular recipient.) Finally, since a "Bcc:" field may contain no addresses, a "Bcc:" field can be sent without any addresses indicating to the recipients that blind copies were sent to someone.

So it seems that bt clients now need a "Comcast switch" to ignore RSTs, like you suggest. I seem to recall that the Great Firewall of China is using the same RST approach to block a lot of content.

Thanks, guys, for encouraging us to ignore RSTs. Seems like a *great* idea for your network's long-term health. Why don't you just assign bt traffic an evil bit and let our RFC standards process do the rest?

This just cries out for someone to implement a page fetch of this using RFC 1149.
Then to archive the transmit and receive buffers in a book.

http://www.faqs.org/rfcs/rfc1149.html
--
Frame Format

      The IP datagram is printed, on a small scroll of paper, in
      hexadecimal, with each octet separated by whitestuff and blackstuff.
      The scroll of paper is wrapped around one leg of the avian carrier.
      A band of duct tape is used to secure the datagram's edges. The
      bandwidth is limited to the leg length. The MTU is variable, and
      paradoxically, generally increases with increased carrier age. A
      typical MTU is 256 milligrams. Some datagram padding may be needed.

      Upon receipt, the duct tape is removed and the paper copy of the
      datagram is optically scanned into a electronically transmittable
      form.
--

LOL. I'd love to see this one hit the courts: "RIAA vs RFC 1149".

Yet. The additional requirements will be forthcoming (once the foot is in the door).

How many times do I have to say, read the PDF (RTPDF?)

These are the requirements, in full, for viewing and public comment. Even including reasons why they want to do what they are asking. In English.

There is no "foot in the door" There's not even a door. Not even in the sense there is no spoon, it's just that a door is not included.

Perhaps I can translate into geek, this being Slashdot and all. You know RFC? This is an RFC. The RFC793 for TCP didn't leave a "foot in the door" for packets built of cheese whiz, or for TCP to arbitrarily move to the application layer.

Unixware was NOT Netware under Unix, it was Unix Sys V R4.2. Netware for Unix was a product sold by Novell before they even acquired Unix from USL well.. http://www.faqs.org/faqs/unix-faq/unixware/general/ Anyway, know your history :-) good advise indeed

http://www.lastgasp.com/d/21573/

Uncle Festor's Silent Death looks fun:

http://www.unclefesterbooks.com/book_sd.html

Any book on pyrotechnics manufacture likely has multiple uses as well.

rec.pyrotechnics FAQ:

http://www.faqs.org/faqs/pyrotechnics-faq/

All kinds of fun:

http://www.textfiles.com/anarchy/

OpenPGP is an IETF standard. Just like S/MIME and ASN.1

http://www.ietf.org/rfc/rfc2440.txt
http://www.faqs.org/rfcs/rfc3156.html

It's impossible to embarrass those who produce bad science.

Well, I'm going to try with you.

The link from man-made CFCs to ozone depletion was tenuous at best.

False. Try educating yourself.

Preliminary investigation into volcanoes shows that the amount of chlorine they spew dwarfs what man produces, and it is lost high in the atmosphere, instead of feet from the ground.

Absolute bollocks. See here.

But, it really troubles me to see a lot of the bad science that is repeated over and over without being checked.

Irony, thy name is uigrad_2000.

Ah yes, RFC1149. What a glorious upgrade from the rock network. Basically, in the old days, you would chisel your message onto a stone, preferably a small one, then lob it at your neighbor, and he would read the address, then throw it in the direction he thought it was supposed to go, and so on until it infrequently arrived at its intended destination. There's an ugly rumor that some 80% of the lost packets can be found at the bottom of Lake Wobegon as the result of a malicious MITM attack.

* A Set-Cookie from request-host x.foo.com for Domain=.foo.com would be accepted.

Having been around at the beginning, I should comment on this.

There are some fundamental problems with the way the Internet works, but hardware has saved us from having to solve them. The biggest problem is that we still can't deal effectively with congestion in the middle of a pure datagram network. We know what to do out near the edges (look up "fair queuing", which I invented), but in the middle, where there are too many flows and too little transit delay, that doesn't work.

The practical solution to the problem has been cheap long-haul bandwidth in the backbone of the network, with routers to match. Early users of the modern Internet may remember the days when MAE-EAST and MAE-WEST would choke on traffic and the whole backbone would start losing half the packets. That was solved by cheap fibre optic links. Today, we have a network where the "last mile" usually saturates before the backbone does. This is what makes the whole thing work. But we never did get a good technical solution to that problem. We have some good hacks: the congestion window in TCP and "Random Early Drop", which together sort of work. At least where most of the traffic is TCP. We still don't have equally effective ways of throttling UDP traffic.

Roberts is a virtual circuit guy. He founded Telenet, which was a virtual circuit system. (I was recruited by Telenet when they had 13 employees, but turned them down.) Telenet was a flop commercially; it didn't scale up well. Telcos love virtual circuits, because they create connections they can bill. And they keep trying to get virtual circuits into the network. X.25, ISDN, ATM, and PPPoE are virtual circuit systems, and they all came from telcos. Roberts is still pushing variations on his virtual circuit scheme.

There are continuing attempts to get some kind of billable virtual circuit thing into the network, and those attempts consistently come from telcos. There was a scheme tried for using multiple PPPoE connections over ADSL links to provide multiple classes of service, with the good ones being more expensive. That didn't fly. The whole "net neutrality" thing is about this. What telcos really want is to be able to charge based on the "value to the consumer". The wireless phone people do this, and cash in big - SMS messages cost more to send than photos. The wireline telcos see themselves being cut out of the revenue stream as video moves to the Internet. They want to create a place where they can step on the hose and cut off the flow unless you pay them extra.

I wrote the classic RFC on this too many years ago. Read the section "Game Theoretic Aspects of Network Congestion". It's still valid. But, as I said above, we don't have to solve the theoretical problem as long as throwing cheap backbone bandwidth at it works. Cheap backbone bandwidth will continue to be available unless some monopoly situation develops that prevents backbone bandwidth from being provided near cost.

Reference RFC 1149 for all the data currently available....

• RFC 1149 - Standard for the transmission of IP datagrams on avian carriers
• RFC 2549 - IP over Avian Carriers with Quality of Service

And don't try to protest that homing pigeons are impractical! They have been tested in a real implementation and has actually been demonstrated to be faster than ADSL.

• RFC 1149 - Standard for the transmission of IP datagrams on avian carriers
• RFC 2549 - IP over Avian Carriers with Quality of Service

And don't try to protest that homing pigeons are impractical! They have been tested in a real implementation and has actually been demonstrated to be faster than ADSL.

Please read here:

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

For more information. This is a method that can be used pretty much anywhere though some special conditions apply.

I haven't found a way to do without DHCPv6. See rfc 4704

There was a draft rfc, draft-jeong-ipv6-ra-dns-autoconf-00.txt but it was later rejected because of scale issues; required management of authorization information for individual hosts.

There is a long thread about ipv6 & dynamic updates located here

There is a draft rfc for adding a router message to the autoconfiguration of ipv6 addresses to include sending dns addresses. The draft is available here. Of course after the draft is finalized kernel(linux, *bds, windows, etc) support will need to be added.

The ipv6 autoconfig is nice but lacks the useful things(ntp, dns, etc) that DHCP provides.

"Correct me if I'm wrong but isn't it that in order for a file format to be accepted as an ISO standard there has to be at least a couple of independent working implementations?"

It's RFCs and Internet Standards which need to have multiple implementations. See RFC 2026 for the meta-standard (explanation of what standards an RFC needs to meet)

Internet standards are also required have been tested in real-world scenarios for long periods, plus they should be as simple as possible to implement, plus all discussion needs to be in public, which might explain their popularity compared to ISO computing standards.

Interestingly, if there's a patent needed in an RFC, then the two reference implmentations even need to have used "separate exercises of the licensing process"

Why? You have all that hardware, why not use it? I mean unless it starts to intefere with your real work, and there is no evidence that it is doing that, then you are fine.