at the risk of feeding into a long-burning flamewar: when you say "a decent NAT box spec", what do you think of?
Now, you've done it.
As far as I can tell, a NAT box contains, over and above what it does because it's a router, a firewall or any other thing it might do:
- Address translation
- Application layer gatewaying
- Remote control of the NAT functionality (already being worked on in MIDCOM)
So what did you want a "decent NAT box spec" to say?
Harald, genuinely curious
I maintain the NAT code (among other things) in the firmware of a consumer Wi-Fi/router product. I'm not sure I can think of anything the IETF needs to do here beyond what it has already done-- or is in the process of finishing up.
I think the spec that Mr. Hallam-Baker would like to see is likely to emerge from outside the IETF. In fact, I predict that several competing de facto standards will emerge in the market, and eventually one of them may win out-- but I'm pessimistic about that.
When customers of retail Internet service start demanding a NAT standard, then that's when the IETF might want to think about documenting the standard that the market seems to want. Not before, I think.
I see no evidence that such demand exists now, or that it's very likely to exist in the foreseeable future. Piteous whines from applications developers complaining about the weird menagerie of NAT implementations do *NOT* constitute an indication of real demand from retail Internet service customers.
The IETF has already decided how to proceed with addressing the limitations in IPv4 that make the deployment of NAT devices an optimal strategy in some cases. We've seen how successful the IETF has been in persuading users that a new protocol is superior because it comes stamped with the magick 'Draft Standard' label. I doubt that providing such a magick stamp for NAT devices would be worth the effort if the market isn't interested in products that claim to be compliant with it.
-- j h woodyatt <jhw@wetware.com>