Re: Is Fragmentation at IP layer even needed ?

[Joe Touch <[e-mail]>]

On 2/11/2016 10:19 AM, Phillip Hallam-Baker wrote:
> On Thu, Feb 11, 2016 at 12:58 PM, Joe Touch <[e-mail]> wrote:
>>
>>
>> On 2/11/2016 6:05 AM, Masataka Ohta wrote:
>>> Joe Touch wrote:
>>>
>>>> I repeat: nodes that encap or decap are acting as sources or sinks, not
>>>> relays.
>>>
>>> I'm afraid firewalls are relays.
>>
>> A firewall that filters on L3 is a router regardless of which side you
>> look at.
> 
> Using 'layers' to describe Internet architecture can be very
> misleading because the Internet isn't layered according to the ISO
> model and the layers don't necessarily stack up the way people expect
> once tunneling is involved.

Internet layers correspond to ISO layers up through 4 fairly well.

Layers have always been relative, though - what I think is layer 4 might
be layer 2 to you if you're using my UDP to transit your IP inside.

> For example, if I have an SSH channel to a system (or a TLS firewall),
> I have a transport layer protocol that is presenting a packet layer
> interface.
>
> So if we number the layers, we have 1, 2, 3, 4, 5, 3 [4, 5, 7].

Strictly, you have two different views:

	SSH [1, 2, 3, 4, 5] acting as [1* 2*] to the transit protocol.

	The complete SSH view is:

		[1, 2, 3, 4, 5, 7#] where 7# is the transit
		(where the transit acts as an application)

	The complete transit view is:

		[1*, 2*, 3, 4, 5, 7], where 2* is a tunnel (which *is*
		just a link) and 1* is virtual

SSH needs to treat the transit as an application.

The transit needs to treat SSH as a link (including support, if needed,
for ARP, MTU discovery, etc.)

> One of the things I learned early on programming Microsoft BASIC was
> to not use sequential line numbers. And I was really glad to get rid
> of line numbers when I moved to machines with decent amounts of RAM.
> Seems to me that the numbered layer model confuses rather than
> clarifies and especially so when tunneling is being discussed.

Once you move to tunnels you need to think in relative terms, not absolutes.

> A tunnel should be a tunnel.

A tunnel *is* (and always has been) a link.

The only difference between a tunnel and a link is that a link is a
special subset of "all tunnels that run over physical connections".

> If you fragment at the tunnel ingress,
> you should defragment at the egress. Otherwise you are simply pushing
> your state maintenance requirements onto the receiving endpoint in a
> way that isn't scaleable.

The beauty of considering a tunnel a link is that the same rules apply,
as they always should have. Just as a link that can't transit an IP
packet requires frag/reassembly within the link (e.g., ATM does this),
so should a tunnel.

Joe