ietf
[Top] [All Lists]

Re: "reality" vs. "principle" (was Re: About IETF communication skills)

2008-08-02 11:58:52
Noel Chiappa wrote:

    > IPv4 NATs cause problems .. because they rob applications developers of
    > functionality, make the net less reliable and less flexible, increase
    > the cost of running applications and raise the barrier for new
    > applications, and increase the effort and expense required to
    > troubleshoot problems.

These things may or may not have been perfectly understood a priori by those
who deployed NATs, but my sense is that even if the world had to do it all
over again, they'd do it all again, for a simple reason: these costs of NAT
were outweighed by the benefits of NAT (allowing network expansion with
little additional coding/engineering/deployment investment; also, it allowing
other higher bang/buck things, such as advanced Web stuff, to be done, by
allocating that effort elsewhere).

I would characterize this differently. The immediate benefits of NAT were obvious and the immediate costs seemed to be small. However the long-term costs were not well understood (most people still don't understand them) and were much larger than assumed.

(I have no idea what you mean by "advanced Web stuff" being "higher bang/buck" and where "that effort" could be allocated from to do that - but dealing with NATs has certainly absorbed a lot of effort on the part of application developers and network operators that could have been put to better use, and it has raised the bar for deployment of new applications in the Internet - certainly many more new applications could have been deployed in a NAT-free world.)

Of course, a lot of these comparisons require one to make assumptions about what could have happened differently if, say, the problems with NATs had been understood earlier, or there had been a greater reluctance to violate the design principles of the Internet. We would still have had IPv4 address shortages to deal with. It's possible to imagine better outcomes, but difficult to evaluate how likely they would have been.

Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>