Slashdot Mirror

Rec.puzzles FAQ has great hints for that one. usenet is your friend.

They're blocking outbound SMTP from desktops? That's cool. Use the submission port. It exists for this reason - ISPs (or employers) can block outbound SMTP to curb problems with spammers and worms connecting directly to the recipient's SMTP server. Legitimate clients (like you) can connect to your other ISP's submission port, which is the same as the SMTP port except that it typically requires SASL authentication.

Or you could simply set up SPF to allow messages from yoru domain to come from your ISP's mail servers.

Or you could just not publish SPF records at all, in which email addressed from you could come from anywhere. You'd still be able to take advantage of SPF to filter forged messages from other people.

Jon Postel passed away October 16, 1998, so I doubt there's much that the ??AA can do now. Incidentally, here is the initial RFC for FTP, which gives credit to J. Postel.

Almost every NOAA scientist that I know (NB: I know quite a few) is proficient in Fortran and IDL. This is the norm in atmospheric science.

The models -- actually complicated software written in a computer language called Fortran -- attempt to account for everything happening in the atmosphere on a global basis.

Nope, earlier than that. About 29 years for those of us who connected via IMP to the Arpanet.

Some people will complain about latency, but the real problem with satellite dish for internet is that it is so damned expensive!

"These documents do not appear to have been the result of technology that was available in 1972 and 1973," said Bill Flynn, one of country's top authorities on document authentication. "The cumulative evidence that's available ? indicates that these documents were produced on a computer, not a typewriter:"

Errr, in 1973 Bell Labs got a 1972 model Wang CAT Phototypesetter, for which the default font was Times Roman. Joe Ossana wrote a program called troff to drive it. This guy Flynn is clueless about the state of technology in those days. Why should we believe anything else he says?

See this, for example.

Here's some useful educational material for whatever moron modded this flamebait:

RFC 1631

RFC 2663

Here's some useful educational material for whatever moron modded this flamebait:

RFC 1631

RFC 2663

While this obviously isn't an ideal solution, users that cannot access
DNAME records can try to append .http.l2.l1.l0.nyucd.net:8090 (note the "C" in
nyuCd) to the end of hostnames, instead of the traditional .nyud.net:8090, to be able to use Coral today.

http://www.scs.cs.nyu.edu/coral/overview/#problems

People have recognised this problem (track by last 64 bits) and the solution is to generate random temporary addresses and use them instead - http://www.faqs.org/rfcs/rfc3041.html

If this is a measure of when people will start using IPv6, the answer is today. It's already there. Every major TCP/IP stack out there supports IPv6. Tunnel networks exist through IPv4. Internet 2 uses it exclusively.

When are corporations going to start moving to IPv6? Who knows...that will depend on individual needs, but in general, large corporations aren't going to see a big need to move towards IPv6 any time soon. Without end user by in, who is going to 'force' people to use IPv6?

Yes, IPv4 space is running out. It has been for a long time. That's why Network Address Translation and private address space are so common in today's world. They may be hacks, but they do the trick. Where's the business case involved in reorganizing major networks?

If this is a measure of when people will start using IPv6, the answer is today. It's already there. Every major TCP/IP stack out there supports IPv6. Tunnel networks exist through IPv4. Internet 2 uses it exclusively.

When are corporations going to start moving to IPv6? Who knows...that will depend on individual needs, but in general, large corporations aren't going to see a big need to move towards IPv6 any time soon. Without end user by in, who is going to 'force' people to use IPv6?

Yes, IPv4 space is running out. It has been for a long time. That's why Network Address Translation and private address space are so common in today's world. They may be hacks, but they do the trick. Where's the business case involved in reorganizing major networks?

here is a mirror

Apple did not create iCal the standard.

Quite right. In fact, in a twist of irony, the prinicpal authors of RFC 2445 are F. Dawson of Lotus and D. Stenerson of Microsoft.

Sometimes, I really wish Outlook 2002 had an iCalendar exporter (it does import iCalendar files, but it'll only export CSV).

Keep a *nix and a windows version of netcat on there. A few of the essential RFCs wouldn't hurt either, HTTP, IMAP, SMTP, among others.

Keep a *nix and a windows version of netcat on there. A few of the essential RFCs wouldn't hurt either, HTTP, IMAP, SMTP, among others.

Keep a *nix and a windows version of netcat on there. A few of the essential RFCs wouldn't hurt either, HTTP, IMAP, SMTP, among others.

Keep a *nix and a windows version of netcat on there. A few of the essential RFCs wouldn't hurt either, HTTP, IMAP, SMTP, among others.

I thought that was just a question of enough bananas, dude!

We could adapt the method using this technology! An interplanetary internet!

Sigh, there are several ways to approach setting up an Apache server. All of them are easy.

First one is to start with an empty configuration file and then cut and past in portions of the standard file until you get a minimally working server.

The good part about this approach is that you get the least amount of bells and whistles added. Security via a small footprint is a good thing. The bad part about this approach is that you end up with a minimal server that may need more tweaking to get everything working as you need it.

The second approach is to take the original configuration file and start chopping things out of it. Test each deletion to make sure that everything you need still works. Use something as simple as RCS to keep track of your changes.

The good part about this approach is that you'll have a server until you break it. You will also have a nice record of every configuration change you've made. The bad part about this approach is that you may end up with a fatter server than you need. This violates a security maxim of making the least footprint on the net necessary to accomplish the task.

The third way to configure Apache is from scratch. This is somewhat more complex than the other two, and can lead to unmaintainable configuration files.

The bonuses for creating your own configuration file include understanding what goes on in the Apache configuration, and making a nice, modular configuration file. The bad part about this is that if you don't comment your file, you'll get an unmaintainable mess. Unfortunately some consultants think this is a good thing.

As for chrooting Apache, it took me less than 15 seconds via Google to find a step by step procedure http://www.faqs.org/docs/securing/chap29sec254.htm l to chroot Apache on a Redhat Linux.

6. "Hitler!" Ha! The thread is over!

Nope, doesn't work that way. Not only is it wrong to say that a thread is over when Godwin's Law is invoked anyway (Usenet threads virtually always outlive their usefulness), but long ago a corollary to the Law was proposed and accepted by Taki "Quirk" Kogama (quirk@swcp.com):

Quirk's Exception: Intentional invocation of this so-called "Nazi Clause" is ineffectual.

Problems regarding accounts or comment posting should be sent to CowboyNeal.

Name "[C019](4)nyud(3)net(0)"
TYPE 39 (39) CLASS 1 TTL 1333 DLEN 25
DATA Unknown resource record type 39 at 012DBC41.

Given that the DNAME RFC is from 1999, it appears that some old DNS servers do not handle this record type well. We'll look into some alternatives or work-arounds. (Perhaps you can contact me directly to see if subsequent changes can fix your problem.)

Thanks for the detailed report!
--mike

Normally, films have to dumb down a book, so it's great to see a director who not only understands the book and manages to put much of its depth on screen, but actually adds to that depth and complexity in such an appropriate way!

I think I'm glad I saw the theatrical version first. Much as the voiceovers spoil that objectivity, I think that without them I'd have found it even harder to follow what was going on. (I think Ridley enjoys making his audience work hard :)

I'm also reminded of another P.K.Dick-based film, Total Recall. Much of that is a little shallow (though fun!), but there are still some very interesting undercurrents. In particular, it's a shame that they didn't make more of that moment about 2/3 of the way through where it's suggested that the hero's whole experience is nothing but the fantasy he originally went to have implanted. That scenario seems to be rejected, but as the film progresses it actually becomes more and more like the fantasy -- it'd be nice for it to have acknowledged that somehow, especially at the rather unconvincing end...

Exactly! Making things modular, and limited to single operations with no side effects, allows you think about how they interact far more easily, in no small part because it makes the actual interactions fewer.

Read The Art Of Unix Programming, particularly the chapter on compactness and orthogonality, to fully understand this.

Exactly! Making things modular, and limited to single operations with no side effects, allows you think about how they interact far more easily, in no small part because it makes the actual interactions fewer.

Read The Art Of Unix Programming, particularly the chapter on compactness and orthogonality, to fully understand this.

... and was apparently ad libbed by Rutger Hauer. (FAQ, section 12).

take your pick... the interview I'm remembering is Ford saying something like 'some people like the movie I guess, I just had a problem only having to walk around in front of futuristic set backdrops.'

Ridley says "So that didn't work out as a particularly good mix."

Aha, here's the interview:

He is also willing to admit that he is not fond of "Blade Runner," Ridley
Scott's futuristic cult favorite. "I played a detective who did no
detecting," he says. "There was nothing for me to do but stand around and give
some vain attempt to give some focus to Ridley's sets. I think some - a lot -
of people enjoy it, and that's their perogative."
- The Boston Globe, July 14, 1991 - BR FAQ

Given enough thrust, any pig can fly.

Here's the proof: RFC 1925, 2.(3)

I hope you at least block outbound port 25 (SMTP). Because this will be abused by spammers otherwise.

Legitimate people can still send mail through the submission port (see RFC 2476). This is a separate port that exists for MUAs to submit new mail; typically it requires SASL authentication. So they can connect to their own ISP's server and submit mail, but not send directly to the recipient's server, as a spammer would.

Not trying to be negative, but is the base system & kernel open sourced from Apple or didn't Apple take somebody else's work and lock it down? In other words I have the understanding that Apple took FreeBSD which is somebodyelses hard work and added their own stuff on top without releasing the stuff on top or how it interacts with the stuff provided by FreeBSD, or any changes they might have made to FreeBSD to make it better.

Apple bought a company called NeXT that had a proprietary BSD386 based OS running on the Mach Micro-Kernal. In the company was an employee who had done a large amount of the original work creating the Mach Micro-kernal. Apple took the NeXTStep / OpenStep operating system as the basis for its Mac OS X operating system. Apple ported it to the PowerPC Chip sets, fused it with knowledge gained from Apple's earlier Unix OSes A/UX and MkLinux and then re-synced the userland with FreeBSD 4.x (now they sync the userland to FreeBSD 5.x).

This might need more explaining. Unlike Linux where all each distribution has the same Linix kernal (sometimes compiled in different ways, but still the same kernal code), BSD branches do NOT have the same kernal. NetBSD, FreeBSD, OpenBSD, DragonflyBSD and Darwin(Mac OS X) are each different kernal code bases. Sometimes they share components / code, but mostly they do not. The different branches are designed to provide the same working userland to users and applications. By "re-synced the userland to FreeBSD" Apple did little more then confirm their OS is compatible with FreeBSD and either updated their own /bin and/usr/bin applications to feature / function compatibility with FreeBSD or ported the FreeBSD apps over, whichever made the most sense. Again all work was done by Apple Engineers.

So what Apple did was not "take somebody else's work and lock it down" but rather take the work Apple Engineers and the Engineers of a second company Apple bought (and retained the employees of) and release the code for no cost onto the internet.

OpenDarwin.org

While this is certainly valid given the license of FreeBSD, strictly speaking that's just being a thief as far as I'm concerned.(Yes I know MS has done this too with it's Unix Services layer).

If someone gives something to you for free, it is not stealing. The only people who are allowed a moral objection to how you use the freely given object are the ones who gave it to you. Far from being upset at it, BSD users "shouted for joy" that Apple choose to base their new OS on BSD. Daemon News: Apple -- What's in it for BSD?

I also understand however, that Apple has given some changes back to the KDE community for the web browser, locking up other changes however behind a proprietary license. In other words it looks to me like Apple is trying to garner some favor while stealing the "open source" community blind.

Every single piece of OpenSource software Apple has used (irrespective of the license it was released under and the requirement, or NOT, to release the code) they have release the code to. The code is available either through the Darwin OS , one of the other Apple Open Source Projects, or by giving the code back to the original developers. In addition to that Apple has also released code that was never before opensource, with projects such as OpenPlay , Darwin Streaming Server and

OK, found this http://www.faqs.org/docs/911/911Report-77.html, so there was some connection. I guess I sould pay more attention. Oh well.

1. "I watched the tapes of the Nuremburg experiments that showcased how people put in positions of authority could be ordered to torture and kill other people and that the majority of those tested in the study failed the "humanity" test."

1. What's the name of that law about when the argument gets to comparing the opponent with Nazi's?

1. As a Usenet discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches one.

You might want to look at this slashdot story about the subject, or as it mentions, this FAQ about the Newton OS (yes, the Apple Newton).

The Newton was very revolutionary in file storage; read and weep.

Yeah yeah... this is gonna sound harsh...

But really... is the 80 column limit that important to you?

You know that you can bump up the number of columns on console displays, right?

Read here :)

There are also a number of tools available to put code in a form that you find agreeable.

There's already the .example TLD (RFC 2606), plus example.com, example.org, and example.net.

It would be nice to have something a little shorter, but no matter what you do, it's going to seem a little odd to people reading the book or watching the movie or TV show, because they've never seen a domain name ending in 'example' in real life. Every time one of those 555 numbers comes on I wince a little, because I've never used one and it doesn't help my suspension of disbelief any.

OTOH, using an unroutable phone number or URL is better than deluging some poor person with prank calls or unwanted Web site attention. You would think Penguin Putnam would have *wanted* to use the title of the book to promote their website for it. Dumbasses.

Go read RFC 1597 before you continue to wax idiotic.

I remember those days. For the curious, look at OWS.

BIND9... don't get your hopes up. The BIND company sells paches for their software. Meaning that if you don't pay them money then you're going to be running an errornouse DNS server. [original emphasis]

Still most people use BIND for two reasons: no one wants to learn the crusty details of DNS and 2) Linux comes with BIND as it's default name library.

Alternative like djbdns should be used.

I wish it was so simple. There are two most important problems with djbdns, though. Namely:

1. unlike BIND, djbdns does not follow RFCs 1034/1035
2. unlike BIND, djbdns is not free software

Don't get me wrong, it is quite a solid piece of software (the laughable cracking contest notwithstanding) but it is not a complete DNS implementation (zone transfers, anyone?) which wouldn'd be such a big deal if it was free software, because anyone (myself included) could make it RFC compatible in few weeks (months at most) but unfortunately it is not.

Also, you should learn about BIND9 (and even BIND8) in the context of cache poisoning. It is not as big of a problem as you seem to believe.

Most people use BIND for two reasons indeed, but those reasons are:

1. BIND is the most complete DNS implementation
2. BIND is free software
3. ("permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted..." etc.) contrary to what you are trying to imply with your patches-selling remark

I am sure many--if not all--GNU/Linux distos will come with djbdns as soon as it is released as free software, for--as I have already said--it is quite a good piece of software, for a one man project.

BIND9... don't get your hopes up. The BIND company sells paches for their software. Meaning that if you don't pay them money then you're going to be running an errornouse DNS server. [original emphasis]

Still most people use BIND for two reasons: no one wants to learn the crusty details of DNS and 2) Linux comes with BIND as it's default name library.

Alternative like djbdns should be used.

I wish it was so simple. There are two most important problems with djbdns, though. Namely:

1. unlike BIND, djbdns does not follow RFCs 1034/1035
2. unlike BIND, djbdns is not free software

Don't get me wrong, it is quite a solid piece of software (the laughable cracking contest notwithstanding) but it is not a complete DNS implementation (zone transfers, anyone?) which wouldn'd be such a big deal if it was free software, because anyone (myself included) could make it RFC compatible in few weeks (months at most) but unfortunately it is not.

Also, you should learn about BIND9 (and even BIND8) in the context of cache poisoning. It is not as big of a problem as you seem to believe.

Most people use BIND for two reasons indeed, but those reasons are:

1. BIND is the most complete DNS implementation
2. BIND is free software
3. ("permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted..." etc.) contrary to what you are trying to imply with your patches-selling remark

I am sure many--if not all--GNU/Linux distos will come with djbdns as soon as it is released as free software, for--as I have already said--it is quite a good piece of software, for a one man project.

No, because having a server listen on a UDP port clearly signals the expectation of meaningful communication.

Seriously, read RFC 768, which defines UDP. It's a quick read. There's no way for a sender to know what happens to the UDP packets you send.

Even if somebody can sniff traffic in principle, he can't sniff everybody's traffic all the time. He has to evaluate which targets are likely to yield anything of value. Since a system protected by portknocking does not give him any clues of what he can expect to find, why would he sniff your traffic?

So if the relevant traffic-sniffing malware can catch data going to your machine, it would be trivial for it to figure out that the service is running. All it then needs to do is to capture traffic immediately prior to your next stream initiation to figure out what is going on.

Seems to me that a single, timestamped (and therefore non-replayable), cryptographically-generated UDP packet to a cryptographically-chosen UDP port would offer as much added security as port knocking (even with the one-time pad mentioned in the post). But the UDP technique has fewer complications in the implementation, which means it's more likely to be built correctly, which is a big part of security.

No, bash 3.0 is not compliant with RFC 2324.

I got my first PC-type computer in 1988. It was a Bondwell-made PC-XT computer with a 8MHz 8088-compatible processor, 360kB floppy drive and a 20MB hard disk. When I got the beast, I didn't have the guts to open the case so I could install a modem, but I did learn much.. after running my BBS on it for a couple of years and even connecting it to a UUCP network with Waffle, I had stripped it down to a motherboard with all the components and power supply on my table. Don't ask why. Anyway, somehow I managed to break the MB in half.
After a careful examination I decided it was worth a try to solder the board back together, so I went for it.. I'm so glad they hadn't invented multi-layer boards back then because the damn thing worked like nothing had happened! After this it was easy to repair my modem that had been struck by a lightning.

I'm tempted to answer your points directly, however, I think it would be better to spend my time pointing you towards the following documents, which, firstly, describe the Internet architecture, and why it was designed the way it is, and secondly, describe how NAT / overlapping address spaces break the architecture. I don't think a debate on NAT can take place until both the design of the Internet and how NAT breaks that design are understood.

• RFC 1958 - Architectural Principles of the Internet - Section 2.3 "It is also generally felt that end-to-end functions can best be realised by end-to-end protocols." is the property that NAT breaks.
• RFC 1631 - The IP Network Address Translator (NAT) - even the original NAT RFC suggests limitations - from section 4. "Conclusions" - "NAT may be a good short term solution to the address depletion and scaling problems. This is because it requires very few changes and can be installed incrementally. NAT has several negative characteristics that make it inappropriate as a long term solution, and may make it inappropriate even as a short term solution. Only implementation and experimentation will determine its appropriateness."
• RFC 3022 - Traditional IP Network Address Translator (Traditional NAT) - the update to RFC1631 lists a number of limitations as well.
• RFC 2993 - Architectural Implications of NAT - a very good document, well worth reading.
• RFC 1627 - Network 10 Considered Harmful (Some Practices Shouldn't be Codified)
• Deprecating Site Local Addresses - an IPv6 oriented document, discussing "site local" addresses, and the problems they cause. They are the equivalent of IPv4 RFC1918 addresses eg. Network 10. The same problems it discusses also occur with RFC1918 addresses.
• Things that NATs break - listed just for completeness.
• The Middleware Dilemma - NAT is a form of middleware, as it does more than just forward IP packets - it maintains state within the network (see RFC1958 for why maintaining state in the network is a problem).
• The Digital Imprimatur : How big brother and big media can put the Internet genie back in the bottle. - The Firewalled Consumer section discusses what NAT is doing to the Internet at a higher level.

Once you've read through these documents, at least to the point of having a basic understanding of them, go through the comment I'm responding to, and look for ways as to how some of your solutions can be better and much more simply achieved via public addressing and the removal of NAT.

I'm tempted to answer your points directly, however, I think it would be better to spend my time pointing you towards the following documents, which, firstly, describe the Internet architecture, and why it was designed the way it is, and secondly, describe how NAT / overlapping address spaces break the architecture. I don't think a debate on NAT can take place until both the design of the Internet and how NAT breaks that design are understood.

• RFC 1958 - Architectural Principles of the Internet - Section 2.3 "It is also generally felt that end-to-end functions can best be realised by end-to-end protocols." is the property that NAT breaks.
• RFC 1631 - The IP Network Address Translator (NAT) - even the original NAT RFC suggests limitations - from section 4. "Conclusions" - "NAT may be a good short term solution to the address depletion and scaling problems. This is because it requires very few changes and can be installed incrementally. NAT has several negative characteristics that make it inappropriate as a long term solution, and may make it inappropriate even as a short term solution. Only implementation and experimentation will determine its appropriateness."
• RFC 3022 - Traditional IP Network Address Translator (Traditional NAT) - the update to RFC1631 lists a number of limitations as well.
• RFC 2993 - Architectural Implications of NAT - a very good document, well worth reading.
• RFC 1627 - Network 10 Considered Harmful (Some Practices Shouldn't be Codified)
• Deprecating Site Local Addresses - an IPv6 oriented document, discussing "site local" addresses, and the problems they cause. They are the equivalent of IPv4 RFC1918 addresses eg. Network 10. The same problems it discusses also occur with RFC1918 addresses.
• Things that NATs break - listed just for completeness.
• The Middleware Dilemma - NAT is a form of middleware, as it does more than just forward IP packets - it maintains state within the network (see RFC1958 for why maintaining state in the network is a problem).
• The Digital Imprimatur : How big brother and big media can put the Internet genie back in the bottle. - The Firewalled Consumer section discusses what NAT is doing to the Internet at a higher level.

Once you've read through these documents, at least to the point of having a basic understanding of them, go through the comment I'm responding to, and look for ways as to how some of your solutions can be better and much more simply achieved via public addressing and the removal of NAT.

I'm tempted to answer your points directly, however, I think it would be better to spend my time pointing you towards the following documents, which, firstly, describe the Internet architecture, and why it was designed the way it is, and secondly, describe how NAT / overlapping address spaces break the architecture. I don't think a debate on NAT can take place until both the design of the Internet and how NAT breaks that design are understood.

• RFC 1958 - Architectural Principles of the Internet - Section 2.3 "It is also generally felt that end-to-end functions can best be realised by end-to-end protocols." is the property that NAT breaks.
• RFC 1631 - The IP Network Address Translator (NAT) - even the original NAT RFC suggests limitations - from section 4. "Conclusions" - "NAT may be a good short term solution to the address depletion and scaling problems. This is because it requires very few changes and can be installed incrementally. NAT has several negative characteristics that make it inappropriate as a long term solution, and may make it inappropriate even as a short term solution. Only implementation and experimentation will determine its appropriateness."
• RFC 3022 - Traditional IP Network Address Translator (Traditional NAT) - the update to RFC1631 lists a number of limitations as well.
• RFC 2993 - Architectural Implications of NAT - a very good document, well worth reading.
• RFC 1627 - Network 10 Considered Harmful (Some Practices Shouldn't be Codified)
• Deprecating Site Local Addresses - an IPv6 oriented document, discussing "site local" addresses, and the problems they cause. They are the equivalent of IPv4 RFC1918 addresses eg. Network 10. The same problems it discusses also occur with RFC1918 addresses.
• Things that NATs break - listed just for completeness.
• The Middleware Dilemma - NAT is a form of middleware, as it does more than just forward IP packets - it maintains state within the network (see RFC1958 for why maintaining state in the network is a problem).
• The Digital Imprimatur : How big brother and big media can put the Internet genie back in the bottle. - The Firewalled Consumer section discusses what NAT is doing to the Internet at a higher level.

Once you've read through these documents, at least to the point of having a basic understanding of them, go through the comment I'm responding to, and look for ways as to how some of your solutions can be better and much more simply achieved via public addressing and the removal of NAT.

I'm tempted to answer your points directly, however, I think it would be better to spend my time pointing you towards the following documents, which, firstly, describe the Internet architecture, and why it was designed the way it is, and secondly, describe how NAT / overlapping address spaces break the architecture. I don't think a debate on NAT can take place until both the design of the Internet and how NAT breaks that design are understood.

• RFC 1958 - Architectural Principles of the Internet - Section 2.3 "It is also generally felt that end-to-end functions can best be realised by end-to-end protocols." is the property that NAT breaks.
• RFC 1631 - The IP Network Address Translator (NAT) - even the original NAT RFC suggests limitations - from section 4. "Conclusions" - "NAT may be a good short term solution to the address depletion and scaling problems. This is because it requires very few changes and can be installed incrementally. NAT has several negative characteristics that make it inappropriate as a long term solution, and may make it inappropriate even as a short term solution. Only implementation and experimentation will determine its appropriateness."
• RFC 3022 - Traditional IP Network Address Translator (Traditional NAT) - the update to RFC1631 lists a number of limitations as well.
• RFC 2993 - Architectural Implications of NAT - a very good document, well worth reading.
• RFC 1627 - Network 10 Considered Harmful (Some Practices Shouldn't be Codified)
• Deprecating Site Local Addresses - an IPv6 oriented document, discussing "site local" addresses, and the problems they cause. They are the equivalent of IPv4 RFC1918 addresses eg. Network 10. The same problems it discusses also occur with RFC1918 addresses.
• Things that NATs break - listed just for completeness.
• The Middleware Dilemma - NAT is a form of middleware, as it does more than just forward IP packets - it maintains state within the network (see RFC1958 for why maintaining state in the network is a problem).
• The Digital Imprimatur : How big brother and big media can put the Internet genie back in the bottle. - The Firewalled Consumer section discusses what NAT is doing to the Internet at a higher level.

Once you've read through these documents, at least to the point of having a basic understanding of them, go through the comment I'm responding to, and look for ways as to how some of your solutions can be better and much more simply achieved via public addressing and the removal of NAT.

I'm tempted to answer your points directly, however, I think it would be better to spend my time pointing you towards the following documents, which, firstly, describe the Internet architecture, and why it was designed the way it is, and secondly, describe how NAT / overlapping address spaces break the architecture. I don't think a debate on NAT can take place until both the design of the Internet and how NAT breaks that design are understood.

• RFC 1958 - Architectural Principles of the Internet - Section 2.3 "It is also generally felt that end-to-end functions can best be realised by end-to-end protocols." is the property that NAT breaks.
• RFC 1631 - The IP Network Address Translator (NAT) - even the original NAT RFC suggests limitations - from section 4. "Conclusions" - "NAT may be a good short term solution to the address depletion and scaling problems. This is because it requires very few changes and can be installed incrementally. NAT has several negative characteristics that make it inappropriate as a long term solution, and may make it inappropriate even as a short term solution. Only implementation and experimentation will determine its appropriateness."
• RFC 3022 - Traditional IP Network Address Translator (Traditional NAT) - the update to RFC1631 lists a number of limitations as well.
• RFC 2993 - Architectural Implications of NAT - a very good document, well worth reading.
• RFC 1627 - Network 10 Considered Harmful (Some Practices Shouldn't be Codified)
• Deprecating Site Local Addresses - an IPv6 oriented document, discussing "site local" addresses, and the problems they cause. They are the equivalent of IPv4 RFC1918 addresses eg. Network 10. The same problems it discusses also occur with RFC1918 addresses.
• Things that NATs break - listed just for completeness.
• The Middleware Dilemma - NAT is a form of middleware, as it does more than just forward IP packets - it maintains state within the network (see RFC1958 for why maintaining state in the network is a problem).
• The Digital Imprimatur : How big brother and big media can put the Internet genie back in the bottle. - The Firewalled Consumer section discusses what NAT is doing to the Internet at a higher level.

Once you've read through these documents, at least to the point of having a basic understanding of them, go through the comment I'm responding to, and look for ways as to how some of your solutions can be better and much more simply achieved via public addressing and the removal of NAT.