[ale] Looking for advise on domain names and other info wrt local network.

[mike at trausch.us (Michael B. Trausch)]

Of course, there is lots of snipping in here...

On Wed, 2008-08-13 at 07:37 -0400, Forsaken wrote:
> On Aug 11, 2008, at 2:00 PM, Michael B. Trausch wrote:
> > I fail to see how you connect "NAT seriously ought to go away  
> > because it
> > is a bad feature that breaks the philosophy behind open end-to-end
> > network communication" with "So, features on the network stack are  
> > bad?"
> 
> The connection was along the lines of countering your arguement that  
> NAT goes against how the internet was designed. I was merely pointing  
> out that there are a few other things that have been developed that  
> were either not within the design parameters or totally changing the  
> design parameters, and yet they're deemed essential for operation. So  
> opposing something on the basis that it's not how things were designed  
> just doesn't sit well with me.

Perhaps I can clear it up a little bit better, then.  I am opposed to
adding functionality to something that has the net cost of reducing
functionality.

Adding CIDR to the network stack increases the available things that can
be done, since it enabled smaller networks to be created.  It did not
prevent anyone from doing anything that they could do in pre-CIDR days,
and so it was a good feature.

Adding NAT to routers and using that and RFC1918 networks, however,
_decreased_ the available things that can be done.  Yes, it enabled a
higher quantity of machines to be present on the Internet (though they
all looked like a single machine), but it also broke a lot of things.
With the introduction of NAT, no longer were machines on the Internet
truly peers.  Only non-NATted machines are peers with other machines on
the Internet.  This means that you can't expect two-way communication to
be _possible_ all of the time.  This is a definite loss in
functionality---functionality which is important.  Without NAT, two-way
communication can be prevented, but if it is, it's because that is
_precisely_ what is desired for _that_ company's network.  Not because
NAT is present and prevents it all on its own.  I _hate_ that I have
always had to use NAT.  I don't want no stinking RFC1918 network.  I
have *never* wanted one.  The same is true when I am working somewhere.
In fact, the largest company I have ever worked for didn't use RFC1918
addressing on their network at all.  They _still_ use globally-routable
IP addresses for all of the machines on their network, and use packet
filtering to manage the flow of information at their external network
boundary.  Exactly the way it should be (and this will make their
eventual transition to IPv6 easier, when they go on and do it).

> > I have a problem with NAT because it breaks end-to-end  
> > communication.  I
> > have a problem with proposed "features" that actually take usable
> > features away from the network stack, too.
> 
> Let's be frank, end-to-end communication has been broken, on purpose,  
> for awhile. For most enterprise class networks, you do not *want* end- 
> to-end communication between your network nodes and the internet  
> (There are enough Windows zombies out there already, aye?) In my  
> honest opinion, the design of end-to-end connectivity got tossed by  
> the wayside when firewalls became the norm. Having a machine or  
> machines interposed between the two end points that specifically  
> decide what traffic is or isn't allowed to cross the link is a pretty  
> big boot on the neck of end-to-end connectivity. I've always equated a  
> firewall to trying to have a raunchy phone conversation with your  
> girlfriend when or both of your parents are listening in on the line.  
> The results aren't always what you'd like.

Yes, there are more than enough Windows zombies out there.  But, the
solution is not to make the network protect this stupidly insecure
operating system.  There are two correct solutions to this problem in a
corporate network:

 * Kick Windows out.
 * Lobby Microsoft to make Windows actually secure.

The only one of those that is possible is the first one.  Microsoft will
never make Windows secure, because then where would their revenue stream
go?  They make money by taking calculated risks with the networks of
people that trust them to do their job correctly.  Add to the mix that
you cannot audit the whole of Windows for issues, and you've got an
unknown element on your network.  It's no surprise that such machines
easily become zombies.  But, most people do not think it's a large
enough issue to warrant doing anything about it---so, they still run
Windows.  Whatever, that's not my problem so why should I have to be
constricted because of it?  I certainly recognize that not everyone
wants to learn a new system.  Most people don't want to learn anything
about their computer.  Why would they bother to learn about what an
operating system is so that they can learn that they're able to switch?
Most of the people that I know only wanted to switch after they saw me
run it.  Talking to them about it was meaningless, except to mention how
rarely I actually have to reboot.  It seems that most people don't care
about security issues in their operating system.

> > The change from class-based routing to CIDR was a good move.  It was
> > sound and required no breakage of networking functionality already
> > present in the stack.
> 
> No, it just broke some routing protocols and required them to be re- 
> worked. No big deal. ;)

CIDR was introduced at nearly the same time as NAT (CIDR was introduced
in RFC 1519 in September 1993, and NAT was introduced in RFC 1631 in
May, 1994).  RFC 1519 [CIDR] obsoleted RFC 1338 from June 1992.  The
documents are verbose, as are nearly all of the RFCs that I have read,
but the changes were, as I understand them, relatively simple changes to
the IP layer of the network stack.

IPv6, RFC 2460, was specified in September 1998 (RFC 2460 obsoleted RFC
1883, from December 1995).  The changes that were made to IPv4 added
many years to IPv4's useful life, which were intended to be used as a
transition period.  IPv6 will be 13 years old in December, 2008.  What's
more, the protocol was designed to be rolled out over a long period of
time as part of the day-to-day maintenance of networks.  Disruption
outside of normal maintenance would not have been necessary to implement
IPv6 if companies didn't procrastinate until the last minute to get it
done.

And if companies procrastinated because of management, then you know
what?  The IT department is stupid for permitting management to step
outside of their boundaries as a business driver, and management is
stupid for dictating to IT how to do their job.  The whole lot of them
need replaced.  That won't happen, of course, because our society is far
too forgiving and has far too many apologetics in it for such a
pragmatic action to occur.  I say that because in this hypothetical
situation, neither management nor the IT department are working in the
best interests of the company, and that makes them worthless.

> Yeah, I know, but I don't think the folks with RFC1918 networks are  
> going to negotiate a changeover to ipv6 before one acquires the other  
> to make their network consolidation easier. And yes, this is a very  
> very real benefit of NAT, mergers and acquisitions happen all the time.

I can't help but wonder if there is something you're driving at here.
You have mentioned this point over and over again---and yet I must still
be missing something.  There's no benefit to NAT here that I can see.
However, since it seems to be your favorite example to throw out here,
let's use it in an example scenario.

Two decently-sized companies merge, and have to spend money to integrate
their network infrastructures.  Your solution---to tie them together
with IPv4 NAT---is shortsighted both fiscally and logically.  The cost
of this route is shorter in short-term time and money investment, but it
is higher in long-term time and money investment.  Why?

Well, since the infrastructure has to be built to tie the two networks
together in the _first_ place, why should that infrastructure ignore
IPv6?  So, push out configuration changes to enable IPv6 on both
networks.  Build the infrastructure to link the two to carry both IPv6
and IPv4.