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.


  1. I am a bit perplex with the whole IPv6 is going to sort all issues in regards of the 'nating' issues which is induced by this post.

    IPv4 -> IPv6 will sort anything for SIP, reason being the current devices that are currently providing IPv4 NAT will be replaced by IPv6 firewalls (No-one wanted to give full inbound internet access toward local network resources).

    The current issue that you are in fact having is with the connection tracking. In an IPv4, or IPv6, the connection tracking table allows to follow the state of the connection so all packet outside the session are dropped/ignore avoiding attackers to bypass firewall policies.
    Now for SIP the connection tracking is difficult as the SIP channels does not carry voice/video but just controls, tracking the data requires a much more complicated rules which understand what ports to which server are going to be used, not to say that all SIP product are perfectly respecting all RFCs to the letter.
    This complexity will not decrease with IPv6 as it is inherent of the SIP protocol.

    To make the point even further, protocols like IAX2 have been designed to use this in consideration and never ever created issue related to connection tracking on IPv4 or even IPv6.

    So here's my question why not supporting protocols that do work by design ?

    side questions: I will be interested to know which internet router only allow 32 sessions at anyone time :)

  2. Well designed routers are not the problem. Poor design routers are. And those can just pass the traffic through, no need to have a table at all! They'll call that 64-bit security.

    IAX is the answer for Digium as much as Skinny is the answer for Cisco. SIP might have many problems, but seems to be the only thing people could agree upon in the industry. This is political, not technical.

    I had a router that had 32 entries and no timeout at all. The price was right, though.

  3. ,,No-one wanted to give full inbound internet access toward local network resources''
    Why not? Every device will get its own public address, not without reason and making use of it. Only the necessary UDP ports will be opened and I think the relative simplicity of a SIP device makes it easy to secure?

    NAT is such an aggravation. Please let the big IPv6 transition begin!