[I wrote:]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.
here's the only thing that a NAT standard should say:
an intermediary MUST NOT alter the source or destination field in an IP header.
an intermediary MUST NOT route an IP packet to other than its intended destination.
an intermediary MUST NOT alter the payload of an IP packet.
I don't dispute this. However, I will observe that customers of retail Internet service seem to rarely have much interest in whether their network intermediaries comply with this proposition.
And, your list is incomplete. The NAT code I maintain does all of the things above that your proposal would explicitly forbid-- but it does a few other nasty things as well. For example, 1) it *should* be rewriting IP datagram identifiers (but I haven't coded it yet), and 2) it hides path-MTU discovery black-holes by rewriting TCP MSS fields.
Basically, once you've committed to rewriting the forwarding information in an IP datagram, then it's open season on all manner of horrible opportunities for intermediaries to engage in Internet abuse.
You want to know what made my blood run cold in the latest release of the product's firmware? I had to change it so that it would propose an impossible MRU in a PPPoE LCP negotiation. Apparently, a lot of PPPoE implementations are happily proposing an MRU of 1500 octets, because there are a lot of PPPoE servers out there that will refuse to negotiate down to the more realistic value of 1492. Consequently, when the product doesn't connect to a buggy PPPoE server, and every other product people try seems to work fine (as long as you don't stress test it), the customer blames the firmware that actually complies with the actual standard for refusing to work the way everyone else's non-compliant system works.
So yeah-- I'm very excited about the prospects of the IETF proposing standards. I'm even more excited when they're standards that customers regard as actually valuable parts of their lifestyles. I have yet to see a proposal for a NAT box spec that would seem like a valuable addition to the RFC library. Including yours, Keith... no disrespect intended, honest.
-- j h woodyatt <[EMAIL PROTECTED]> stop me before i rewrite your IP header again.
