minimal STUN

Hello,

It seems to me that the algorithm that STUN uses to discover the NAT type is 
not as useful and brittle especially when behind a non-deterministic NAT. 
This sentiment seems to be reflected in draft-rosenberg-rfc3489bis-00. As 
such, it also seems to me that some of the requirements needed for a STUN 
server can be made optional. In particular, the requirement that a Bind 
response MUST have a CHANGED-ADDRESS attribute doesn't make sense when a STUN 
server will only be used for it's reflective property to learn about a NAT 
binding. Could I suggest that the Bind response MAY have a CHANGED-ADDRESS 
attribute. A STUN client that wishes to use a STUN server for the purpose of 
NAT type classification could use the presence or absence of the 
CHANGED-ADDRESS attribute in the Bind response to determine if this STUN 
server is capable of being used for NAT classification.

This would reduce the resource requirements of a STUN server. It would also 
make ICE peer STUN server a compliant implementation.

Jon