5

I need to programmatically determine the Router NAT type in my program. I did look at some of the STUN related answers and UPnP related information on SO. But did not get any definitive answers.

I looked at STUN RFC (rfc 5389) and it does not specify how to determine the NAT type. It does mention that it's previous version (RFC 3489) did provide the mechanism to determine NAT type. But also mentions that

Furthermore. classic STUN's algorithm for classification of NAT types was found to be faulty, as many NATs did not fit cleanly into the types defined there.

Given above, could you please advice on how I should go ahead with determination of router NAT type in my software. Further, now that RFC 3489 is obsoleted is there any other means?

Thanks in advance.

sthustfo
  • 1,209
  • 4
  • 19
  • 35

1 Answers1

6

RFC 3489 was split into three different RFCs:

RFC 5389 - basic STUN protocol. Basic protocol of STUN binding request and binding response are largely the same as RFC 3489. The protocol header gets updated with a magic cookie occupying some of the transaction id field. Some STUN attributes get redefined. A few new ones added (specifically - XOR_MAPPED_ADDRESS). Some changes to how STUN auth is done. NAT behavior and classification discussion moved to RFC 5780.

RFC 5780 - "Nat Behavior discovery using STUN". The basic change to NAT type discovery was to distinguish NAT port mapping behavior separate from NAT filtering behavior. Whereas RFC 3489 would try to classify a NAT into one of several buckets ("cone", "port restricted", "symmetric") - which was just too generic to describe a NAT.

RFC 5769 - Just outlines what the hex dump of a few different STUN message types would look like.

Out of curiosity, I suppose knowing if your app is running behind a NAT is useful. But how would knowing the NAT's behavior influence your code path?

Shameless plug - Use my STUN Server code that is hosted on GitHub.

selbie
  • 100,020
  • 15
  • 103
  • 173
  • thanks for your answer. I am working on nat traversal, so knowing about the nat type helps though it does not change the code flow. I think it is something exciting to work on. – sthustfo Dec 22 '11 at 11:54
  • BTW, how accurate is the nat type determination with the newer RFC 5780, given that RFC 5389 does not have a good opinion on RFC 3489 mechanism. Have you tried it and if so, any observations? – sthustfo Dec 22 '11 at 11:57
  • I'd have to go back and check my notes, but most well behaved NATs are "endpoint independent" in terms of their mapping behavior and "address+port dependent" with regards to filtering. Which if you have one of these NATs, it just means you can reliably do P2P via UDP with hole punching. If that NAT is not "endpoint independent" for mapping (aka "symmetric" in the old RFC), it becomes more difficult to traverse. "Port prediction" sometimes works. I would love to chat with you about your project and/or if we can collaborate. Feel free to follow up with me offline jselbie at gmail dot com. – selbie Dec 22 '11 at 20:32