--54u2kuW9sGWg/X+X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, May 28, 2004 at 03:14:48PM -0700, Jason Thorpe wrote:
> I guess that has to happen to handle your A-B=3DC-D case properly is for=
=20
> {B,C} to manufacture a NEEDS FRAG packet for {A,D} upon reception of=20
> one corresponding to the tunnel.

This sounds... ugly.. and impossible! We might like to fabricate the
initial NEEDS FRAG when we receive one for the tunnel, because it's by
extension of processing the original packet - but by this stage we no
longer have the original packet from which to generate the ICMP.

I think it should keep a per-SA record of the MTU across the SA, and
update that accordingly. Then NEEDS FRAG's get generated appropriately
later when A/D send something too large for the new smaller tunnel.

> Sigh, if our IPsec tunnel implementation actually created netif=20
> instances then it would be a simple matter of cranking down the MTU of=20
> that interface when a NEEDS FRAG message was received on the outer=20
> shell of the tunnel it corresponds to.  Then everything else would just=
=20
> figure it out.
>=20
> However, we could also certainly change our IPsec tunnel data structure=
=20
> to hold the same type of MTU information, and consult it, as well.

Right.

--
Dan.



--54u2kuW9sGWg/X+X
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (NetBSD)

iD8DBQFAt70YEAVxvV4N66cRAqvgAJ9uM05xacxYTwrpWIouuAy11SL0AgCgw2/N
YNUGMsZT0HO36u0dXU23xeU=
=/u+w
-----END PGP SIGNATURE-----

--54u2kuW9sGWg/X+X--