Hi Joe, > -----Original Message----- > From: ietf [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Joe Touch > Sent: Thursday, February 11, 2016 10:35 AM > To: Phillip Hallam-Baker > Cc: IETF Discussion Mailing List > Subject: Re: Is Fragmentation at IP layer even needed ? > > > > On 2/11/2016 10:19 AM, Phillip Hallam-Baker wrote: > > On Thu, Feb 11, 2016 at 12:58 PM, Joe Touch <touch@xxxxxxx> 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. This is coming close to repeating a discussion we had in intarea back in the August 2015 timeframe, where I thought we had reached a conclusion. Thanks - Fred fred.l.templin@xxxxxxxxxx > Joe