In message <BLUPR05MB1985F5F2BB3118362C67B921AED50@xxxxxxxxxxxxxxxxxxxxxxxxxxx. 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@xxxxxxxx On Behalf Of Alexey Eromenko > Sent: Sunday, February 07, 2016 7:47 AM > To: ietf <ietf@xxxxxxxx> > 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@xxxxxxx