[clug] IPv6 Australia?

Robert Edwards bob at cs.anu.edu.au
Tue Jul 29 02:18:53 GMT 2008

Daniel Rose wrote:
> It is a hack to allow RFC1918-type hosts access to the Internet.  It's 
> not come about by design, it wasn't meant to work that way.  It's not 
> pure! It violates the peer-to-peer nature of the open Internet!

(Bob playing the IPv6-skeptic again)
Note that the peer-to-peer design of the open Internet came about in
an age when there were no personal computers, laptops, PDAs, mobile
devices etc. etc. All Internet nodes were multiuser minicomputers or
mainframes and generally administered by specialists who wanted the
Internet to work and so there were no "bad guys".  This then lead on
to the appallingly poor security design of the Internet (IPv4, in
any case).

I sometimes like to pose the question: how different is a NAT router
with a bunch of client-only devices behind it to a 1970s multi-user
minicomputer or mainframe with a bunch of X-terminals or VT-100s
connected to it? In both cases you are sharing a single IPv4 address
with other users. In both cases, usually a sys-admin needs to set up
a new "listening" service (on the low numbered ports, in any case).
In both cases, there is no "peer-to-peer" relationship with external
(public) IP addresses and the actual terminal being used.

A more recent (1990s) example is a SunRay server with a bunch of
SunRay terminals behind it on their own RFC1918 network (no routing
or NAT, but many web-users sharing a single IPv4 address).

> It wastes CPU cycles.  It makes it harder for external people to get 
> information about a host.  It means that one "Natted" user can get the 
> public IP blacklisted and cause trouble for their peers.
> It allows lazy networkers to make new netblocks every time they think 
> they need one, leading to cascading NATs and messy networks.
> That's about all I have.  These aren't strong, practical reasons why NAT 
> is bad.  I think NAT deployed by an ISP would be a problem, certainly 
> for many of us it would be, but overall I can't see a strong practical 
> reason why NAT should be shunned, I just know that it feels wrong!

I certainly agree that having ISPs using NAT would be a big problem. As
there is no scarcity of IPv4 addresses yet (there are still lots of
Class Cs waiting to be allocated) there is no reason for any ISP to
start using NAT. If my ISP were to, I would take my business elsewhere.

Until IPv6 solve some fundamental problems (like reverse DNS etc.) then
I think that IPv4 and NAT are here for a long while yet, and people
should just get used to the idea that services shouldn't be expected to
work on a peer-to-peer basis, so only write/use protocols that do work
client-server (all my favourite protocols work fine as client-server,
but then I don't play games and I'm not beholden to SIP-based VoIP yet).

And, in response to a suggestion posted by someone yesterday that I
might be confusing NAT with a stateful firewall, I am not. I know that
NAT is stateful but not, by itself, a firewall. However, the only
alternative in IPv6 to some of the protection that NAT offers is to
setup a stateful firewall on your incoming router.

I further humbly suggest that the CPU cycles required to process the
longer addresses used in this stateful firewall would exceed the CPU
cycles required to implement NAT on an IPv4 router. Not to mention the
memory requirements, but RAM is cheap, right?


Bob Edwards.

More information about the linux mailing list