TCP and UDP ports management...

[Thierry Agassis]

----- Réacheminé par Thierry Agassis/ITServices/Unicible le 18.04.2001
18:06 -----
                                                                                       
                     
                    Thierry                                                            
                     
                    Agassis              Pour :  [EMAIL PROTECTED]              
                     
                                         cc :                                          
                     
                    17.04.2001           Objet :      TCP and UDP ports management...  
                     
                    14:37                                                              
                     
                                                                                       
                     
                                                                                       
                     




Hello Everybody,

                                                                            
 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 objective would be to facilitate trafic filterring and shaping         
 (prioritization).                                                          
 Would it be possible to make sure that THIS port is THIS application ?     
                                                                            
 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.                  
                                                                            
 All stacks don't allocate the first free port above 1023, some start       
 above 32,768 (32'768 in Europe ;-). If an application listen on port       
 54321 on all the platforms and a client which has nothing to do with       
 this application gets port 54321 because it is free on its local stack,    
 things get confused.                                                       
                                                                            
 My understanding is that if all the stacks can define that a given range   
 is reserved for "dynamic" allocation (ports returned by socket() call),    
 the other ports outside this range could be allocated to "well known"      
 applications (at least those able to bind() on specific ports/ranges).     
                                                                            
 It seems that Solaris and HP-UX can do that (/usr/sbin/ndd -set /dev/tcp   
 tcp_smallest|largest_anon_port).                                           
                                                                            
 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.                             
                                                                            
 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.                                                                  
                                                                            
 Any input or experience is very welcome.                                   
                                                                            
 Best regards !                                                             
                                                                            
                                                                            


Thierry Agassis




-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]