<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: [e2e] Port numbers in the network
layer?</title></head><body>
<div>The question is why is a protocol-id field required in some
protocols and not others.</div>
<div><br></div>
<div>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.&nbsp; If it identifies the protocol, then that should be
possible.&nbsp; Obviously it isn't what it is intended for.</div>
<div><br></div>
<div>Knowing what kind of protocol it is is not required for
multiplexing.&nbsp; All that is needed is to distinguish different
collections of related packets. sometimes called &quot;flows&quot; or
&quot;connections.&quot;&nbsp; So while an additional multiplexing
field might be useful, it would be more useful if wasn't tied to the
kind of protocol.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.&nbsp; If it is also used as
another multiplexing field that is secondary.</div>
<div><br></div>
<div>Take care,</div>
<div>John</div>
<div><br></div>
<div>At 9:34 PM -0400 4/24/13, dpreed@reed.com wrote:</div>
<blockquote type="cite" cite><font face="Times New Roman">John &amp;
Bob -&nbsp; I don't concur.&nbsp; 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.&nbsp; 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.</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">This was
*all* screwed up when NAT was allowed to happen (rather than fixing
the shortage of routable addresses by doing IPv6 quickly).&nbsp;&nbsp;
NAT was a disaster because it conflated port numbers with endpoint
names for autonomous destinations.</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">At the time,
I was told that &quot;NAT was temporary&quot;, and that one should not
worry about the companies that proposed it as an IETF standard.&nbsp;
It was not &quot;standards track&quot;.&nbsp; 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
&quot;proprietary&quot; to lock in dominance that they had
achieved.</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">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 &quot;port numbers&quot; could be
blocked to attempt to prevent &quot;servers in the
home&quot;.</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">So it really
had little to do with thoughtful architecture or the IETF.&nbsp; 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.</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">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.&nbsp; Had all protocols had port numbers, that flexibility
would have been lost.&nbsp; 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 &quot;control plane&quot;, but instead would be
delivered to the endpoints.</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">One of the
key things about the Internet design was its openness to unanticipated
future evolution, without asking for &quot;permission&quot; from a
standards committee like 3GPP.&nbsp; That played out in the
demultiplexing layer.&nbsp; Not all hosts are &quot;operating systems&quot;
that look like TENEX or Unix, and have those goals, so the
demultiplexing and packet parsing goals might not have anything to do
with &quot;processes&quot; logged into a machine.</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman"><br></font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">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.&nbsp; That way you get
SNA, with 8-bit addresses and protocols for every device type that
don't have any commonality.</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">Caveat: Joe
Touch prevents me from posting.</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman"><br>
<br>
On Wednesday, April 24, 2013 7:55am, &quot;John Day&quot;
&lt;jeanjour@comcast.net&gt; said:</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">&gt; After
delving into it fairly deeply, it is clear that port-ids are<br>
&gt; the crucial piece required for proper (and useful) layer
isolation.<br>
&gt;<br>
&gt; Decoupling port allocation from synchronization as indicated
by<br>
&gt; Watson's work is key in constructing a well-formed layer.
Watson<br>
&gt; clearly recognized the importance of distinguishing port-ids (a
local<br>
&gt; handle) from Connection-endpoint-ids (CEP-ids that are carried
in<br>
&gt; protocol).<br>
&gt;<br>
&gt; Both the Internet and the OSI Models conflate port allocation
and<br>
&gt; synchronization and so have one identifier where two are
required.<br>
&gt; Cleanly distinguishing them has major implications for security.
A<br>
&gt; layer without port-ids leads to all sorts of problems, the least
of<br>
&gt; which are the so-called protocol-id fields to identify the syntax
of<br>
&gt; the encapsulated header.<br>
&gt;<br>
&gt; Take care,<br>
&gt; John<br>
&gt;<br>
&gt; At 12:24 PM -0700 4/23/13, Bob Braden wrote:<br>
&gt; &gt;During the development of TCP during the 1977-1980 period,
the<br>
&gt; &gt;original C&amp;K TCP layer was divided into a transport layer
(TCP) and<br>
&gt; &gt;an internetwork layer (IP). One of the key decisions in this
split<br>
&gt; &gt;was which layer should inherit the port numbers. At the time
I<br>
&gt; &gt;simply accepted the group decision to put ports into the
transport<br>
&gt; &gt;layer without taking time to think through the
architectural<br>
&gt; &gt;implications. Has anyone ever thought through how the
architecture<br>
&gt; &gt;would have been changed had ports ended up in the
internetwork<br>
&gt; &gt;layer, i.e., in IP?<br>
&gt; &gt;<br>
&gt; &gt;Bob Braden<br>
&gt;<br>
&gt;</font></blockquote>
<div><br></div>
</body>
</html>