Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Eric Rescorla writes:
 > I said I was done with this discussion, but I think Melinda
 > deserves a response here.
 > 
 > Melinda Shore <mshore@cisco.com> writes:
 > 
 > > > I'm not sure what you mean by routing above. Are you suggesting there's
 > > > some negative externality in that NAT makes the routing infrastructure
 > > > more complicated? If so, what is it?
 > > 
 > > If you're multihomed and your route changes, your address
 > > changes.  (Yes, this happens).
 > Agreed.
 > 
 > > I am profoundly weirded out by reading an IAB member argue
 > > that something that's got broad market acceptance is
 > > tautologically okay.  I agree that there's a real problem
 > > here that NAT is trying to solve, but I certainly wouldn't
 > > treat it as a given that NAT is the best, or even a good,
 > > solution.  
 > I can understand how this would bother you, and I think
 > part of the problem is that I haven't been writing as clearly
 > as I could have. A series of e-mail replies isn't a good
 > way to elucidate your position.
 > 
 > Here's what I mean to be arguing:
 > 
 > (1) There are some set of problems that users have or
 >     believe they have.
 > 
 > (2) NAT solves at least some of those problems, at some
 >     cost (say Cn), both financial and operational and
 >     that solution has benefit Bn.
 > 
 > (3) The fact that a large number of people have chosen
 >     to use NAT is a strong argument that B>C. (Here's
 >     where the invocation of revealed preference comes in).
 > 
 > (4) It may well be the case that some other solution S
 >     would have some other costs Cs and benefit Bs such
 >     that (Bs - Cs) > (Bn - Cn). It may be that S doesn't
 >     exist yet, in which case it would be good for us
 >     to design and build it.
 > 
 > (5) It's also possible that at some time in the future
 >     Cn will exceed Bn, in which case I would expect people
 >     to stop using NAT and (probably) demand something else.
 > 
 > (6) The argument that I thought I heard people (though not
 >     you) making is that Cn > Bn. I don't think that this
 >     is likely to be the case. In that sense, I think
 >     NAT is OK. I think that if we believe this, it will likely
 >     lead to us designing a long series of S'es that are
 >     inferior to NAT (in the sense that users do not
 >     prefer them because (Bs - Cs) < (Bn - Cn). That's a waste
 >     of time.
 > 
 > Does this seem like a weird position for an IAB member to take?
 > I don't think so. 

The problem here is that your cost functions are
averages when what is far more interesting are the
trends. Voice is one trend and it pretty
fundamentally challenges one of the base
assumptions of NAT: private-client/public-server.
But instead of realizing that NAT is
architecturally incapable of dealing with private
servers and switching back to the model that does
accommodate that model fine, we're being driven as
a community to do both with the ensuing insanity
of two broken models being forced to cohabitate,
all the while neither meeting the actual
requirements.

So just saying that NAT is here get used to it is,
architecturally, not helpful. The split of effort
is to put it mildly a huge drain on engineering
talent, but more importantly the net is becoming
more and more incomprehensible because of it, both
intellectually as well as operationally. That
strikes me as a profound architectural issue, one
that should scare anybody who cares about the net.

So yes, to my mind saying "get used to it" is a
weird position because it discounts the problems
of the status quo and doesn't really express any
vision for what the architecture *ought* to be, or
drive us in a direction which will make that
determination possible. What NAT's are telling us
is that there are requirements that aren't being
met with the current Internet. But that's really
the only thing they should be telling us because
we already know that NAT's fail miserably on other
requirements.  We want an architecture that meets
all of the requirements, not a hodgepodge of half
solutions which fall over in the first stiff
breeze.


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]