Tuesday, November 8, 2011
Routers and NAT
IPv4 remains to be a pain in the neck. The biggest problem is that there are not enough addresses, and people need to do dirty tricks to keep the network up and running.
One of the biggest problems is that routers have only a limited number of NAT UDP table entries. The problem is this: When a client in the private network sends a UDP request to the public Internet, the router has to remember from which private IP address and port the packet came from. It associates that address/port with a port on the public interface of the router. Obviously you can have up to 64 K ports on a router doing this trick.However, there are at least two problems. The first one is that most devices have a limited table size. For example it is not unusual to have just 32 table entries. So if there are 32 devices in the private network sending out a UDP packet, the router will have to drop old table entries to accommodate the new entries. Then when a response for an old port association will come back from the internet, the router will drop the packet.
The problem is even bigger.Because this works okay when you use UDP for DNS. DNS is pretty much stateless here, and if the NAT table should have dropped the connection already, the DNS client will just repeat the request and the whole thing takes a little longer. But when we start using SIP registrations, dropping the NAT becomes random and sometimes (probably most of the times) it works fine, and then sometimes it does not work fine and you are missing incoming calls. That’s when people get frustrated. I don’t even blame them: It is very difficult to trouble shoot this problem. DNS and other UDP-based services work okay, but SIP traffic just gets dropped randomly. It is easy to point fingers at the SIP devices, but now you know, there is not much the device can do.
What people do is making the registration interval shorter. I have seen registration intervals of five (5) seconds! This starts a kind of battle for the shortest registration duration, all contributing to a huge waste of bandwidth. It is almost like denial of service, but it keeps the service calls for the providers low. On the m9, I must say we were very hesitant to add support for STUN (market demanded it for those providers who cannot afford the luxury of a session border controller); but at least we made the default refresh interval very short to have a good chance to win in the battle for the ports, hehe.Is TCP the answer? Not really. In the real world, the number of TCP connections is also limited for the cheap routers and it becomes as erratic as with UDP. I have seen cases…
This is madness.I can’t wait until we turn off IPv4 and use IPv6 instead. Lets hope for better routers. Cheers.