[e2e] Port numbers in the network layer?

[Joe Touch]

Hi, John,

On 5/2/2013 4:42 PM, John Day wrote:
...
>>> The argument for the pseudoheader has always been a bit shaky.  No other
>>> Transport Protocol except UDP either within or outside the IETF found
>>> the need for it.  There have been many discussions about removing it,
>>> but as you know tradition has always won out.
>>
>> The pseudoheader is an artifact of the TCP/IP split, which isn't as
>> clean as often claimed.
>>
>> It is used in other transport protocols built on IP, e.g., DCCP and SCTP.
>>
>> It is not a matter of tradition; it is deeply entrenched with the
>> notion of endpoint and that this notion exists at two different layers
>> that share at least some of the context (IP addresses).
>
> "Deeply entrenched," indeed. (Some would say a synonym for tradition.)
> Strongly reasoned, less so.  As recently described by its author, it is
> this binding that thwarts mobility.
>
> Indeed this "notion" exists in two different layers. In fact, it is a
> general property of all layers.  But I fail to see how that is an
> argument to require a pseudo-header.

It's an argument that it IS required in all current Internet transports. 
It is NOT an argument that it has to be required in a new transport 
protocol in the Internet, or in other new stacks.

...
>>>>> According to this socket pair definition then, is the connection id a
>>>>> Network Layer identifier or a Transport Layer identifier?
>>>>
>>>> Transport layer ID that is based on a transport header that subsumes a
>>>> subset of the network header.
>>>
>>> Huh?  Next you are going to tell me that it is "small, green and split
>>> three ways"!  ;-)
>>
>> The transport layer flow is *defined* as the socket pair, which is
>> defined in TCP (and used in other Internet transports) as combining
>> the transport header context (port pair) with the IP context (IP
>> address pair), the latter of which is part of the pseudoheader for
>> that reason.
>
> I realize this is the definition, and I would even agree with including
> the same error-check-code, if they were in the same layer. But since it
> is said they aren't, I fail to see the need and I definitely see the
> constraints.
>
> Is there some condition in which a router might put a TCP packet on a
> different IP packet?  The only reason I can see for having it.

A router should never do anything to the contents of an IP payload, IMO.

However, isn't that the definition of how a NAT works?

...
>> So I interpret "protocol-id" as I think most people do.
>
> Excellent. That was my point.  The field has the wrong name.

Yes, but when we're talking about existing protocols, the name is there. 
New protocols might use more accurate terms, just as IPv6 has a 
"hopcount" instead of a "TTL".

...
> If there was a "protocol-instance-id" I would think it would be more
> useful if one left the protocol out of it entirely.  Of course, then it
> would be a port-id.  ;-)

The destination port ID in a SYN encodes the service protocol, which is 
a protocol-type-id. It isn't an instance-id; the instance-id is the 
combination of the IP addresses and port numbers taken as a set.

>>> Why does the receiver need to know the type of protocol?  Perhaps so it
>>> knows how to interpret the header in the layer above?
>>
>> Yes, that's what I said several times ;-)
>
> Excellent! then you agree!  The purpose of the protocol-id field in IP
> is identify the syntax of the encapsulated protocol.

Yes. Same for the destination port of the initial SYN in TCP.

...
> Good discussion, Joe.

Back at ya' ;-)

Joe