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

[Michael H. Warfield]

On Mon, 2008-08-11 at 05:03 -0400, Forsaken wrote:
> On Mon, 11 Aug 2008 00:28:23 -0400
> "Michael B. Trausch" <mike at trausch.us> wrote:
> > I must have missed the short bus somewhere here.

> Now was that really called for? Or are you one of those folks who have
> to have an arguement rather than a discussion?

> > NAT doesn't enhance communication, it _breaks_ it.  The Internet was
> > designed for things to be end-to-end.  Protocols that depend on the
> > end-to-end functionality of the Internet break without some nasty
> > middleware between the client and server (or two peers) working to
> > rewrite packets. 

> It's a matter of perspective. No matter which way you slice it, NAT
> does allow more machines to talk to each other than would otherwise be
> able to. I'm well aware of how ugly of a hack it is, I have the
> equivalent of a small enterprise network running behind my little
> comcast IP, and I've had to deal with all the work arounds to make
> services available to the outside world. 

	I have to agree with Mike here.  Whether or not NAT lets MORE devices
communicate, it's not "enhancing communications".  That's a subtle
different in meaning but an important one.  Communications between
arbitrary devices with arbitrary protocols is extremely difficult when
NAT is involved.  Just read up on the STUN ("Simple" Translation of UDP
over NAT) and TEREDO protocols to appreciate just how difficult this is.

> And sure, the internet was designed to be end to end. ipv4 was also
> designed to be classful. Do you think that was a good idea too? The
> wasteful allocation of the ip4 space before the implementation of CIDR
> is mostly responsible for the ip crunch that we're in right now.

	Actually, that's largely open to debate.  Another serious problem is in
the routing tables and the fact that the routing tables are expanding
faster than the router memories.  And we would still be out of addresses
with or without having started with the old classful system.  The
classful system allowed for subneting and superneting (aggregation),
CIDR formalized that an institutionalized that and formally deprecated
the old classful nominclature.

> On the
> other hand, I suppose you could say NAT is largely responsible for the
> long delay in ipv6 implementation. 

	Partially.  Chicken and egg situation.

> > IPv6 is designed to last for a long time, and it's expected that it
> > will have to be replaced, too.  Given that there is 128 bits worth of
> > address space in there, though, and that is broken down into network
> > names of at most 64 bits, it's expected to last for a while.  It'll
> > be around for a very long time if we never leave the planet, since if
> > we had that many people and that many machines, we'd probably not
> > have the resources to sustain it all---after all, we don't have the
> > resources to sustain life indefinitely as it is, with the numbers we
> > have now.

> *shrug* and 640K ought to be enough for anyone. Not trying to be cute
> or sarcastic (well, not much) but the computer industy has found out
> time and again that what you think is enough for future growth turns
> out to be quite different when the future gets here. 

	I hope you appreciate the magnitude of the numbers here.  I remember
someone saying that if all the stars in this galaxy had one planet like
earth with the same population as the earth and you gave each person a
cell phone, you'd have enough addresses to give each cell phone a block
of addresses and still not run out.  I've never run those numbers down
but a single IPv6 subnet has 4 billion times as many addresses as the
entire IPv4 internet and each IPv6 network has 65,536 of those subnets.
There are other limits of scale (like the speed of light) which will
kick in long before those addresses become a problem.

> > And, I'm totally lost on the benefit of NAT when merging two networks
> > that are the same non-routable address block.  If I have two networks
> > that are 10.0.0.0/8 and I am merging them together, there's going to
> > be a lot of collisions, and likely a lot of renumbering.

> Well there will certainly be alot of renumbering, but if you stick a
> NAT box between them, they can at least talk to each other until things
> are consolidated. It's pretty darned useful, since the majority of
> folks who allocate RFC1918 space for their corporate networks seem
> hellbent on starting at the bottom of the range.

	When each is behind their own NAT box, they can not talk to each other
without some other protocol, such as STUN, and some intermediary.  If
they are symmetrical NAT boxes, you're screwed, even then.  You can talk
to servers out on common addresses but you can not, without a lot of
difficulty, talk directly to each other.

	It's interesting that Comcast had to deploy IPv6 internally to manage
their cable modems and settop boxes.  They did a presentation on this
several years ago at NANOG.  Basically, they ran out of address space
internally.  They exhausted all of the private address space and NAT was
not a lick of help for that without some nightmarish hacks.

> > I've used IPv4 for all of my life, and most of the time that I have
> > been using it, NAT has been around.  I'd like to say that I remember
> > the days before NAT with absolute clarity, but to be honest, I was a
> > dialup user then and fairly new to networking.  But, ever since I ran
> > into my first NAT, I was really unhappy with the way Internet access
> > worked through it.  I've wanted to see it go away ever since I ran
> > into it, really. 

> Again, it's a matter of perspective. For folks that just need internet
> access, NAT makes things easy. When you need to setup IPSec tunnels, it
> makes life hard. 

	There are many many things that NAT makes hard.  Only simple protocols
work and lots of protocols just fall down go boom without a lot of work.
SIP doesn't work around NAT without STUN.  You can't run a server behind
it unless you punch in some mapping holes.  "For folks that just need
internet access" is imprecise.  What you really mean is "For folks that
just need web, mail and other simple client access"...  NAT does not
make things easier.  Just try and fix things when they break and you
can't figure out why.  It works for the simple things, most of the
time. 

> Please understand that I'm not praising the wonderfulness of NAT and how
> it makes life better. I'm a pragmatist. Like any other service, NAT has
> it's good points and it has it's problems. I'd love it if Comcast would
> give me a /29 (and a full BGP feed, but I'm sick like that) for my
> home network. But since this is the company that blocks even *incoming*
> port 25, I'm skeptical of whether they would even if we weren't in an
> IP crunch. Unfortunately, I don't think widespread ipv6 adoption is
> going to happen anytime soon. 

> Last I looked, only 4 of the tier 1 providers are offering ip6, and one
> of them are only offering tunnels. So like it or not, NAT is a fact of
> life in the network world for the forseeable future. If you want an ISP
> that's generous with it's bandwidth and not overbearing with it's
> policies, you'll have to leave the country to find one.

	There is no location anywhere on the Internet where I have not been
able to get at IPv6.  I've even accessed it from two cruise ships at
sea.  I've used it on networks where I could not even pull down an IPv4
address (crashed dhcp servers or conflicting servers).

	Yes, I have available a variety of tunneling mechanism for when it's
not available "native" (for some value of "native") but that's all you
ever have anyways.  PPP is nothing but a tunneling mechanism.  PPPOE is
nothing more than PPP tunneled over Ethernet.  So you end up with tcp
tunneled over ip tunneled over PPP tunneled over ethernet tunneled over
the ATM fiber link layer to your DSL provider.  Your cablemodems are
performing tunneling.  You just don't recognize it because you're merely
looking at the end point.  This is fundamental to layered architectures.
It's no different than any VPN.  Tunneling is nothing more than
encapsulation and routine with none of the translation headstands
inherent in NAT.  IPv6 in a SIT tunnel is more "native" than RFC1918
addresses mapped through NATS.  The former adds a layer to the stack of
protocols and the other violates a layer (or two).

	Interesting little side issue too (to illustrate some of the evils of
NAT).  The latest DNS kerfluffle coming out of BlackHat is impacted by
NAT.  Even if you update your nameservers to the latest patches, many
NAT devices still leave you vulnerable.  Some NAT devices leave the
source port alone, when possible.  Some NAT devices (OpenBSD) choose
random ports to translate to (Linux has this feature if you use the
--random option on the iptables rule with a recent kernel).  Some NAT
devices (the bad ones) translate the source port into a predictable port
number, generally a fixed port and incremented from there.  The result
is that, even if you have a good nameserver that's issuing queries from
truly random ports, the NAT box is undoing the randomness of the source
port and destroying that 16 bits of entropy.  So even a patched
nameserver is vulnerable if it's behind one of these NAT devices.

	Yes, NAT is a fact of life for the foreseeable future.  So is AIDS and
Ebola.

	Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20080811/777dd2d6/attachment.bin