[arin-ppml] IPV4 allocations
McNutt, Justin M.
McNuttJ at missouri.edu
Sat Jan 3 22:30:11 EST 2009
Our "look way ahead into the future" IT people are thinking about taking
it even further. They predict a day when we'll throw away the firewalls
for the same reason we threw away NAT: They break two-way applications.
Their argument - and it seems pretty sound to me - is that we only
installed firewalls because at one time, the end stations were mostly
incapable of defending themselves from malicious traffic from the
Internet. This forced the client-server model onto a lot of apps, but
it wasn't that painful, since at the time, most two-way apps were
internal (and poorly-secured) things anyway.
Three things have changed since then. First, host security has improved
*somewhat*. Windows works pretty hard to make you leave the firewall
turned on and apply patches. Second, two-way apps between hosts at
different enterprises are much more common. Third, for those people who
turned off the firewall and BITS and the internal nagware reminding you
to patch your system, there are intrusion prevention systems nowadays
that can sit in-line on the network the way firewalls do. The IPS can
drop just the attack traffic, rather than just dropping everything from
the outside. (Some IPS devices can "quarantine" inside or outside hosts
that do susicious things, like port scanning and so on.)
Basically, they predict a more "innocent until proven guilty" model for
the network, since it allows for much better communication, and that's
what the network was *built* for. How about DEM apples? IPS replaces
firewall and two-way apps work again.
It's merely tangential to this discussion, but the above serves to
underline just how committed we are to a direction opposite of NAT. To
us, NAT is something you do when you want to hide what you're doing or
when your upstream provider won't give you more IP space. It's
something you *have* to do, not something you ever *want* to do (for any
I was dismayed to find out that NAT is still possible in IPv6, though
pleased that it breaks enough things that it will, perhaps, be deemed
unusable enough that it is never widely used.
> -----Original Message-----
> From: arin-ppml-bounces at arin.net
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Matthew Petach
> Sent: Saturday, January 03, 2009 8:47 PM
> To: eBoundHost: Artur
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] IPV4 allocations
> On 1/3/09, eBoundHost: Artur <artur at eboundhost.com> wrote:
> > How many IPs in use today are used for people connecting to
> the net vs
> > servers?
> Well, I've been trying to assign an IP address to my brother for years
> now, but it still hasn't stuck yet; so, unless you're a bit
> further along
> in your bioengineering, I imagine 100% of the IP addresses in use are
> used by computer-type devices, and not by people. :P
> Now, many of those computer-type devices may happen to be used
> more interactively by humans, while others may be less interactively
> engaged by humans; but fundamentally, every IP in use is used by a
> computer-type device (network gear, etc. and other special-purpose
> gear fall under that same ruberic of "computer-type device").
> Fundamentally, we can't really distinguish among the various
> computer-type devices to be able to say "oh, this category or
> subset is fine to NAT, but these others aren't" at the ISP level.
> Applications today are becoming more and more highly interactive,
> with information flowing bidirectionally on multiple ports. Even as
> an end user at home running NAT, I'm finding the number of NAT
> rules and ACL openings that have to be allowed is increasing over
> time, as embedded gtalk, jabber, YIM, AIM, and other seemingly
> end-user applications start to need more and more bidirectional
> connectivity between them. Trying to stave off the IPv4 runout
> by arbitrarily trying to draw lines between computer-type devices
> that are allowed to engage in bidirectional end-to-end communication
> vs those that must sit behind a NAT and can only engage in
> unidirectional communication is a dead-end course; we'd be
> better off focusing our energies on paths likely to lead to
> positive outcomes.
> > Best Regards,
> > Artur
> > eBoundHost.com
> > http://www.eboundhost.com
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML