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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf