Apple strudel, and other things that don't traverse NATs.

NAT, or Network Address Translation, is the absolute bane of my existence (next to Barbara Walters of course). It finds itself near the upper-ends of lists like "technologies that frack my network code" and "reasons IPv6 will save us from ourselves," but what many of you don't know, is that NAT was designed by giant salmon with a bad attitude. Why, if it weren't for NAT, we might not get to enjoy such wonderous atrocities like "Universal Plug and Play" (UPnP).

UPnP, oh how I hate you, let me count the ways:

• Runs over HTTPU.
  HTTPU is a silly acronym for an even sillier concept, HTTP over UDP which isn't really a standard, but an outdated (2001!) internet draft (draft-goland-http-udp-04.txt).
• Over-engineering? Is there a better modifier than "over" we can use?
  Imagine what would happen if SOAP, and some network engineers got hammered and made a bastard love-child in the back seat of a 1993 Buick Le Sabre, UPnP would be it. It exists in this weird realm of trying to cover device and service discovery and advertisement, and about 13 other things that don't need to exist but do.
• Description. C'mon, are you serious?
  After "addressing" and "discovery" in the UPnP hall of horrors, it's time for description. This part of the freak show is where "we" (as in our machine/device/etc) know about "interesting devices" but don't know much about what those do, so "we" request a "description" after which, the other device sends us 8-10 pages of XML (double spaced) telling us about the hardware, the services, and anything else we might ever care to know about (mood, mother's maiden name, etc).
• Internet Gateway Device
  This is where the NAT happiness happens, I'm pretty sure it's just as miserable as the rest of UPnP, but i'm not willing to read a couple hundred pages of documentation on why IGD sucks, but if the couple hundred pages wasn't enough to convince you, I've got a note from my mom confirming it.

"Aren't there alternatives?" I hear you quip, why of course! In the realm of NAT mapping protocols there exists another contender which I will hit on in a later posting, NAT-PMP, but other than that, UPnP is pretty widely adopted.

On the other side of the fence exists NAT hole-punching protocols, such as STUN, which helps coerse UDP packets from one side of a NAT to the other side with relatively few bumps and bruises. The downside of using a protocol like STUN, is that is is based on UDP, so unless you receive an ICMP error message your packets may just continually disappear into the ether and your application wouldn't be the wiser (unless you implement some TCP-like error-checking and packet ordering on top of UDP). For most applications that use STUN such as VoIP, this isn't a major issue. For other applications where data integrity is a major issue, UDP in general is most likely not on the table to begin with. Which leaves most folks (like me) working with something like STUNT which extends STUN's functionality to add support for TCP packets.

Nothing is fool-proof however, NAT is such an abomination that there exists a good proportion of NAT devices in the "real world" that misbehave, preventing hole-punching protocols like STUN(T) from getting through to allow clients behind the NAT to perform the actions they wish to. The situation worsens if you're behind two NAT devices (which I was in my last apartment, BLECH!), as no amount of UPnP, hole-punching, or Merry Christmas sugar cookies will allow traffic to traverse in the fashion which some applications (iChat AV for one example) need in order to function.

Did I mention that I abhor NATs? Grumble.

[tags: nat, nat-pmp, upnp, stunt, stun]

• Posted: 21/12/06 03:44AM
• Category: Programmr

Write reply