Like every other website on the planet, SmallNetBuilder uses cookies. Our cookies track login status, but we only allow admins to log in anyway, so those don't apply to you. Any other cookies you pick up during your visit come from advertisers, which we don't control.
If you continue to use the site, you agree to tolerate our use of cookies. Thank you!

Router Charts

Click for Router Charts

Mesh Charts

Click for Mesh Charts

Summary, Conclusions, Recommendations

Updated 8/2/02

Basically, I'm still not very impressed with UPnP's tricks at this point in its development. Let me sum up what I've learned:

Summary of UPnP enabled Internet Gateway Device (IGD) capabilities
What it does
What it doesn't do

1) Allows a UPnP enabled client to find and connect to an IGD if the client is set to "Obtain an IP address automatically".

2) Automatically opens needed ports in the IGD firewall for applications that support UPnP NAT Traversal

3) Allows a user to define Services (open ports in the IGD firewall) without directly accessing an IGD's admin interface.

4) Provides access to the IGD's main admin interface via a My Network Places icon that has an obvious name.

1) Let the user automatically know that ports have been opened in the IGD's firewall and that security could be compromised.

2) Ask the user for permission before enabling NAT Traversal services.

3) Coordinate service addition, removal, and display between the UPnP and normal IGD admin interfaces

4) For non NAT-Traversal services, automatically determine the IP address for the service based on the computer that is establishing the service, or prompt the user to enter it.

5) Allow you to disable NAT Traversal separately from other UPnP services.

6) Automatically configure the IGD's WAN connection properties, i.e. get connected to the Internet.

7) Guide the user in configuring the IGD's WAN connection properties

8) Provide information about the IGD's WAN IP information (IP address, DNS, Gateway)

Since I didn't check to see what happens when multiple UPnP enabled clients request the same Service (port mapping), I can't offer any insight into what happens. But from reading Microsoft's UPnP papers, I will say that it looks like its an issue that applications need to deal with, since Microsoft says that port conflict resolution isn't the IGD's problem.

Note that many of the items in the "doesn't do" list above are not deficiencies in UPnP's fundamental design, i.e. things it could never do, but are things that are caused by limitations in the present implementations of UPnP, UPnP-enabled IGDs, UPnP-enabled applications, or combinations of the three. But no matter what the reason, the [in my opinion] deficiencies are still there.


I highlighted "Doesn't do" Points 1, 2 and 3, because I think Microsoft has set a very bad precedent that I think they need to fix ASAP. I realize that Microsoft is trying to make things easier for the consumer and to help their customers get around some of the frustrations of dealing with the problems that NAT-based routers can cause with many applications (not to mention the time and $ spent in the Tech Support calls related to those problems). But even your common Web-browser warns you when you are changing from a secure to a non-secure web page and can be set to block (or at least warn about) cookies, Java applets and other things that can cause security problems. Shouldn't a user be warned and allowed to confirm an event that could potentially be even more damaging than a cookie?! Especially when many users take the time to ensure that their routers are configured so that they are as invisible as possible to port scans?

It's simply unacceptable (and especially in light of Microsoft's alleged new company-wide focus on "trusted computing") that NAT Traversal doesn't provide warning and allow confirmation of opening holes in an IGD's firewall or allow the user to disable that capability independent of disabling UPnP entirely. Given the capabilities of the UPnP API, Microsoft could even go further and have UPnP provide indications of opened ports whether or not they were set by NAT Traversal.

So c'mon Redmond, let's get this fixed!


Recommendations? I have two.

  1. Don't make a router or other networking equipment purchase decision based on whether or not UPnP is supported. The technology needs time to mature, doesn't provide a lot of value added due to the relatively few applications that support NAT Traversal, doesn't provide enough user feedback and control of holes it opens in a IGD's firewall, and implementations are buggy. It also seems that manufacturers are not knocking each over in a race to make their routers UPnP-enabled, so it looks like UPnP feature improvements will be slow in coming.

  2. If you must have a UPnP enabled router that properly handles NAT Traversal, your only choice is still the D-Link DI-804.

Support Us!

If you like what we do and want to thank us, just buy something on Amazon. We'll get a small commission on anything you buy. Thanks!

Don't Miss These

  • 1
  • 2