XOR_MAPPED_ADDRESS_OPTIONAL attribute

[Chaosvex]

I'm implementing a STUN client and I've been using your server a test endpoint (thanks!). When adhering to RFC3489, I noticed that the server responds with an undocumented XOR_MAPPED_ADDRESS_OPTIONAL attribute, which seemed odd. I found that it comes from an early RFC5780 draft and was made comprehension required in subsequent drafts.

It's not a big deal given that it's comprehension optional but I'd argue that the server should not be sending this attribute at all. This attribute never existed in RFC3489 and any newer client will be using the correct XOR_MAPPED_ADDRESS. I can see that it's used for Vovida compatibility but that appears to be pertinent to the client rather than the server.

I'm not really expecting any change to be made on the back of this issue but for being a stickler for adhering to the standard, I figured I'd present an argument for no longer sending it to legacy clients. I'd happily submit a PR for it.

Thanks again. :)

[jselbie]

Good catch.

As the server is coded now:

• If the incoming binding request conforms to the 5000 series RFCs and has the "magic cookie" of 0x2112A442 as the first 4 bytes of the transaction id, then server will send back the encoded xor mapped address with an attribute id of 0x0020. This is the modern behavior that's probably inline with what you want.

• If the incoming binding request does not have the magic cookie in the transaction id, it's assumed to be a RFC 3489 client and the xor mapped address has an attribute id of 0x8020 (optional comprehension). Also, the padding rules change with regards to show attributes are parsed and written out in this mode.

I can't remember the clients and servers I tested with back then, but I suspect certain products only understood RFC 3489 and the 0x8020 attribute when this code was first published. I think there might have been a bug fix a while after as well.

My advice would be for your client to be strict in sending RFC 5780 style binding requests, but be prepared to handle RFC 3489 style responses from legacy servers that might still be out there. I think this is as simple as just accepting both 0x8020 and 0x0020 for the XOR Mapped address and falling back to the un-xor'd mapped address if neither is found.

[Chaosvex]

Thanks for the quick response.

My client has a toggle for both RFC3489 and the 5xxx series, which is why I noticed the XOR_..._OPT (and added handling), since it'll pretend it isn't aware of anything that was introduced in later standards (a 'strict' mode, so to speak). I doubt there actually many servers out there that only speak RFC3489 but I figured I'd support it anyway as a sort of 'baseline', since it isn't much more work on my part.

[jselbie]

I doubt there actually many servers out there that only speak RFC3489

Well, the "Vovida" code, I think was just an RFC 3478 server. Which was the only other STUN code base before this repo came along. Look here: https://sourceforge.net/projects/stun/

I'm implementing a STUN client

You are aware that the Stuntman code base has a fully functional client and client message generator/parser, right? I'm not sure if you using C++, but the code is here:

https://github.com/jselbie/stunserver/blob/master/client/clientmain.cpp https://github.com/jselbie/stunserver/blob/master/stuncore/stunclientlogic.cpp