At 18:07 18/04/01 +0200, Thierry Agassis wrote:
>
> Has anyone had to (tried to) standardize TCP and UDP applications/port
> numbers, enterprise wide, in a multi-platform environement (Unix,
> Windows, z/390) ?
the well-known ports are defined in /etc/protocols on Unix.
the "not-well-known" ones are not well-known, and thus can't be standardized.
>
> The objective would be to facilitate trafic filterring and shaping
> (prioritization).
> Would it be possible to make sure that THIS port is THIS application ?
No, that would mean that I should'nt use some port for an app just because
someone in Australia (or elsewhere) is using it for another one. so
uncorrelating
protocols and port numbers is a good design decision.
>
> It may sound obvious (RFC1700, etc.), but when you think about RPC
> mechanisms and the
> fact that clients usually use the dynamic port number returned by the
> socket() call (or equivalent), things get not so obvious.
RPC uses dynamic ports because it allows you to have any number of
simultaneous connections. If you require the use of say just 3 ports, then
you either have only 3 RPC sockets at a time, or the server and client have
to demulteplex things, which is harder for coders and not really good for
performances
(demultiplexing inside the kernel is better than demultiplexing in the app).
>
>
> All stacks don't allocate the first free port above 1023, some start
> above 32,768 (32'768 in Europe ;-).
The "common" practice is to use 1024 to 5000 as random ports.
but even if this is not a standard (and NAT devices map to other ranges:)
you still know what is running in your network (after all, you have to!).
> [snip]
> It seems that Solaris and HP-UX can do that (/usr/sbin/ndd -set /dev/tcp
> tcp_smallest|largest_anon_port).
in *BSD, that's sysctl with
net.inet.ip.portrange.[lowfirst, lowlast, first, last, hifirst, hilast]
variables.
So yes, it's changeable, but you should only change if needed:)
>
> I've heard that z/390 let the administrator reserve port numbers per
> address space (process ?) and that the reserved ports will not be
> available to other address spaces, even if no socket is active, yet, on
> this port.
> I think it is not possible on Windows or Unix.
you can write a perl script that binds to the port...
>
>
> I wonder if the application address space will not become an issue in
> the future.
> IPv6, of course will not help since it will not change the way TCP or
> UDP work.
>
I think a machine will get down before all the ports are used (I mean for
serious use, not just a bind that does nothing).
and anyway, just use many IP addresses if you want more applications
(you can bind a socket on 10.0.0.1 port 80 and a second one on 10.0.0.2
port 80 and so on...). you'll need to deal with routing, but it's feasible...
Also, there is no need for so many ports. Much people are using port 80
to do everything, and http has replaced TCP and even UDP as "the" transport
protocol.
While there are problems with the range of "reserved" (privileged) ports,
that's no more a concern since new applications no more need such tricks.
regards,
mouss
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
