Arguments that the latter breaks the IP
model are simply arguments that the IP model is broken for today's
Internet and will be even more broken for tomorrow's.
those two statements aren't equivalent. the fact that people want
to break the IP model may mean that it's easier (at least initially)
to deploy a broken solution than to deploy a technically sound one
(just like it's easier to dump your toxic waste in the local stream
than it is to clean it up)
but the fact that IP doesn't do everything that people want doesn't
mean that the IP model is broken, any more than the stream is broken
because it doesn't solve your waste disposal problem.
some approaches to solving problems seem simple at first but
really are a lot more complex than they look.
NATs seem like a simple solution to address exhaustion...until
you figure in the additional complexity of application-level
gateways inside the NAT, and of the additional code that ends
up in applications that try to work around the problems caused
by NATs, and (in some cases) of the additional middleware that
you need to deploy to solve those problems. with enough work
you can get around most of the problems that NATs cause, but
it would have been a lot simpler, more efficient, more flexible,
and more reliable if you had just solved the address space
problem in a sane way. (and regardless of what some folks think
about IPv6, it's a LOT saner than NAT). and in addition to the
complexity and increased operating costs and reduced reliability
etc. required by those workarounds, you also end up with an
increased effort requried to deploy new applications (e.g. IP
telephony).
interception proxies seem like a simple solution to automatic
location of services, until you figure in the additional complexity
(of things like NECP) required to make them work in something
resembling the fashion that the applications expect, and the
additional complexity of things (like IPsec) that applications and
services need to do to defeat interception proxies that get in
their way.
similar arguments apply to content-modifying firewalls and
probably apply to traffic shaping.
it's completely natural that people will try such approaches -
they are trying to address real problems and they want quick
solutions to those problems. but if the quick fix solutions
get entrenched then they cause their own set of problems which
are worse then the original problems. this is not progress.
IMHO we need to see these things for what they are:
- quick fixes with limited applicability and future
- indicators that there is an important problem that needs to be
solved in a technically sound fashion
Keith