Slashdot Mirror

Hey guys, nevermind this article, I found something even more amazing.
I know it's offtopic, but have you guys heard about this new RFC3514 that implements an "Evil Bit" for TCP/IP?

RFC 3514 is now available. It provides for an additional so called 'Evil Bit' that can be used to determine the nature of the TCP/IP packet. This should vastly simplify networking and internet security, and prevent the beepers of tired sysadmins from going off and interfering with Warcraft III!"

Ok, now some actual information. Since the ftp isn't allowing users in anymore, here is an http link for the same page:

http://ftp.rfc-editor.org/in-notes/rfc3514.txt

It works, and you don't run into the FTP user limit.

I don't mean to interrupt this thread, but has anyone seen this. Its an RFC that adds an new bit field to TCP/IP headers for packets that have malicious intent.

I haven't seen it at /. , and its hilarious.

Actually, "today" (1 April) is also the 13th anniversary of RFC1149.

Check out its majesty: ftp://ftp.rfc-editor.org/in-notes/rfc1149.txt

People were so much more creative back in 1990. ;-)

There may be some strange cosmic significance about April 1st, or just a series of amazing coincidences, but many RFCs published on April 1st are of amazing importance.

Potentially devastating Y10k problem

Lifesaving method to temporarily reroute ip in cause of equipment failure

Protocol to guarantee software engineer productivity and efficiency

Addressing ipv6 with incredible bandwidth savings

Planning ahead to Star Trek technology with current protocols and infrastructure

I don't even know what this one is about...

And many, many more. Any self-respecting network engineer should be especially familiar with all April 1st RFCs, in my opinion...

There may be some strange cosmic significance about April 1st, or just a series of amazing coincidences, but many RFCs published on April 1st are of amazing importance.

Potentially devastating Y10k problem

Lifesaving method to temporarily reroute ip in cause of equipment failure

Protocol to guarantee software engineer productivity and efficiency

Addressing ipv6 with incredible bandwidth savings

Planning ahead to Star Trek technology with current protocols and infrastructure

I don't even know what this one is about...

And many, many more. Any self-respecting network engineer should be especially familiar with all April 1st RFCs, in my opinion...

There may be some strange cosmic significance about April 1st, or just a series of amazing coincidences, but many RFCs published on April 1st are of amazing importance.

Potentially devastating Y10k problem

Lifesaving method to temporarily reroute ip in cause of equipment failure

Protocol to guarantee software engineer productivity and efficiency

Addressing ipv6 with incredible bandwidth savings

Planning ahead to Star Trek technology with current protocols and infrastructure

I don't even know what this one is about...

And many, many more. Any self-respecting network engineer should be especially familiar with all April 1st RFCs, in my opinion...

There may be some strange cosmic significance about April 1st, or just a series of amazing coincidences, but many RFCs published on April 1st are of amazing importance.

Potentially devastating Y10k problem

Lifesaving method to temporarily reroute ip in cause of equipment failure

Protocol to guarantee software engineer productivity and efficiency

Addressing ipv6 with incredible bandwidth savings

Planning ahead to Star Trek technology with current protocols and infrastructure

I don't even know what this one is about...

And many, many more. Any self-respecting network engineer should be especially familiar with all April 1st RFCs, in my opinion...

There may be some strange cosmic significance about April 1st, or just a series of amazing coincidences, but many RFCs published on April 1st are of amazing importance.

Potentially devastating Y10k problem

Lifesaving method to temporarily reroute ip in cause of equipment failure

Protocol to guarantee software engineer productivity and efficiency

Addressing ipv6 with incredible bandwidth savings

Planning ahead to Star Trek technology with current protocols and infrastructure

I don't even know what this one is about...

And many, many more. Any self-respecting network engineer should be especially familiar with all April 1st RFCs, in my opinion...

There may be some strange cosmic significance about April 1st, or just a series of amazing coincidences, but many RFCs published on April 1st are of amazing importance.

Potentially devastating Y10k problem

Lifesaving method to temporarily reroute ip in cause of equipment failure

Protocol to guarantee software engineer productivity and efficiency

Addressing ipv6 with incredible bandwidth savings

Planning ahead to Star Trek technology with current protocols and infrastructure

I don't even know what this one is about...

And many, many more. Any self-respecting network engineer should be especially familiar with all April 1st RFCs, in my opinion...

DNS is designed to be an extensible, flexible, distributed, and massively scaleable lookup database. It is quite suited to what you propose, and has certainly been used for much lamer ideas already.

I wouldn't use TXT records, though. SRV records might be more appropriate, but people are apparently using SRV for LDAP nowadays so you're probably better off just defining a new type. Use the procedure laid out in the RFCs for designating a new type of "experimental" DNS record, so that everyone will be compatible with you (well, everyone that follows the RFCs, anyway, which might leave out MS and DJB) or figure out how to use one of the obsolete record types.

You can look at some of the other types of records in RFCs 1035, 1183, 1706, 1886, 2672, 2782, and 2874. Most of the important ones (well, other than IPv6 stuff) are in RFC1035.

Incidentally, you're going to get dozens (if not hundreds) of posts here that will say "You shouldn't do that with DNS!". Pretty much any question you ask around here that even mentions DNS will get the same result, so just ignore them. I think these people are a lot more interested in shooting down ideas than in actually testing them, which is the only real way to find out if they will work.

And here I thought they were referring to RFC 1464: Using the Domain Name System To Store Arbitrary String Attributes....

Why not start off with whitelisting? Add some extension to SMTP that would sign outgoing mail with a domain certificate. Old, noncompliant software could ignore the extension. Newer versions could verify the signature and bypass the spam (message content) filters, but check the domain name against a domain blacklist. Once a domain was found to be a source of spam, it could be added to a domain blacklist (or better yet, request that they get put on the CRL!). Eventually, you'd get to the point where you (the mail server admin) would feel comfortable requiring all domains to sign their mail to you.

How about it, guys? (I looked, and this was the closest thing I could find.)

For an IPv6 network to work, all hosts need to be aware of IPv6. That would be "native IPv6" (not sure about the term, but you get the picture!). That is, you need your ISP/OS/Routers/whatever is in the middle to know IPv6.

You could also tunnel IPv6 over IPv4, so two ends could communicate using IPv6 in a v4 network.

Or, you could use a gateway, like sixxs.org. There is some info in the link supplied in the article, but if you want the big stuff, please RTFRFC 2460!

HTH!

Obsoleted by RFC 3207 (Feb 2002)

There are several other benefits to IPv6 IETF is implementing while they are updating the protocol. They don't wish to do it too often for obvious reasons and will try to get as much useful stuff in the new version while they're at it.

IPv6...

- ... will support IPSec intrinsically to provide end-to-end security on protocol level.

- ... eliminates the need of NAT with special "local" addresses.

- ... supports QoS features.

- ... supports multihomed devices and load balancing, since an IPv6 address specifies a network interface, not a computer as in IPv4.

- ... uses "modularized" headers where only the necessary fields are used. This essentially makes IPv6 more optimized than IPv4. For example, if the payload of a packet is larger than 64KB, IPv6 will attach another field for "jumbo payloads" and set the 16-bit value to 0.

- ... contains improved multicast support (as an extension header), support for an authentication header (also an optional extension header), and an encryption header (also an optional extension header).

- ... provides enhancements for DNS.

- ... provides automatic neighbor discovery which is especially useful for ad hoc networks and wireless devices.

- ... has a completely rewritten adress autoconfiguration.

See also:
IPv6: The Promise, The Problems, The Protocol
RDC 2373

I'm quite sure you can get a good randomness by recording noise from your (cheap) sound card.

RFC 1750 describes techniques to use not only the audio but the video hardware as well as disk drives to achieve randomness

who's actually using IPv6? I know some use it privately within their org, but are there any publicly using it?

ah, lots of people, actually... it's all over the routers and servers, nowdays... but the local network admin and network engineers are probably doing their best to make the migration as invisible as possible.

A good starting point to learn more about IPv6 would be www.internet2.edu. If you check out the corporate partners, you'll notice that ATT&T, Cisco, IBM, Intel, Lucent, Microsoft, Nortel, Qwest, SBC, and Sun are all in on the "Internet2" act, which includes the IPv6 protocol And the list of affiliated universities stretches nearly 200 members long...

Anyhow, Sun Solaris 9, Microsoft Windows2000, Microsoft WindowsXP, and Cisco IOS all have support for IPv6, as I understand... They're publicaly using it and supporting it.

If you want to know more about IPv6, check out this link and just search for the term "IPv6"... you should get about 93 articles regarding the Request For Comments (RFC) procedure used to define the protocol... As you will notice, IPv6 is a 128bit protocol, and was designed to be able to be broken up into 4 32bit packets, which allows it to interoperate with older IPv4 networks...

Moral of the story is that there are millions of people already using IPv6 on their client machines, who already don't know and don't care about the specific protocol implementations...

The article refers to an award for application developers to develop IPv6 enabled applications... If you calculate the ratio between IPv6 address and the total surface area of the earth, you will notice that there are approximately 2,000 IP addresses per square meter, with the IPv6 protocol... enough to give an address to every nut, bolt, and widget in every plane, train, and automobile on earth, with billions and billions left over... The awards will be going to people who figure out not just how to use IPv6, but how to code new applications and new uses for that kind of domain space...

SIP and video is NO different than SIP and audio, or SIP and bazookie player commands. SIP is the Session Initiation Protocol and, underneath it all, it's just a way to exchange offer/answer pairs of SDP (session description protocol) so the endpoints (eg. phones) can do what they wish.

Once you have a user agent (endpoint / phone) that groks audio SDP, you just need an appropriate way to render video and you have a video phone if that's what you want. If you want to exchange chess moves by SIP, you can do that too. It's just about establishing a session (out of band from the signalling).

You can read more in the actual RFC 3261 .

Examination of RFC821 and RFC2505 shows that any 55x error is (paraphrase) a permanent negative result code indicating that the receiving system cannot accept the message.

The third digit allows for fine gradation of replies, and "552" is a common return code from a spam filter.

This is a design decision -- in many cases, you don't want your anti-spam filter to return a result that could be interpreted to mean:

"What you just sent me triggered a threshold limit, if you take out some exclamation points and only mention viagra once, I might let it through next time"

Actually IDNs have their IETF approved standard called "Internationalizing Domain Names In Applications" (IDNA). It calls for changes to individual applications to support IDNs. It is composed of three standards that are going to be published as RFCs and are currently in the queue of RFC editor.

The IDNA standard is currently used by many application developers. For example Mozilla guys are including IDNA in some parts of the Mozilla project

Do you know many thousands of .org domains are out there? With /etc/hosts, when you go to look up a domain name, it loads up /etc/hosts, and checks, line by line if the domain is in there.

Imagine that your /etc/hosts file has 50,000 hosts in it (which is NOT ALOT, considering the amount of existing domains out there). Now imagine the 2 billion people that are on the internet are hitting your /etc/hosts based nameserver to look up aolsucks.org.
SQL servers, good ones, do table indexing and cacheing enableing lightning fast lookups even when there are hundreds of thousands of people accessing database (assumeing a fast enough server).

DNS does ALOT more then just mapping names to numbers. If you are interested head over to the dns rfc over here

Actually, according to RFC 2606 (Reserved Top Level DNS Names), .localhost can be blocked by the local DNS, as it is an invalid name (along with .test, .example, .invalid, and .example.(com|org|net)). These are supposed to be used for testing and documentation, so if they aren't in use, they may as well be blocked.

Actually, I use some_string@example.com just to prevent this sort of thing.

Since example.com is not available for registration, no one gets hurt.

The first problem is that the Reply-To field is optional as defined by RFC 2822. Secondly I would see this as an absolute nightmare for list admins. I run a mailing list for <insert open source project here>. Joe Blow signs up for it. For Joe to receive mailing list mail, someone has to respond to a message sent to the Reply-To address (which is usually the list's posting address) with whatever is needed to verify the address. Now the mail sent to Joe is auto-acking the list. Problem. Another problem. Joe wants to sign up for a mailing list no one on the server has ever signed up for before. He signs up. The MTA tries to verify that the sending address exists by auto-acking it. The sending address could very well be directed to /dev/null because a human response isn't supposed to be sent to that address. To confirm the opt-in Joe was supposed to load a URL from the initial message. Whoops. Joe can't join the list. There are ain infinite number of possible problems if a verification protocol is wrapped around email.

Yes, you're confused. T/TCP is an extension to TCP, over which HTTP runs.

Yes, you're confused. T/TCP is an extension to TCP, over which HTTP runs.

Yes, you're confused. T/TCP is an extension to TCP, over which HTTP runs.

Not a standard. RFC 1644 is classed experimental; it's not a standards-track protocol. See The Internet Standards Process (RFC 2026). The claim in the story leader that Microsoft were somehow ignoring RFCs looks, uh, foolish though, which is the point you were making.

For example, on banking sites (and other sites that want transactional semantics), the Back button will often force a reload if your browser honors "Pragma: no-cache" or "Cache-control" headers.

This is not correct behaviour. The HTTP 1.1 specification specifically states (section 13.13) that cache control should not prevent the viewing of stale pages in a browser history.

sounds like a job for rfc 1149

Uhm, no. I know a whole bunch of network security and abuse staff. The response to any complaint with ZoneAlarm, BlackIce etc logfiles in it is to close the ticket, usually with an annotation like 'GWF' (Goober with Firewall). 99% of those reports are frivolous, about normal network traffic.

Some ill-knowledged network admins do produce a lot of such 'frivolous' reports.

I'm not by job a network admin or specialist, but I do a lot of networking stuffs. One day I've got a mail CC to me saying that one of our network was under attack. The alleged 'hacker' was able to go thru their firewall and started scanning the rest of the boxes within.

Though not directly for my action, I took this case seriously, but 7 sec later I found out it's just a false alarm: the 'hacker' address in question is in fact a 169.254.x.x address, the ports the 'hacker' was scanning is 137/139.

169.254.x.x is the 'link local' block, and it could never get pass the firewall from outside(no matter how lame it is) from outside. Also, even a layman know 137/139 are the netbios scanning for windows file sharing. Deeper in the log I found this 'hacker' attempted to access a DNS which is owned by ASL. Then I immediately know that this must be a absent-minded ASL technican who came to perform technical support, carrying a laptop with 169.254.x.x address, and it attempted to re-established windows shared and internet connection when he powered up the laptop.

I told my boss about my foundings, but I'm sure he'd ignore it. The report has already went thru 7 layers of management(forwarded 7 times, some of them are network admin and specialists) and each layer vowed to take serious action. The topest layer already held meeting for further action dealing with this 'most serious security hazard ever'.

It's not really in my position to tell them they are bunch of morons.

TCP SACK (which suggests a resend of the blocks between the acknowledged ones) is becoming common; Linux 2.1.100 and Win98 both had it.

RFC 1035

The Internet supports name server access using TCP [RFC-793] on server port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP port 53 (decimal).

-dk

This is called "Delivery Status Notification" and has been a standard for some time now.

Before the Internet was big, I worked with proprietary (non-SMTP) inter-office mail systems. I remember one system in particular had this feature where it would display the status of a message to the message sender or administrator. A message would be marked "read" if the user lingered on the message for some configurable amount of time (remember, this was non-standard mail, so the vendor wrote both the client and the server).

I'm certain you can see the problems with this system: it's something of an invasion of privacy. Boss sends user a mail, user doesn't complete task in mail before lunch, boss confronts user, user claims he only had time to skim over the message, boss tells admin to pull out the logs.

Anyway, this can result in some pretty nasty situations, so I'm guessing the reason this hasn't been widely-implemented is because users actually don't want this (I just read through the standard and I can see a number of other technical problems which have possibly delayed its acceptance). I certainly don't want anything like this (even without that evil MUA behaviour described above, this sort of raises the bar for email, making it a "more serious" medium, and that changes the nature of what goes through email (consider what goes through email and why you would never receive a subpoena or summons through email)). If I had to complete every hair-brained idea sent to me through email from management, I would never get any work done. Without status notification, I can postpone this for a couple of days until I actually speak with the person involved and they've already forgot about the idea or we have a chance for a two-way conversation and I can convince them how bad their idea is.

AIM and ICQ are both owned by AOL. ICQ is the original IM.

Accurate.

And at one point was the most poular.

I think this is accurate, but i'm not sure.

There have occasionally been UNIX knockoffs, like the vastly inferior command line "talk" implementation, however it was incapable of letting you know whne new users had signed on, also, it could not do file transfers.

Um, wrong. If the parent post is a troll, this is probably the little "subtle absurdity" flag. The UNIX Talk protocol is very, very old and serves a different purpose than that of AIM. I'm not sure when it dates from, but i see here an RFC for a message-sending protocol to allow "write" messages to be sent across TCP/IP, that dates all the way back to 1983. For comparison, AOL was founded in 1985. Anyway, Talk has not traditionally been used quite the same way as AIM, for that purpose look at IRC. (Yes, it's slightly different.)

Programs like Trillian, that do what the author of this article suggests have been having a difficult time lately because they steal Yahoo, AOL, and Microsofts intellectual property, in an attempt to make money. It's like companies like Kazaa and Gnucleus that make money off of other people trading files. It's illegal. And not a good idea.

This is absolute nonsense. Trillian, GAIM, etc have been having no problems, as they are using AOL's servers with permission using the specifically-made-for-third-parties TOC protocol. The big sound fury about "stealing" was when MSN tried to use the OSCAR protocol used by AOL's AIM client instead of TOC, and AOL said "you can't do that, these are our servers and you have to agree to use TOC". This was a very reasonable issue, but the issue was over "unauthorized access and use of a computer system", not over "stealing intellectual property" (?? Where does intellectual property come into this? TOC is publicly documented, and when third-party AIM clients do some wierd runaround and try to slip in some OSCAR features, they do so using reverse-engineering, which is completely legal to the point of not even being an intellectual property issue). Anyway, Jabber has problems from time to time because AOL really, really seems to hate them, and so last i checked they are leaving TOC out of the main codebase for fear that jabber puts TOC support in, AOL will shut down TOC just to keep jabber out or something.

This is just AOL doing what is best. They saw a duplication of effort in their own company and decided to stop it.

Accurate.

I would bet that a lot more people would use Linux if Open Source programmers would wake up and realize that they also are (most of the time) duplicating effort. Gnome and KDE are but one example. Just search freshmeat for an mp3 database organizer one day, and you'll see what I mean.

This is opinion. However, it is by no means an invalid one.

As far as the DNS DDOS attack goes, the relationship between ICANN and the root servers is pretty fluid - it doesn't own or control them, though the Feds fund some of them, and it's more concerned with the master databases of who owns what names than the implementation issues of what IP address currently is attached to the names. Remember, ICANN are not engineers - they're intellectual property policy wonks. ICANN does encourage the root servers and the registries and registrars to follow security / reliability standards, and the recent DDOS attack means that there'll be some changes in the way things are run. There's an RFC 2870 on Root Name Server Operational Requirements, so if you've got opinions on how they can do a better job, go Comment.

ICANN's work on the top-level domains deserves mixed reviews. Moving slowly is usually ok; the big reasons for expanding the space are "because it gives us more cool names to sell", and one of the big reasons for going slowly is that you can only sell each TLD once, so you'd better get it right. Unfortunately, their definitions of getting it right strongly involve letting them stay in control, and are biased against any experimentation except along very narrow lines that they can stay in control of. But the IETF Ad-Hoc committee couldn't crack the political layer either. One thing both groups did right is pick a bunch of boring TLD names for the first batch, because they're going to make mistakes and discover unexpected problems in the first batch or two, and it's much better to mess up the market for .MUSEUM or .FIRM which nobody cares too much about than to mess up commercially valuable names like .INC or .LTD or .SEX or anything that overlaps with the voice telephone business.

IPv6 is Not ICANN's Job. It's the industry's, and the carriers', and Cisco's. ICANN does have the responsibility for coordinating the root servers' transition to support for IPv6 name lookups, and for making sure the Reverse DNS Lookup space (today's 1.0.0.127.in-addr.arpa PTR queries) gets managed correctly, though the standards work is probably the IETF's job, or maybe ISOC's. The one thing they've done in the IPv6 space that was Blatantly Evil (but probably reversable) was to claim that all your address bits are belong to them and set an unacceptably high price for the smallest routable address block. This not only delays widespread implementation until a major carrier either decides to pay them or ignore them, it nails down some assumptions about the shape of the hierarchy and organizational relationships that may be hard to repair, and increases the brittleness of the net without obviously benefitting the routing table situation (which is probably a more important IPv6 issue than the supply of address bits.) This delay gives them more time to try to finish grabbing power before IPv6's virtually-unlimited address space escapes from their ability to steal it from the world and sell it, but it also gives the industry more time to figure out what we're going to do with IPv6 and how to manage it, which is not a Bad Thing - there's a lot we really need to learn about how to use it before it's ready to replace IPv4.

RFC2396 goes into great detail about URI's and URL's. It covers the (minor for most of us) differences between them.

How's that? You don't have to use the new standards. You could just write everything in tried-and-true HTML 2.0 and screw anything else. But you wouldn't like that, being that you couldn't complain about browsers not rendering your content as you expected.

And now for my rant: you don't design for anything. You mark up structural data and let the UA handle it.

rfc2606 says that you, Mr. 456/23, do not exist.

HAND.

S

"The Mythical Man-Month", Brooks. Won't really help much, but you'll have the satisfaction of knowing exactly how your pointy haired managers are screwing things up.

"Design Patterns", Gamma, et al. Without this, you simply won't be able to understand current discussions about programs or programming. This book gives you the philosophy and vocabulary to understand what's going on.

"The Art of Computer Programming", Knuth. What can I say? An absolutely mindboggling treasure trove.

"Software Tools", Kernighan & Plauger. A Golden Oldie. The book is ancient, but the "software tool" concept is still solid.

"The Design of the Unix Operating System", Bach, and "The Design and Implememtation of the 4.4 BSD Operating System", McKusick et al. (These are old. I would hope there is something equivalent for Linux and current BSDs). While abstraction is all well and good, at some point you have to open up the black box and figure out what the machine is actually doing in there.

You need the definitive description of the language you're working with. For C, it's "The C Programming Language", Kernighan & Richie. For C++ it's "The C++ Programming Language", Stroustrup, or, if you're a standards junkie like me, INCITS/ISO/IEC 14882-1998, "ANSI Standard C++".

If you're doing anything connected with the Internet, learn about RFCs. Personally, I credit a large part of the success of the Internet to the free availability of its governing standards. (Other standards are freely available, but not available for free. A paper copy of ISO 14882, for example, is US$175.)

There are all sorts of "domain specific" books. What you need depends on what you're doing. I find "Advanced CORBA Programming with C++", henning & Vinoski, to be priceless, but then, I do CORBA programming in C++.

For years internet architects have built a house of cards that is not nearly as robust as it's outer appearance. In fact, there are some aspects that point to a fragile infrastructure just waiting for the final earthquake. The ATM backbone that Tom's previous company helped produce, is largely responsible for creating the packet lost instabilities in the network over the last 5 years. Under Vint Cerf's leadership at MCI/WorldCom/UUNet (Will WorldCom's Woes Engulf UUNet?) switched ATM networks created several years of heavy packetloss at key peering points, that can only cascade into total collapse if UUNet goes dark. This fragility might be the only thing that actually saves WorldCom/UUNet - the fear of what can happen without it.

With UUNet dark, the remaining network lacks the switching capacity to handle all of today's traffic (it barely can handle today's traffic without packet loss monitored here), much less short term growth as the world economy recovers from the dire recession. The resulting high packet loss would take us back 5 years where many DNS lookups timed out and simply failed due to high packet loss, and the network loading is dominated by 100% to 300% retries cascading into congestive failure (RFC896 Congestion Control in IP/TCP Internetworks. J. Nagle. January 1984).

There have been many people explore this issue, some very excellent papers (Quality of Service in the Internet: Fact, Fiction, or Compromise? by Paul Ferguson and Geoff Huston) - but largely missed are very basic architectural issues like NTP time syncronization network wide for packet loss retransmission that CREATES well synchronized additional packet loss. This happens because the retranmissions are all timed to arrive at the same time in overloaded switches just to be dropped again due to servers having their scheduling clocks syncronized at a very low rate of 50/60/100/1K Hertz.

A study I did in 1997 of peering point packet loss showed that 90% of packet loss observed correlated to retransmit clock boundries. Changes in traffic flow from primarily mail and ftp in the early 90's, to web traffic where browsers launch 4-20 concurrent small file lookups changed the nature and ability for Slow Start to be effective in throttling loads causing packet loss (web browser designers flood requests to mask packet loss timeouts) and the short files which are often only a couple packets in length do not throttle with TCP window size controls.

Nothing in the next generation design of the internet (IPv6, VoIP, Streaming UDP MP3's, FPS games which flood packets, or any other new protocol) addresses these critical failings ... in fact there is a huge head in the sand approach to just continue providing excess bandwidth and applications to saturate it even more quickly.

Tom's suggestions largely miss the boat, for all the wrong reasons - but the end conclusion is correct - the biggest problems tomarrow are not going to be solved by the solutions being offered.

From the point of view of a machine connected to the Internet by cable modem, in terms of rejected TCP SYN packets, grouped by destination port, over a period of a little over 2 weeks:

1. port 1433 (MS SQL server), with 1325 packets
2. port 27374 (SubSeven, a Windows backdoor program), with 393 packets
3. port 12345 (NetBus, another Windows backdoor program), with 361 packets
4. port 80 (HTTP, of course), with 205 packets. (Since the connections aren't accepted, I have no data on which specific exploits they might be intended for.)
5. port 119 (Usenet NNTP), with a paltry 66 packets
6. port 21 (FTP), with 59 packets.

From the point of view of a machine connected to the Internet by cable modem, in terms of rejected TCP SYN packets, grouped by destination port, over a period of a little over 2 weeks:

1. port 1433 (MS SQL server), with 1325 packets
2. port 27374 (SubSeven, a Windows backdoor program), with 393 packets
3. port 12345 (NetBus, another Windows backdoor program), with 361 packets
4. port 80 (HTTP, of course), with 205 packets. (Since the connections aren't accepted, I have no data on which specific exploits they might be intended for.)
5. port 119 (Usenet NNTP), with a paltry 66 packets
6. port 21 (FTP), with 59 packets.

From the point of view of a machine connected to the Internet by cable modem, in terms of rejected TCP SYN packets, grouped by destination port, over a period of a little over 2 weeks:

1. port 1433 (MS SQL server), with 1325 packets
2. port 27374 (SubSeven, a Windows backdoor program), with 393 packets
3. port 12345 (NetBus, another Windows backdoor program), with 361 packets
4. port 80 (HTTP, of course), with 205 packets. (Since the connections aren't accepted, I have no data on which specific exploits they might be intended for.)
5. port 119 (Usenet NNTP), with a paltry 66 packets
6. port 21 (FTP), with 59 packets.

I think it's the owner of someone (at) somewhere.com posts to bugtraq.

example.com
example.net
example.org

Are the RFC 2606 eserved domains you should use in examples, such as the parent post.

Also reserved are the TLDs: .test .example .invalid .localhost

I don't know if it's been updated since, but they don't mention the common "localhost.localdomain" that I see a lot. I guess it really doesn't matter too much, except for trash traffic to the root name servers if someone messes it up.

Perhaps if ISPs were only allowed to track IP addresses....

Um, there's this thing the DNS has called a PTR record... although if the questionable host name is just a web vhost (that is, it's a non-canonical name; the IP address doesn't map back to the same domain name), you might be okay, if the actual web server isn't also named something noteworthy (e.g. www3.smutserver.com).

http://www.rfc-editor.org/cgi-bin/rfcdoctype.pl?lo c=RFC&letsgo=1305&type=ftp&file_format=txt