In message
<BLUPR05MB1985F5F2BB3118362C67B921AED50(_at_)BLUPR05MB1985(_dot_)namprd05(_dot_)prod.
outlook.com>, Ronald Bonica writes:
Hi Alexey,
This question comes up every few years. The short answer is:
- The vast majority of Internet traffic rides over TCP or UDP
- Generally speaking, traffic that rides over TCP does not rely
on IP fragmentation
- However, traffic the rides over UDP absolutely relies on IP
fragmentation
So, as things stand, IP fragmentation is required to support UDP.
However, the conversation doesnt end at that.
Operational experience has taught us that IPv6 fragmentation does not
work so well. Unlike IPv4, IPv6 encodes fragmentation information in an
IPv6 extension header. Sadly, many operators discard packets containing
that extension header. So, as specified, IPv6 provides fragmentation
services, but as deployed, it does not.
Actually fragmentation works well unless you have a firewall that
drops fragments. When they are not being deliberately blocked the
packets get through and are reassembled. It is also not many
operators. It is some operators.
Additionally there is zero reasons why firewalls can't open <src,
dst, frag offset != 0> when they open <src, dst, proto, src port,
dst port> for reply traffic for those that are paranoid about just
letting all non-zero fragment offset through. I just let the
non-zero offset fragments through.
You might get a few extra packet through.
Many end-stations work around this problem by sending packets no longer
that the IPv6 minimum MTU (1280 bytes). This ensures that IPv6
fragmentation services will never be required. However, it also prevents
applications and networks from realizing the benefits of larger packets.
So, the internet community has the following options:
1) Live with the status quo / Send only packets < 1280 bytes
a. Say nothing in the standards about the issue, beyond what has
already been said
b. Write an RFC informing developers of UDP applications of the
problem and advising them not to rely on protocol MTU > 1280
c. Deprecate IPv6 fragmentation
2) Fix the problem / Allow end-stations to send larger packets
a. Convince operators not to drop fragmented packets
b. Design a UDP replacement that provides fragmentation service and
migrate UPD applications to the replacement protocol
Options 2a and 2b may not achievable, because they require action on the
part of many, many parties. So, we seem to be stuck with Options 1a, 1b
and 1c.
In light of this, your original question is not only appropriate, it is
telling.
Ron
From: ietf mailto:ietf-bounces(_at_)ietf(_dot_)org On Behalf Of Alexey
Eromenko
Sent: Sunday, February 07, 2016 7:47 AM
To: ietf <ietf(_at_)ietf(_dot_)org>
Subject: Is Fragmentation at IP layer even needed ?
Hi All,
I'm re-evaluating TCP/IP stack again with my ongoing IP-FF research.
My question: Is packet fragmentation at IP layer even needed ?
Basically here are few possibilities:
1. Fragmentation-and-reassembly at every hop. (I don't know if anybody
implements it)
2. IPv4 style-fragmentation -- fragmentation per every hop, reassembly at
destination end.
3. IPv6-style-fragmentation -- fragmentation only at source end,
reassembly at destination end.
4. No fragmentation at all (the advantage here: faster Router processing
vs #1 or #2 and less implementation bugs); Assuming standard packet size
is defined at 1280 bytes, like in IPv6
5. MTU path discovery via ICMP -- RFC-1981
6. MTU path discovery via TCP (or other Transport) -- RFC-4821 (or other
way)
I'm leaning towards 4 + 6 solution in my own protocol, IP-FF.
What do you think ?
Should IP layer provide fragmentation ?
--
-Alexey Eromenko "Technologov"
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka(_at_)isc(_dot_)org