ietf
[Top] [All Lists]

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

2008-08-01 15:27:33
Geoff Huston wrote:

Yes, I stand by what I said in that article. If you disagree with
my perspective on this topic, then perhaps you may want to followup
with me directly, rather than claim some shortcoming on the part
of the journalist.

Well, of course, the things you are quoted as saying are separate from the spin given by the author and/or editor. But I reread the article to refresh my memory as to what you were quoted as saying, and I do have a disagreement or two:

(from the article:)

Geoff Huston, chief scientist at APNIC and an expert on IPv4 address
depletion, says it's important for the IETF to develop high-quality
NATs for IPv6 instead of ignoring the requirement as it did with NATs
for IPv4. "Frankly, it's a NAT-dense Internet these days, and I for
one would rather see the world as it is than steadfastly maintain a
position of high principle in the face of reality," Huston says. "The
challenge to the IETF is whether it is prepared to shed its biases
here and figure out what would makes NATs in IPv6 slightly less
odious than what we did in IPv4."

I find the comparison of "reality" vs. "principle" really misleading and unhelpful, especially as a public statement.

The problems with IPv4 NATs are real and numerous. And IPv4 NATs cause problems not because they violate "principles", but 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.

I'm reasonably certain that you're aware of all of this.

Huston says NATs are useful for addressing, packet filtering and
other functions. He says the real problem with NATs is that they lack
standards, and that is an area where the IETF can make improvements
in NATs for IPv6.

Strongly disagree.

Most of the real problems with IPv4 NATs that I've outlined above could not have been solved merely by having IPv4 NAT behavior be standardized.

- There was no way to get rid of multiple addressing realms in an IPv4 NAT world, and the resulting problems for host addressability across realm boundaries.

- There was no way to get rid of port mapping, and the consequent need to have NA[P]Ts allocate and destroy address bindings (causing connections to break) in a world where NATs were used as a way to deal with IPv4 address shortages.

- Given the inevitability of port mapping, there was no way to avoid having NATs impose apparently arbitrary (to applications) barriers to connections even when those barriers had nothing to do with security policy.

Of course, standardized IPv4 NATs would have been somewhat preferable to the hodgepodge of NAT behaviors that exists now. But I don't think we understood NATs well enough ten years ago (which is when I think we would have had to standardize them for those standards to have had much effect) to know how to make better-behaved IPv4 NATs. And I don't think we could have avoided the worst of the problems with IPv4 NAT even if we had had an idea of what a better-behaved IPv4 NAT would look like.


But back to the notion of "principle".

It's easy to dismiss those who cite "principle" as being over-idealistic or out of touch. And it's easy to dismiss arguments whose subtlety one doesn't understand as appeals to "principle". But when people appeal to principles in discussions of the Internet and its protocols what they're generally saying is a shorthand for something like this:

   There is a relatively simple model that most of us understand for
   how the Internet was intended to work.   As long as we stick to
   that model, we will generally understand the consequences of our
   design decisions within that space.  But when we deviate
   significantly from that model, we are in new territory.  We do not
   understand what will happen, either as individuals or as a community
   whose decisions affect one another.  That's not to say that
   "principles" should never be changed or violated, but rather, that
   we need considerably more time and analysis to understand the
   consequences of violations of "principle", than we need to make
   design decisions which stay within those "principles".

To reiterate: NATs don't cause us problems because they violate principles, they cause us problems because they break things. But the fact that the principles were being violated by NATs, was a clue that significant problems might result from their use. Sadly, many people ignored those clues because they didn't trust arguments that appealed primarily to principle... and by the time the actual problems were well-understood, it was too late.

"The IETF's position of ignoring NATs some years back forced NAT
software builders to exercise their own creativity when designing
their version of NATs," Huston says. "This variation of NAT behavior
is a far, far worse problem than NATs themselves."

Again, this presupposes that IETF would have collectively been able to understand what individual NAT vendors apparently did not. And in my recollection, IETF did not ignore NATs. Certainly I tried hard to make people aware of the problems that NATs would cause, and I wasn't the only one. Really I think IETF did not try to address the IPv4 NAT problem because no good solution was known...and a sure way to waste time and frustrate people is to convene a WG without having any idea how they'll solve the problem. If we had had a concrete proposal, things might have been different. But I don't recall seeing one, and I tried to come up with one myself and failed.

And after all this time I think I have a pretty good handle on how to make an IPv4-IPv6 NAT be well behaved - but I still don't know how to make IPv4 NAT work well.

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