[e2e] Port numbers in the network layer?
touch at isi.edu
Fri Apr 26 17:42:52 PDT 2013
On 4/26/2013 3:30 PM, John Day wrote:
> 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.
In the Internet, the IP addresses are part of that connection ID, called
the socket pair.
>> - 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.
No protocol has a "means" to initiate connection with anything that
isn't waiting for it on the other end. In this case, it would be an
application listening on the socket. The assumption is both that the
application is listening AND that the service (application protocol) is
>> 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.
You have to have agreement on the method for doing that. Otherwise
you're assigning meaning to bit patterns arbitrarily or reading minds.
> 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.
The portname is the name of the protocol and the application you expect
to interpret it on the other end, just as a destination port is.
Yes, the resulting connections still use the current socket pair as the
connection identifier, and yes, that still includes IP addresses. This
was intended to be compatible with the existing Internet architecture,
as noted therein.
>> 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
> 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. ;-)
That's the feature of such a version field.
>> Similarly we could allocate a new ethertype to "IPv4:TCP" or "IPv4:SCTP".
> What about IPv4:TCP1 thru IPv4:TCP1000?
I was clearly trying to extrapolate only different protocol stack
combinations. If you're referring to variants of TCP, those could either
be in a single ethertype or 1000 different ones. If you're referring to
specific connections, that's a different semantic that doesn't map to my
example about ethertypes.
>> 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.
"some indication" means either a preexisting agreement at the endpoints
or a label either in-band or out-of-band. You can't differentiate
various types of stack combinations without any information.
More information about the end2end-interest