[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:
>
>http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-01
>
>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
usage.
>
> - 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
application.
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:
>
>http://www.isi.edu/touch/pubs/draft-touch-tcp-portnames-00.txt
>
>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
>layer-by-layer.
If I understand what you mean by "some indication" I would have to
say no it is not required.
Take care,
John
>
>Joe
More information about the end2end-interest
mailing list