Hi, all,
Here’s the thing about fragmentation:
1. all links have a maximum packet size
2. all tunneling/encapsulation/layering increases payload size
1+2 implies there is always the need for fragmentation at some layer:
3. fragmentation always splits info across packets
And there’s something important about layering:
4. layering intends to isolate the behavior of one layer from another,
such that
it will always be impossible for an upper layer to know exactly what is
going on below,
i.e., to determine that limiting size across an entire path of possibly
virtual tunnels
The next two are where we get into trouble:
5. network devices increasingly WANT to inspect contents beyond the
layer at which they are intended to operate
6. inspecting contents ultimately means reassembly, at some level
Which brings us to the punchline:
7. but network device vendors want to save money, so they don’t want to
reassemble at any layer
So I agree, IP fragmentation has its flaws - but those flaws are created not
only because it leaves out the transport port numbers, but also because DPI and
NAT devices don’t reassemble. And they don’t because it’s cheaper to sell
devices that say they run at 1 Gbps (e.g.) that don’t bother to reassemble.
I.e., it will never matter what layering we add to fix this - GRE, GUE, Aero,
etc. - ultimately, we’re doomed to need fragmentation support down to IP
exactly because:
a. #1-4 mean we need frag/reassembly at any tunnel ingress
b. vendors want to sell #5 at a price that is too low for them to
support #6 (i.e., point #7)
So pushing this to another layer will never solve it. What will solve it will
only be a compliance requirement for #6 - which could be done right now, and
has to be done for ANY solution to work.
NOTE: even rewriting EVERY application won’t fix this, nor will deploying a new
layer at any level.
And yes, I do intend to add this to draft-ietf-tunnels, so it can be referred
to elsewhere.
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
