[e2e] Port numbers in the network layer?

[John Day]

The question is why is a protocol-id field required in some protocols 
and not others.

If it is to identify the protocol in the layer above, then how many 
thousand SCTP instances can I identify on top of a single IP 
instance.  If it identifies the protocol, then that should be 
possible.  Obviously it isn't what it is intended for.

Knowing what kind of protocol it is is not required for multiplexing. 
All that is needed is to distinguish different collections of related 
packets. sometimes called "flows" or "connections."  So while an 
additional multiplexing field might be useful, it would be more 
useful if wasn't tied to the kind of protocol.

In protocols with port-ids, there is no need to know what protocol is 
encapsulated (and interestingly there are no protocol-id fields in 
these protocols) because the ends of the flow were involved in 
creating the port-ids and hence know what to expect when packets are 
delivered on that port-id.

That would seem to indicate that the purpose of the Protocol-id field 
is to identify the syntax of the protocol being encapsulated so that 
the receiver knows how to interpret (at least some of) the data in 
the packets that are delivered to it.  If it is also used as another 
multiplexing field that is secondary.

Take care,
John

At 9:34 PM -0400 4/24/13, dpreed at reed.com wrote:
>John & Bob -  I don't concur.  The value of having a protocol ID 
>that is separate from port numbers is that there *is* a namespace 
>that allows alternative multiplexing/demultiplexing models in the 
>overall internetwork.  And one obvious (but by no means the 
>simplest) example is the potential to create namespaces that are 
>much larger and more stable than the 16 bits currently allocated for 
>port numbers.
>
>
>
>This was *all* screwed up when NAT was allowed to happen (rather 
>than fixing the shortage of routable addresses by doing IPv6 
>quickly).   NAT was a disaster because it conflated port numbers 
>with endpoint names for autonomous destinations.
>
>
>
>At the time, I was told that "NAT was temporary", and that one 
>should not worry about the companies that proposed it as an IETF 
>standard.  It was not "standards track".  But Cisco, in particular, 
>sidelined Scott Deering away from its commercial planning, and put 
>some product managers in charge, who felt no desire to evolve using 
>IETF processes, and (like Chambers), just wanted to go "proprietary" 
>to lock in dominance that they had achieved.
>
>
>
>Of course, NAT was not temporary - it was Milo Medin and @Home that 
>wanted to charge per-device in a home that created architectural 
>warts all over the place, including the idea that "port numbers" 
>could be blocked to attempt to prevent "servers in the home".
>
>
>
>So it really had little to do with thoughtful architecture or the 
>IETF.  That period was when IETF lost its way completely, not 
>understanding what the vendors were attempting to do by balkanizing 
>the design space and eliminating interoperability as much as they 
>dared.
>
>
>
>But back to the main point: the protocol number has served a role 
>precisely because it allows higher level multiplexing to be extended 
>and evolved.  Had all protocols had port numbers, that flexibility 
>would have been lost.  There's no obvious reason why, for example, 
>that SCTP should have the same port number space as TCP, and 
>certainly UDP's demultiplexing is quite different from TCP, even if 
>the field size is the same - we don't send UDP datagrams to the same 
>place that we send TCP segments, and ICMP would not be able to talk 
>to a protocol-independent "control plane", but instead would be 
>delivered to the endpoints.
>
>
>
>One of the key things about the Internet design was its openness to 
>unanticipated future evolution, without asking for "permission" from 
>a standards committee like 3GPP.  That played out in the 
>demultiplexing layer.  Not all hosts are "operating systems" that 
>look like TENEX or Unix, and have those goals, so the demultiplexing 
>and packet parsing goals might not have anything to do with 
>"processes" logged into a machine.
>
>
>
>Of course, if your view is that you just design a protocol from a 
>clean slate, and then throw it away and start again from a new clean 
>slate - you can wean the design down to a highly brittle framework 
>that does *exactly* what you plan for, and nothing more.  That way 
>you get SNA, with 8-bit addresses and protocols for every device 
>type that don't have any commonality.
>
>
>
>Caveat: Joe Touch prevents me from posting.
>
>
>
>
>
>On Wednesday, April 24, 2013 7:55am, "John Day" <jeanjour at comcast.net> said:
>
>  > After delving into it fairly deeply, it is clear that port-ids are
>>  the crucial piece required for proper (and useful) layer isolation.
>>
>>  Decoupling port allocation from synchronization as indicated by
>>  Watson's work is key in constructing a well-formed layer. Watson
>>  clearly recognized the importance of distinguishing port-ids (a local
>>  handle) from Connection-endpoint-ids (CEP-ids that are carried in
>>  protocol).
>>
>>  Both the Internet and the OSI Models conflate port allocation and
>>  synchronization and so have one identifier where two are required.
>>  Cleanly distinguishing them has major implications for security. A
>>  layer without port-ids leads to all sorts of problems, the least of
>>  which are the so-called protocol-id fields to identify the syntax of
>>  the encapsulated header.
>>
>>  Take care,
>>  John
>>
>>  At 12:24 PM -0700 4/23/13, Bob Braden wrote:
>>  >During the development of TCP during the 1977-1980 period, the
>>  >original C&K TCP layer was divided into a transport layer (TCP) and
>>  >an internetwork layer (IP). One of the key decisions in this split
>>  >was which layer should inherit the port numbers. At the time I
>>  >simply accepted the group decision to put ports into the transport
>>  >layer without taking time to think through the architectural
>>  >implications. Has anyone ever thought through how the architecture
>>  >would have been changed had ports ended up in the internetwork
>>  >layer, i.e., in IP?
>>  >
>>  >Bob Braden
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130425/6b7125a0/attachment.html