Assigned numbers.

[Michael H. Warfield]

Andrew Tridgell enscribed thusly:
> >   Port 42:   It appears as though this is being used for WINS replication. 
> >              Any truth to the rumor?

> >   name             42/tcp    Host Name Server
> >   name             42/udp    Host Name Server
> >   nameserver       42/tcp    Host Name Server
> >   nameserver       42/udp    Host Name Server

	Aaaauuuugggghhhhh!!!!  It arises from the dead!

> that's a new one for me.

	No...  Not a new one at all.  An old one.  An evil one.  "The star
stones must have come unstuck" one (for H.P. Lovecraft fans)...  :-)

	The "nameserver" or "hostname" service is an OLD service that has
been obsolete for longer than I've been involved with TCP/IP (almost 15
years now?  Gees, I'm getting old...)  It's listed back in several RFC's
that actually have only 3 digits!  (start at 961 and work your way through
the "obsoleted by" list until you end up at 1011).  It has it's roots in
IEN 116 which described what amounted to a "what's in your host file" type
protocol.

	This is from RFC 1011...  I think it says it best.  It describes
what this thing was, what its problems were and the fact that it was
abandoned in favor of the DNS.  RFC 1011 is dated 1987...  Nuff said.

]    Host Name Server Protocol  ----------------------------- (NAMESERVER)
] 
]       STATUS:  Experimental
] 
]       SPECIFICATION:  IEN 116 (in DPH)
] 
]       COMMENTS:
] 
]          Provides machine oriented procedure for translating a host name
]          to an Internet Address.
] 
]          This specification has significant problems:  1) The name
]          syntax is out of date.  2) The protocol details are ambiguous,
]          in particular, the length octet either does or doesn't include
]          itself and the op code.  3) The extensions are not supported by
]          any known implementation.
] 
]          This protocol is now abandoned in favor of the DOMAIN protocol.
]          Further implementations of this protocol are not advised.
] 
]          Please discuss any plans for implementation or use of this
]          protocol with the contact.

	It's unfortunate that once a port is allocated, even to a protocol
which never had a snowball's chance in hell, it becomes difficult (or
nearly impossible) to call it back or retire it.  This one has been around
long enough to be called ancient.  We have a recent candidate in the SMTPS
(SMTP over SSL) which was allocated and then almost immediately withdrawn.
Not fast enough before Microsoft decided to stick it into exchange and
outlook, though...

	Unfortunately, IANA's assigned numbers list does not have a column
or an annotation that says "This number is assigned but this is a bad
thing - don't do this".

> >   Port 135:  This is listed as a DCE/RPC termination port.  Is this being
> >              used by the NT DCE/RPC stuff at all?

> >   epmap           135/tcp    DCE endpoint resolution
> >   epmap           135/udp    DCE endpoint resolution

> it is used, but I don't know exactly what for. I've seen packets to it
> though.

> >   Ports 137, These are assigned for both tcp & udp.  It appears, however,

> It seems that the IANA always does that. When I asked for a port for
> rsync they gave me UDP as well as TCP even though I only asked for
> TCP.

	That's now official policy buried on their web pages (or maybe it's
in the application for a port assignment) somewhere.  I vaguely remember
some confusion or some problems many years ago when two different services
got allocated the same port number, one on UDP and one on TCP.

> >                       "Set if this message was truncated because the
> >                        datagram carrying it would be greater than
> >                        576 bytes in length.  Use TCP to get the
> >                        information from the NetBIOS Name Server."

> I don't believe the MS implementations do this. Anyone see it?


	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw at WittsEnd.com
  (The Mad Wizard)      |  (770) 925-8248   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!