[e2e] Port numbers in the network layer?

John Day jeanjour at comcast.net
Fri Apr 26 15:30:11 PDT 2013

At 11:46 AM -0700 4/25/13, Joe Touch wrote:
>One issue is the need for ports; there's a summary of that here:
>Its use evolved to overload:
>	- part of the stream identifier used to associate groups
>	of packets (with IP addresses)

The source and destination port-ids form a 
connection(flow)-identifier.  There had been experimentation with 
this in various protocols at the time.  Some had a single field, 
where the source numbered from one end and the destination from the 
other end hoping they would not meet in the middle.  The idea of 
simply concatenating locally unique identifiers became the common 

>	- an identifier for the upper layer protocol (service)
>	(the dest port, in all UDP packets or in the TCP SYN)

Actually, it does not identify the upper protocol or application, but 
a path to the upper protocol or application.  It is significant that 
this identified the type but there was no means (unless application 
specific) to establish communication with a particular instance of an 

The use as a so-called well-known port was carried over from an early 
ARPANET shortcut.  This is equivalent to the early OS practice of 
reserving memory locations in low memory as jump points for 
applications.  OSs got beyond this. Networks never did.

As the reference above indicates there was consideration of names for 
applications and a "telephone book" or directory, which corroborates 
that most of us knew well-known ports were a kludge when we did them 
40 years ago.  It is just too bad, they weren't retired when we had a 
chance to.  As I have said, they are the OS equivalent of jump points 
in low memory!  How incredibly primitive!  ;-)  That was a bad idea 
in OSs even way back when I started!!

>FWIW, one way to decouple these two was described here:
>It seems fairly clear that a layered architecture needs agreement on 
>what the layers are. Indications of a particular layer sequence can 
>occur anywhere - in band at any layer, or out of band.

Actually it doesn't.  A complete layered architecture can create 
layers on the fly as necessary.  Actually this proposal would have 
still made them rooted on the IP address, i.e. the portname was a 
path to the application, not the name of the application.

>Consider that ethernet ethertype 0x0800 was originally intended to 
>mean "IP", allowing the IP version number to be determined at the IP 
>layer, but packet demuxing efficiency concerns resulted in a new 
>ethertype for IPv6 (0x86DD). So the ethertype includes not only the 
>upper layer protocol, but it's redundant with the version at the 
>next layer.

Or perhaps IEEE was noting that since the only common fields between 
IPv4 and IPv6 was the version field that for all practical purposes 
they were different protocols. ;-)

>Similarly we could allocate a new ethertype to "IPv4:TCP" or "IPv4:SCTP".

What about IPv4:TCP1 thru IPv4:TCP1000?

>So any "mix and match" architecture needs to have some indication of 
>what the particular mix is, but it need not be cascaded 

If I understand what you mean by "some indication" I would have to 
say no it is not required.

Take care,


More information about the end2end-interest mailing list