Re: [Spud] Putting Network-Layer Information in the Network Layer

[Joe Touch <[e-mail]>]

On 7/20/2015 4:30 AM, Brian Trammell wrote:
> 
>> On 10 Jul 2015, at 18:19, Tom Herbert <[e-mail]> wrote:
>>
>>> Coming back to the layering question:
>>>
>>> It does seem to me that what we're (the we that wrote the two 
>>> documents starting this thread) trying to do is explicitly
>>> reinforce the boundary between the network layer and the
>>> transport layer, where this is defined as "things the path needs
>>> to see versus things only endpoints need to see". Asking nicely
>>> (i.e., publishing RFCs) did not work in this case: the transport
>>> ports are de facto part of the network layer now, and short of
>>> blowing the Internet up and starting over I can't see a way to
>>> get them back. So now we are left with enforcing the boundary 
>>> cryptographically, leaving some space in the "new network layer"
>>> (in this case, IP + UDP (for ports) + SPUD) for those things now
>>> commonly done within the network.
>>>
>> This "new network layer" breaks down at fragmentation.
> 
> One can argue (indeed, I do) that in-network fragmentation is
> essentially a deprecated feature of the network layer.

If you think that network devices need to see transport ports, then it
doesn't matter where the fragmentation occurs. Source fragmentation -
which is still very much a part of the network layer, and needs to be* -
causes just as much of a problem.

> The current
> version of IP doesn't support it, and AFAICT avoiding fragmentation is
> current practice in modern transport protocol design.

In-network, yes. Source, no.

>> Only the first
>> fragment carries port numbers and the embedded network layer
>> information in the payload. Other fragments will carry neither, but
>> still can carry IP options, DSCP, TTL, ECN marking, flow labels in
>> IPv6.
>>
>> An alternate possibility would be to embed IP options within UDP. So a
>> packet might look like IP-UDP-IP options-payload.
> 
> This is an intriguing possibility, if there is an advantage to reusing IP options handling code.
> 
>> This allows us to
>> use native options (say in our data center where we can control
>> things), but maybe to use embedded IP options in UDP on paths in the
>> Internet where we see options are being dropped. SFC-in-UDP
>> (https://tools.ietf.org/html/draft-kumar-sfc-nsh-udp-transport-00)
>> proposes a similar model,
> 
> It looks a lot like innerspace (http://tools.ietf.org/html/draft-briscoe-tcpm-inner-space-01), too.

Yes and no. UDP has a length field, which means it's actually possible
to use space in an IP payload that isn't part of the UDP frame without
compliant UDP implementations breaking.

That's the real issue with innerspace; it's inside the TCP payload.

Joe