[65690] in North American Network Operators' Group
Re: MTU path discovery and IPSec
daemon@ATHENA.MIT.EDU (Valdis.Kletnieks@vt.edu)
Thu Dec 4 23:51:20 2003
To: crist.clark@globalstar.com
Cc: Joe Maimon <jmaimon@ttec.com>, nanog@merit.edu
In-Reply-To: Your message of "Thu, 04 Dec 2003 17:22:23 PST."
<3FCFDDCF.B08A473D@globalstar.com>
From: Valdis.Kletnieks@vt.edu
Date: Thu, 04 Dec 2003 23:50:33 -0500
Errors-To: owner-nanog-outgoing@merit.edu
--==_Exmh_-1915522584P
Content-Type: text/plain; charset=us-ascii
On Thu, 04 Dec 2003 17:22:23 PST, Crist Clark said:
> Excerise for the reader:
>
> Devise an algorthm that will take an arbitrarily sized packet 20-65535
> octets and an arbitrarily sized MTU, > 576 octets, and split the
> packet into the minimum number of "n" fragments where each fragment is
> (1) less than the MTU, (2) no two fragments differ by more than 8 octets,
> and the fragments obey the IP fragmentation rules, (3) data payload must
> end on an 8-octet boundary for all but the last fragment and (4) each
> fragment has an exact copy of the original header except for differences
> in the fragmentation fields and checksum.
> Compare to the algorithm of cutting the data in to "m" (mtu - ip_hl)-
> chunks and putting the leftovers into the final fragment.
Then re-read rfc792:
The ICMP messages typically report errors in the processing of
datagrams. To avoid the infinite regress of messages about messages
etc., no ICMP messages are sent about ICMP messages. Also ICMP
messages are only sent about errors in handling fragment zero of
fragemented datagrams. (Fragment zero has the fragment offeset equal
zero).
and think which is more likely to silently fail - fragmenting a 1500 byte
packet 750/750, or 1430/70, if the *second* frag is in possible danger
of being lost due to buffer congestion or similar?
--==_Exmh_-1915522584P
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001
iD8DBQE/0A6ZcC3lWbTT17ARAvaKAKCJpTKHXEjCHsL3KmjGQd5ytMh6nACgnuZ3
DHE2Jxe4MlI2jsiLBi7lsp8=
=3RE1
-----END PGP SIGNATURE-----
--==_Exmh_-1915522584P--
