[165377] in North American Network Operators' Group
Re: IP Fragmentation - Not reliable over the Internet?
daemon@ATHENA.MIT.EDU (Fred Baker (fred))
Mon Sep 2 22:00:31 2013
From: "Fred Baker (fred)" <fred@cisco.com>
To: Owen DeLong <owen@delong.com>
Date: Mon, 2 Sep 2013 06:11:22 +0000
In-Reply-To: <5DEF4DE9-3680-4D47-9FF0-1FC3CED0A816@delong.com>
Cc: North American
Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--Apple-Mail=_AE2FD6D8-5713-41F5-8C3A-1620DD226444
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On Aug 27, 2013, at 12:34 AM, Owen DeLong <owen@delong.com> wrote:
> If I send a packet out as a legitimate series of fragments, what is =
the chance
> that they will get dropped somewhere in the middle of the path between =
the
> emitting host and the receiving host?
>=20
> To my thinking, the answer to that question is basically "pretty close =
to 0 and
> if that changes in the core, very bad things will happen."
I mostly agree. I will argue that the actual path of an IP datagram is =
end to end, so the question is not the core, but the end to end path.
That said, with today's congestion control algorithms, TCP does pretty =
badly with an other-than-negligible loss rate, so end to end, fragmented =
messages have a negligible probability of being dropped, so the =
probability of sending a message that is fragmented and having it arrive =
at the intended destination is a negligibly small probability smaller =
than then probability of sending an unfragmented message and having it =
arrive.
The primary argument against that is firewall behavior, in which =
firewalls are programmed to drop fragments with high probability.
If we had a protocol that sat atop IP and did what fragmentation does =
that we could expect all non-TCP/SCTP protocols to use, I would have a =
very different viewpoint. But, playing the ball where it lies, the =
primary change I would recommend would be to support any firewall rule =
that permitted dropping the first fragment of a fragmented datagram in =
which the first fragment did NOT include the entire IP header and the =
entire subsequent header, and expecting a host to keep a fragment of a =
datagram no more than some stated number of seconds (I might pick "two") =
with express permission to drop it more rapidly should the need arise. I =
would *not* support a rule that simple dropped fragments, or a protocol =
change that disallowed them.
--Apple-Mail=_AE2FD6D8-5713-41F5-8C3A-1620DD226444
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iD8DBQFSJCwFbjEdbHIsm0MRApEtAKD+BOYEWKm+P7JV9BDl+vzHiNOSdwCgrWT8
atEUAVaZfh2MMhQ1fNgagrs=
=wvUH
-----END PGP SIGNATURE-----
--Apple-Mail=_AE2FD6D8-5713-41F5-8C3A-1620DD226444--
