slm@wsc-sun (Shamus McBride) (01/13/90)
Is there some organization or "official" list of tcp port uses above 256 (last one specified in RFC1010) or is /etc/services the best one can hope for? -- Shamus Mc Bride Employer: Boeing Computer Services Email: slm%wsc-sun@atc.boeing.com (static routers) or : slm@wsc-sun.boeing.com (domain routers) UUCP: uw-beaver!uw-june!bcsaic!wsc-sun!slm Voice: (206) 865-5047 US mail: MS 7A-35/Boeing Computer Services/P.O.Box 24346/Seattle, WA 98124-0346 DISCLAIMER: I speak for myself. The opinions expressed above do not necessarily reflect those of The Boeing Company.
heberlei@kongur.ucdavis.edu (Louis Todd Heberlein) (01/14/90)
In article <9001121841.AA25491@shuksan.> slm@wsc-sun (Shamus McBride) writes: >Is there some organization or "official" list of tcp port uses above >256 (last one specified in RFC1010) or is /etc/services the best >one can hope for? > >-- >Shamus Mc Bride >Email: slm%wsc-sun@atc.boeing.com (static routers) > or : slm@wsc-sun.boeing.com (domain routers) I too am, and I imagine many others would be too, interested in such a list. I see many ports being used which are not mentioned in /etc/services nor in any other documentation that I have found. Todd Heberlein heberlei@kongur.ucdavis.edu 128.120.57.118
deanr@lakesys.lakesys.com (Dean Roth) (01/15/90)
To get a list of assigned numbers (TCP ports, protocols, etc.), send email to info-server@sh.cs.net with the format shown below. (The subject line is ignored.) The request will be filled by a program. In the body of the message put: REQUEST: RFC TOPIC: RFC1010 REQUEST: END The last time I got the list it was 80KB. Dean deanr@lakesys.lakesys.com
rogers@OSI540SN.GSFC.NASA.GOV (Scott W. Rogers) (01/16/90)
The Assigned Numbers RFC available from the NIC (nic.ddn.mil) lists the officially assigned TCP and UDP port numbers. The /etc/services file may document additional "commonly" used unix TCP/UCP ports, but may not be officially assigned. To have a TCP or UDP port "officially" assigned for a specific use, you can make a case to jkreynolds@isi.edu or Jon Postel (also of ISI).
tcs@BRL.MIL (Terry Slattery, SECAD) (01/16/90)
> Is there some organization or "official" list of tcp port uses above > 256 ... I have been asking the same question of Jon Postel recently. It seems that Sun's NeWS system usurped port 2000, which has historically been used by ttcp (a program to test TCP/UDP thoughput). Upon discovering this I wanted to have a published port number so that it wouldn't happen again. Unfortunately, the number czar only handles low numbered ports. Something needs to be done about registering ALL port numbers so that this doesn't continue to happen. Personally, I don't see why the existing registration procedures can't be applied to all port numbers. Are there any significant problems in doing this? -tcs
cpw%sneezy@LANL.GOV (C. Philip Wood) (01/17/90)
>> Sun's NeWS system usurped port 2000
Sun also decided to use port 9 (DISCARD protocol) for "copy protection"
of their PC-NFS product. Is that a low enough port number? Nothing
like stomping all over convention. Now I have beaucoup messages from
various blankity-blank Peesee's in a log on our network test machine.
Of course all the other systems on the net get to handle these
interrupts too.
A way to stop this noise is to send the data back to them. Yuck, yuck.
We could call it "Well Known Socket Protection".
Philslm@wsc-sun (Shamus McBride) (01/17/90)
I asked a question about tcp port numbers are assigned (my interest was the
256 - 1023 range).
To throw something else into the discussion I awk'ed out the following
two tables (tcp & udp) from all of the /etc/services files I could find
(see note at end). For the most part the various systems I looked at
were consistant, but there were a couple of differences
ALL = unicos ultrix sun & yp
tcp:
7 echo ALL
9 discard ALL
11 systat ALL
13 daytime ALL
15 netstat ALL
17 qotd ultrix:unicos
19 chargen ultrix:unicos
20 ftp-data sun:yp
21 ftp ALL
23 telnet ALL
25 smtp ALL
37 time ALL
42 nameserver ultrix:unicos # IEN 116
43 whois ALL # usually to sri-nic
53 domain ALL # name-domain server
57 mtp ultrix:unicos # deprecated
77 rje ALL
79 finger ALL
87 link ALL
95 supdup ALL
101 hostnames ALL # usually to sri-nic
102 iso-tsap:tsap sun:yp:ultrix # for isode (M. Banan)
# tsap on ultrix
# iso-tsap on sun yp yp
103 x400 sun:yp # ISO Mail
104 x400-snd sun:yp
105 csnet-ns sun:yp
109 pop:pop-2 ALL # Post Office
# pop-2 on sun yp yp
# pop on ultrix ultrix unicos
111 sunrpc ALL
113 auth ultrix:unicos
115 sftp ultrix:unicos
117 uucp-path ALL
119 nntp ALL # Network News Transfer # USENET News Transfer Protocol
123 ntp sun:yp # Network Time Protocol
144 NeWS sun:yp # Window System
170 print-srv ultrix # network PostScript
201 nqs yp # NQS daemon
# port 607 on unicos
260 rtape ultrix # remote tape from chaos *rsg*
512 exec ALL
513 login ALL
514 shell ALL # no passwords used
515 printer ALL # experimental # line printer spooler
520 efs ultrix:unicos # for LucasFilm
526 tempo ultrix:unicos
530 courier ALL # experimental
531 conference ultrix:unicos
532 netnews ultrix:unicos
540 uucp ultrix:unicos # uucp daemon
543 klogin yp # Kerberos authenticated rlogin
544 kshell yp # and remote shell
556 remotefs ultrix:unicos # Brunhoff remote filesystem
570 eval ultrix # remote eval service *rsg*
600 pcserver yp # SunIPC
607 nqs unicos # Cray Network Queueing System
# port 201 on yp
608 cde unicos # Cray Distributed Editor
750 kerberos yp # Kerberos authentication--tcp
751 kerberos_master yp # Kerberos authentication
754 krb_prop yp # Kerberos slave propagation
755 kadmind yp
888 erlogin yp # Login and environment passing
906 sample yp # Kerberos sample app server
1109 kpop yp # Pop with Kerberos
1234 mkuserd yp
1524 ingreslock ALL
2001 lgc_pd unicos
2002 lgc_sdsrv unicos
2053 knetd yp # Kerberos de-multiplexor
2105 eklogin yp # Kerberos encrypted rlogin
5000 VTVIN unicos # bill samayoa / nrao aps virtual tv
5003 xcwcs ultrix:yp # CWCS control socket # experimental
5004 cwdata ultrix:yp # CWCS file transfer socket # experimental
22375 quantic unicos
udp:
7 echo ALL
9 discard ALL
13 daytime ALL
19 chargen ultrix:unicos
37 time ALL
39 rlp ultrix:unicos # resource location
42 name sun:yp
53 domain ALL
67 bootp ultrix # boot program server
69 tftp ALL
111 sunrpc ALL
153 sgmp ultrix #
161 snmp ultrix #
162 snmp-trap ultrix #
512 biff ALL
513 who ALL
514 syslog ALL
517 talk ALL
518 ntalk ultrix:unicos
520 route ALL
525 timed ultrix:unicos
533 netwall ultrix:unicos # -for emergency broadcasts
550 new-rwho sun:unicos:yp # experimental
560 rmonitor sun:unicos:yp # experimental
561 monitor sun:unicos:yp # experimental
704 elcsd ultrix # errlog
750 kerberos yp # Kerberos authentication--udp
751 kerberos_master yp # Kerberos authentication
752 passwd_server yp # Kerberos passwd server
753 userreg_server yp # Kerberos userreg server
999 applix ultrix # Alis
2049 nfs unicos # Network File System
----------------------------------------------------------------------
"ultrix" = ULTRIX V3.1 & Ultix-32 V3.1 (Rev. 9).
"sun" = SunOS Release 4.0.3.
"unicos" = UNICOS Release 5.0.13
"yp" = what I ripped off of local yellow pages servers.
------------------------------------------------------------------------
If people want to mail *ME* some /etc/services from some other systems
and there is enough interest I could republish this list. My interest
has been looking at colisions in the address space.
--
Shamus Mc Bride
Employer: Boeing Computer Services
Email: slm%wsc-sun@atc.boeing.com (static routers)
or : slm@wsc-sun.boeing.com (domain routers)
UUCP: uw-beaver!uw-june!bcsaic!wsc-sun!slm
Voice: (206) 865-5047
US mail: MS 7A-35/Boeing Computer Services/P.O.Box 24346/Seattle, WA 98124-0346
DISCLAIMER: I speak for myself. The opinions expressed above do not
necessarily reflect those of The Boeing Company.BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) (01/17/90)
> Is there some organization or "official" list of tcp port uses above > 256 ... Come on people. Port numbers above 255 are BY DEFINITION un-official. I could see some value in making the "official" space larger, but you still need a whole bunch of numbers for the other side of the connection. BillW -------
stev@VAX.FTP.COM (01/17/90)
> Now I have beaucoup messages from > various blankity-blank Peesee's in a log on our network test machine. > Of course all the other systems on the net get to handle these > interrupts too. > > A way to stop this noise is to send the data back to them. Yuck, yuck. > > We could call it "Well Known Socket Protection". > > Phil > i understand you are kidding, phil, but before anyone decides to go give this a try, you should consider that you are voilating the paradym as badly as they are (hope the spelling is correct there, someone ran off with the dictionary). while it *seems* like a good idea at the beginning, and one could argue that is you are only replying to the hosts that generate traffic to the discard socket with the broadcast address, it is still a bad idea to lower ones self to their level. personally, i liked the idea of charging back for the packets:) stev knowles ftp software stev@ftp.com
morgan@jessica.Stanford.EDU (RL "Bob" Morgan) (01/18/90)
Terry asks: > Personally, I don't see why the existing registration procedures can't > be applied to all port numbers. Are there any significant problems in > doing this? As various other postings about inconsistent use of port numbers on different systems should make clear, we have got to the point where maintaining a universal static list mapping service names to port numbers is as unappealing and difficult as maintaining a universal static list mapping host names to IP addresses. It's an inevitable consequence of the growth in size and diversity of the Internet. The Numbers Czars seem to have stated their limited interest in maintaining such a list by limiting the "official" range to 0-256. (Maybe they're thinking of expanding this?) Clearly, what's needed is a standard mechanism for hosts to access services on other hosts without knowing in advance what ports those services are on. One such mechanism is proposed in RFC-1078, TCPMUX, but unfortunately it only applies to TCP-based services. Sun's portmapper provides this function for services using their RPC protocol. My impression of Hesiod, MIT-Athena's extension to domain name service, is that it performs this function among others. I imagine that such a mechanism could be based on ISO Directory services whenever they become widely available. In the meantime, we'll suffer along as usual. - RL "Bob" Morgan Networking Systems Stanford
casey@gauss.llnl.gov (Casey Leedom) (01/19/90)
| From: stev@VAX.FTP.COM | | Personally, I liked the idea of charging back for the packets:) Don't forget to charge the broadcast storm packets too. And the CPU time stolen from all the machines that were uselessly interrupted.