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

[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.

From here, you can make a few different choices.  You can get two
IPv6 /64 networks and assign each one to the two networks.  You can get
a single /48 (which I suspect businesses will probably have anyway since
they will want separate logical networks for some things) network and
subnet it for the two networks (or subnet it and then subnet it again,
or whatever; subnetting is similar to CIDR subnetting for IPv4).  You
could use the (admittedly depreciated, but still valid) IPv6 site-local
addresses to tie them together as a single network, and then can set up
two link-local networks and just leave it at that for now, until you get
more things done in preparation for an overall move to IPv6 and allocate
public addresses to advertise.

If you do none of this at the time of processing the acquisition, then
what will you do?  Either merge the networks into one large subnetted
beast, which may require renumbering, or tie them together with an
intermediary machine functioning as an address-translating bridge of
sorts.  Then, later, you'll wind up doing one of the above things,
_anyway_, and duplicating a lot of the work that went into the initial
setup of the network to begin with, because you'll have to treat it as a
project all on its own.  How is this saving any money, time, or work?

> I think the main issue here is the fact that we look at things from  
> two totally different viewpoints. You've already changed over to ip6  
> and are anxious for everyone else to follow suit, whereas I look at  
> things from the viewpoint of what I have to deal with at work every  
> day. I'll give you absolutely no dispute that ip6 solves quite a few  
> problems. But unfortunately, it's not as simple as logging into my  
> routers, typing
> 
> config t
> ip 6 enable
> 
> And having everything magically work. So sure, having to NAT your  
> acquisitions traffic because they're using the same local range  
> becomes unnecessary in ip6. But the amount of private companies  
> running ip6 aren't exactly pre-dominant. So your point is germane from  
> an academic standpoint, but from an every day one, it sounds alot like  
> the guy in the back saying 'I told you so' to his peers (when it's  
> probably management who shot the ip6 conversion down in the first  
> place) instead of pitching in to help with the consolidation

Management should have nothing to do with technical details.  If they
do, it's the IT department's fault for operating in such a way as to
give management the idea that they can dictate things that are totally
unrelated to business functions (unless they're in the network business,
and then, well, they ought to have been there before anyone else,
anyway, in the interest of knowledge and experience, and that's just a
sad company if they're not).  Management belongs to the business, and IT
does what is necessary to make the things that management wants to do,
possible.  That's the way it is.  I've said it more than a few times,
and I'll say it again:  IT's job is to maintain things, such as the
network.  IPv6 was (and still is) deployable in the course of routine
maintenance---which, IT departments are already funded to do, because
that's their *job*.  So then, why aren't they doing their job?

("I was just following orders" is an invalid response, too.  It just
means that both the management *and* the IT department need to be
replaced, not just one or the other.)

> That depends on what you consider a commodity router. I picked up some  
> 3640's fully loaded with ram and flash for quite cheap, and have them  
> deployed at the edge and core of my home network, so FTP and IPSec  
> aren't issues, though I haven't tried SIP yet.

How do you get IPsec through a NAT at all?  I know of no ALG that can do
it, because then the payload and the packet header no longer match up.
That's why IPsec is always tunneled through something like UDP.  You
_could_, in theory, route IPsec through a NAT if you opt not to use AH
support, but that simply reduces the amount of security that IPsec
provides (AH provides a hash of the packet, and that hash cannot be
easily recomputed by Mallory or any other intermediary without the keys,
so it prevents modification or covert replacement of the packet).

> Honestly, the fact that the wal-mart routers don't support the work- 
> arounds isn't NAT's fault. It's Belkin's, and Netgear's, and Cisco's  
> for trying to be cheap by assuming the folks who are going to buy  
> those routers won't have any need to get the advanced protocols around  
> NAT.

ALGs are kludgy at best, and ugly, brutal hacks at the norm.  SIP, for
the most part, "just works" when there is end-to-end communication
between the peers.  Start introducing the latency required by ALGs (some
of which have to, by necessity, use lots of processing power and need to
be a dedicated dæmon), and the complexity of the routing between hosts,
and you begin to have issues, particularly with something like SIP.  I
don't know of any embedded router that I would 

> > the IPv6 Internet will start becoming larger very soon.  Tunnels may  
> > be
> > all that is available now, but Comcast is already using IPv6  
> > internally
> > for the management of some of their CPE as of May 2007 [1].
> 
> I'd imagine Comcast would have to, they're still working on the  
> consolidation of their network, and from what I've heard and seen from  
> my own service, they're having issue. At the rate they buy people, I  
> can just imagine what a balancing act it is to keep it all working.

That is certainly part of the issues that people have in the areas where
Comcast has just acquired the previous provider.  I haven't had any
issues with my service outside of an outage or two provoked by weather
in a while.  

> As far as the adoption relatively soon.... I think five years is  
> highly optimistic. Ten years may be a little more likely. Basically,  
> ip6 isn't going to get implemented until the ip4 space runs out. And  
> when that happens, the companies who are holding on to large swaths of  
> unused blocks are going to make a killing, as the demand for new IP  
> blocks reaches an all time high. Finally, when it reaches a point  
> where it'd be more cost effective to adopt ip6 than continue buying  
> ip4 blocks, that's when ip6 will start seeing widespread adoption.

Well, I suppose you're probably right---we here in the U.S. are behind
in just about everything, it's only appropriate that we stay there, eh?
At least the guys that designed the network used in the Olympics for
this year have the idea.

From what I've heard, ISPs in Finland and other countries have the right
idea, too.  China has had large amounts of IPv6 deployed since 2004.
Asia uses it, Australia has native IPv6 providers too.

There are lots of entities getting tunnels, as well.  At least through
Hurricane Electric, there have been 674 signups in the last 20 days [1].

What's our excuse?

> That's a pretty easy question to answer: Money.
> 
> Right now, there's no need to screw with the status quo. (from the  
> viewpoint of the folks who are making the money). So you keep selling  
> what you're selling, let the panic begin, then announce that you have  
> this wonderful new fully ip6 supportive product so you can sell them  
> the same thing again.
> 
> The cynic in me believes the Tier 1's are just waiting until they've  
> decided they can't bleed the turnip anymore before they decide 'Ok,  
> time to go to ip6'.
> 
> Last year, O'Reilly put out a wonderful book called Network Warrior  
> (for anyone who's new to the network field, I suggest picking it up...  
> it's a wonderful brain dump of a guy who's been doing network admin  
> for a very long time, and full of useful little tricks). It is my  
> sincere belief that the chapter on dealing with upper management  
> should be required reading for anyone who works in a corporate IT  
> environment, whether you're involved with netops or not.
> 
> In that chapter, he tosses around a few maxim's, the first of which  
> has stuck with me ever since I read it -
> 
> Network designs are based on Politics, Money, and The Right Way To Do  
> It - in that order.
> 
> That one sentence is a perfectly succinct  explanation of why the  
> adoption of ip6 has been so slow, and why it'll be a bit slower in  
> coming.

... and reaffirms everything I've believed about management all along.
McConnell [Code Complete, 2 ed., § 28.6, "Managing Your Manager"], has
similar words of advice regarding managers:  "Technically competent,
technically current managers are rare.  If you work for one, do whatever
you can to keep your job.  It's an unusual treat.  If your manager is
more typical, you're faced with the unenviable task of managing your
manager.  'Managing your manager' means that you need to tell your
manager what to do rather than the other way around.  The trick is to do
it in a way that allows your manager to continue believing that you are
the one being managed."

He then goes on to talk about some methods on just how to do that,
including educating the manager.

> I'm actually trying to get the folks at work to put in a request for  
> an ip6 allocation so I can play with it on our sandbox segment. We're  
> already eating up a /18 and a couple /20's, but I'd at least like to  
> get to work on an ip6 implementation so we can do it right when the  
> time comes.

Just get an IPv6 tunnel from Hurricane Electric or another provider and
set that up for temporary use.  It's free to use, and you can get both a
routed /64 and a routed /48 from them (so you can experiment with
networking in various configurations and experiment with managing
subnetworks, too, while getting things situated).  The only thing that
you'll then have to do when you're ready to put IPv6 up "for real",
using the company's own assigned IPv6 addresses, is to renumber the
networks and stop using the tunnel (or, continue to use the tunnel for a
little while and transition over to the native IPv6 numbers, if you
want).  I use HE, and I am quite happy with the reliability of it.  I
had tried SixXS in the past, and had issues keeping their tunnel up.

> > I'd absolutely _hate_ to be double-NATed.  One NAT---the router
> > that I have here---I can work around.  Two?  One here, and one at the
> > ISP?  That's much harder to work around.  Of course, that'd be one way
> > that the ISP could save money, using one NAT at each node.  But it'd  
> > not be worth it.
> 
> That's actually my biggest worry. If Comcast ever starts handing out  
> RFC 1918's via dhcp instead of real IP's, I'll move to another  
> provider in a heartbeat. I think Bellsouth started that crap down in  
> Florida at one point, but the outcry caused them to reconsider.

Yeah.  IPv4 providers in really dense areas or with really high
subscriber counts have been known to do that when they don't have enough
addresses in their pool to serve them all.  Not only does it introduce
the possibility that the ISP will somehow conflict with the customer's
network (think about what would happen if the ISP gives 192.168.0.1 to
someone as an IP address, and their own private network is
192.168.0/24).  Not good.

> > As things stand today, there are 38 /8 blocks that are unallocated  
> > [2].
> > The estimates that I have seen estimate the exhaustion of the IPv4
> > address space in anywhere from two years to four years, depending on  
> > the
> > level of allocation that the exhaustion is being estimated for.
> 
> Oh, you should subscribe to the NANOG mailing list. The predictions  
> are much more dire than that :)

I don't doubt it.  There are paranoids and fanatics in every field.  :-)
There are some people that I know of that seriously think "Oh, we'll
never run out," too.

> >  It's
> > time for ISPs to saddle up and get ready to deploy, and work with
> > vendors to ensure that the hardware being sold will work properly.
> 
> Honestly, you can't blame the vendors for this one (at least not in  
> their enterprise hardware). Cisco and Juniper have had ip6 support for  
> a very long time now, so they did their part. The ISP's need to be  
> yelling at their peers and the people they purchase transit from to  
> get the ball in motion, those are the folks who are really holding the  
> show up.

Part of the process can be organic---and in fact, will be.  After all,
*someone* controls various pieces of the Internet.  If Comcast starts
doing IPv6, for example, then the people downstream from them (such as
myself) will have IPv6 service.  Then, not only is there a bit of
pressure put on other ISPs to get IPv6 going, but there is a large
implementation of it.  There is also pressure on the vendors if that
happens---after all, Comcast isn't exactly a small ISP, and nobody would
want to be known as "the company whose routers won't work with Comcast".

Hrm.  Big business can be useful sometimes, I suppose.

> 
> > There will almost certainly be a period of chaos that everyone will
> > remember during the transition, but that's life, and life cannot  
> > always
> > be made nice and insulated.
> 
> Honestly, I think it'll be like Y2K. All the unnecessary build up and  
> then .... poof. One day your dhcp lease will refresh and you'll have  
> an ip6 IP instead of ip4 and things will just work.


Assuming that we wait for there to be no more IPv4-only hardware, sure.
But that will be a long time.  The catalyst for people getting rid of
IPv4-only hardware will be the lack of availability of IPv4 itself,
whether that is caused by people stopping native IPv4 services, or by
actually running out of IPv4 address space altogether.  But one thing is
for sure:  additional software is required before IPv6 will happen, be
that software on the client workstation, or in the firmware of the CPE
that ISPs use to grant access to their network to subscribers.  I
honestly don't know how the process of an ISP assigning a /64 to a user
would work, precisely, but I am sure that it requires an IPv6-specific
service of one sort or another on the client, be that in the network
stack or running as an extra program (like a DHCP client would).

(Which reminds me, I either need to modify my desk phone's firmware,
find modified firmware, or get a new desk phone---it's the only device
in my apartment on the network that is IPv4-only at this point.

	--- Mike

[1] http://tunnelbroker.net/usage/accounts_last_20.php

-- 
My sigfile ran away and is on hiatus.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20080814/b24ad94e/attachment.bin