David Conrad wrote:
Tony,
On Nov 25, 2008, at 4:41 PM, Tony Hain wrote:
Either way the app developers will have to rely on topology
awareness crutches to deal with the resulting nonsense.
Stuff they presumably already have to deal with because they'd like
their applications to be used in the real (IPv4+NAT) world...
Yeah, but we're trying to get rid of that stuff, or at least
considerably reduce the cost and complexity, because (among other
things) it presents a huge barrier to adoption of new multiparty apps.
A reasonable standards development effort would not blindly endorse
something known to be detrimental,
Standards development effort != endorsement.
According to RFC 2026, IETF standardization is a kind of an endorsement,
because it's a statement of both protocol quality and community consensus.
The architecture is _ALREADY_ broken. 66NAT is merely another symptom
of the underlying disease.
Just because a disease exists does not mean we have to encourage its spread.
The only reason for IETF to standardize some kind of 66NAT is to
significantly improve the situation over what would happen in the
absence of standardization. There are several ways that we could
probably do that. But one of them is NOT to standardize NATs like they
exist in IPv4. We already know that that sucks really badly, and it
would never meet the criteria defined in RFC 2026. Nor would it achieve
community consensus.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf