On Tuesday 09 April 2002 03:48, Nils Ohlmeier wrote: > If i understand the spec correct, a UPnP deamon have also to > provide control over your ppp-deamon. The main aspect of the spec > is configuring and controling your dialup connection and the > posibility to configure port-forwarding is additional. At this > commands is mentioned that the deamon also have to configure the > firewall, if one is implemented :-), according to forwared ports.
UPnP is "UNiversal Plug and Play", and covers a very wide scope of automatic discovery and configuration in small networks. In large I think it is mostly wet dreams of the authors, but some aspects like inverse NAT port mapping is at least useful in the short term. Note: The portmapping feature is available in both the IP and PPP based "upstream" interfaces (WANIPConnection, WANPPPConnection). > If i'm not wrong ctnetlink will provide what a UPnP deamon needs to > support this port-farwding requests. >From my understanding some changes will be needed to allow for decent firewalling. We still want to be able to use connectiontracking helpers to inspect the traffic and tell what is related or not, not just to blindly trust the UPnP client. > Port reservation isn't really > a problem because the only case when a UPnP deamon can reject such > port-forwading request is, when the same tuple of external IP, port > and destination IP and port is used by another internal host. Even > if all ports on the NAT-Device are occupied the deamon isn't > allowed to reject such a request.... The device is always allowed to reject portmap requests at it's own will. The spec only defines then the device MUST reject.. And you are allowed to firewall these in any way you like. The spec only assumes that if you are doing firewalling then you know how to do so without impairing the service to be provided to your users. Regards Henrik
