breaking the IP model (or not)

[Keith Moore <moore at cs.utk.edu>]

> 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