NAT is evil (still), NAT & SIP

I say it enough, but the latest adventures in SIP make me even more convinced at the evilness of NAT. I thought it may be worth trying briefly to explain what the hell I am on about. It is a tad tricky without getting technical, but I'll have a bash.

Computers send messages to each other - that is how networks work. The internet is a damn big network and has been around a while so the messages use a protocol which is just a well defined set of rules that everyone follows. Part of that protocol is addressing. It is how one computer says, in the message, where the message is to get to in the end. It also says where the reply is to go (a return address).

There are many ways to do an addressing system. You will know some of these already - telephone numbers are a sort of address as are postal addresses. Postal addresses are not too bad an example of how this works in the internet world.

The internet protocol uses an addressing scheme designed around the fundamental principle that every end-point has a globally unique address. Each of the messages that are sent has this as the address and it stays the same all the way as it passed from computer to computer. The same is true with a letter. You put the address on it, and maybe put a return address on the back, and you send it. That address does not change as it travels around the postal system.

At each stage the job of whoever has that letter is to send it to the right place to get it logically closer to the destination address on the letter. My local sorting office put it on a truck or a train or whatever to get to another sorting office. They ensure it goes on a van, and gets to a postman, and finally the postman sees that same full address on the envelope and ensures he puts it through the right letter box.

This type of system is very sensible. It makes things relatively easy as the address does not change. It means if you look up my address, it is always the same address regardless of where you send the letter from (pretty much).

You can have other schemes. You could put on the envelope to send to the local sorting office, where they open it and find another envelope saying to send to another sorting office. They open it and find another that says which van to put it on. The postman opens it to find which road to take it to. Etc. This is complicated and means the way you address things changes as the message goes through the system. It also means that it changes depending on where you are starting.

So, where does NAT come in?

Imagine that you are in an office, and in the office you have decided that all addresses are "Wonderland". And your room is "No. 5 Mad-Hatters corridor, Wonderland.". You can send letters freely to other places in Wonderland no problem, and you can put your return address on the letter and they can reply, no problem. Lots of different offices do the same thing, so there are actually lots of "No. 5 Mad-Hatters corridor, Wonderland" in the country. This is fine as long as letters do not leave your offices.

But if you want to send a letter to someone in the real world, e.g. "10 Downing Street, London" the post room cross out your return address and put the real address of the office on, e.g. "A&A, Enterprise Court, Bracknell". Then when people in the real world get the letter they can reply. Obviously the reply gets to the post room, and they somehow have to remember who was sending letters to "10 Downing Street, London", cross out the address and put "No. 5 Mad-Hatters corridor, Wonderland" on it, and send it on in the internal post.

As a system it sounds sensible...

Except it is not. It is broken. Imagine my letter to "10 Downing Street, London", had in it, "Please can you send a letter to by friend at No. 7 Alice's Gardens, Wonderland" in it. This is inside the envelope. It is not the return address on the outside. This means the post room did not know about it. When the recipient gets the letter they try replying to the Wonderland address and it does not work as the post office have no idea where Wonderland is. Even if they know it is one of those magical addresses a lot of offices use, they would not know which office.

Well, some protocols that use IP (internet protocol) work on the basis of replies coming back to the sender address on the envelope. That means they work via NAT as the post room changed the reply address, and made a note for the reply.

Some protocols do this, but expect to be able to send replies much later and the post room have forgotten who was writing to "10 Downing Street, London" by the time these replies come back and don't know where to send the letter internally. SIP does this, so you can get a case where the phones work for seconds or minutes after they have been turned on or made a call, but later incoming calls don't work.

Some protocols send other addresses in the letter. SIP does this, a lot! SIP says where to send replies to the initial letter. Where to send things later (may be different) and where to send the actual call audio itself (different again).

Now, if you have a really smart post room, they don't just change the return address, they look in the letters and change the addresses quoted in the letter. But they have to understand hundreds of different ways people write letters. SIP is just one.

SIP is a specially complex because it includes addresses in the message in lost of ways. Getting SIP to work with NAT is specially complex too.

1. Some SIP phones are clever and they manage to get and quote "outside" addresses. There are various complex ways to do this depending on the router and firewalls involved.
2. Many NAT devices will rewrite the SIP messages and handle the SIP setup and registration and even call set up.
3. Some SIP phones can handle the audio using something called a STUN server to work out what sort of NAT is done.
4. Some SIP call servers (proxies) also break the normal SIP protocol and ignore the addresses quoted but instead reply to the return address they see which then works.

Sadly it is very hard for our call server to work properly with NAT without a lot of messing about. One of the problems is that the audio can be connected to the far end directly over internet protocol. This is best for reliability and performance reasons. Our call server only has to handle the actual call setup and not the stream of packets that are the call itself as they go direct. This means that to work with some types of NAT, every possible audio (RTP) endpoint would have to play the game to work with NAT. This is impractical.

The other problem is that the work arounds are dependant on several bits all working together. Our new call server works fine with NAT where the NAT router does all of the necessary header changes. But some that do not do all of the header changes and some cases with some phones, do not work. The work arounds depends on so many bits not following the normal design rules of internet protocol and bodging things. So change one bit and you have a different set of working and not working cases.

The end result is, for now, that we maintain some customers on the old call server. It has several bodges and also relays the media as well. This is one of the reasons it is not as scalable and why we wanted the new call server in the first place.

Longer term, we don't support NAT, but we do support IPv6. We plan to test as many phones on IPv6 as possible, and have our firewall boxes that handle IPv6 so that NAT is not needed.

For the non technical it is worth explaining one of the reasons people do NAT. It is because they only get one address. A whole office with one address (for the post room, effectively). So they have no choice. In fact what you need is every endpoint, even within an office or home, to have its own globally unique address (as per the original design of IP) and then no NAT would ever be necessary. IPv6 is a new system that allows every atom to have its own address so NAT should never be needed. Sadly some people will still find convoluted reasons to use NAT with IPv6 and they should be properly shunned by everyone else. Shun the NAT user. NAT is evil... etc.