Re: [pmtud] I-D ACTION:draft-savola-mtufrag-network-tunneling-00.txt (fwd)

[Michael Richardson <mcr at sandelman.ottawa.on.ca>]

-----BEGIN PGP SIGNED MESSAGE-----


1) you might extend applicability IP-in-IP to many in the abstract.
   might want to add PPPoE situations too.

>   1.  Fragmenting all the big the encapsulated packets to fit in the
(page 2) -- extra word somewhere.

>   4.  Fragmenting the original too big packets so that their fragments
>       will fit, even encapsulated, in the paths, and reassembling them
>       at the destination nodes.  Note that this is only available for
>       IPv4 packets under very specific conditions.

  true. Linux sets fragid=0 when DF=1, for instance.

  At #2, you might want to add reference to MSS-clamping techniques.

3.3.... is this ever actually used?

One of the major contrasts between fragment before encap and fragment
resulting packet has to do with cryptographic overhead. 

If one fragments the resulting packet, then, when a fragment goes
missing, one never does the crypto operation.  In some cases crypto is
way more expensive than fragment management. In other cases, the crypto
has already been provisioned for wire-rate, and buffer management is the
real bottleneck.

I think that I would add the road-warrior (extruded /32) situation to
your list. This is a very common situation, and is not often understood
by network/firewall designers. (i.e. people who are dropping ICMPs)

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr at xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQNCq74qHRg3pndX9AQFGgAP8CUsy7hXIKY250SFjGS7kjxLOLLitt8tw
gjWG7ld0yTAKWbYg9gPGe6BIJxA4YlW8apRTuCk08Es0jscpvkl+ppFHiUYxizu4
/yHq3T/MT4bRFkUMIVmd6fzub9AwH6eiOmMeLPqfrp9c4dUjHIJHub4UKyg6uWZN
snEWzSAX/Y8=
=O42x
-----END PGP SIGNATURE-----

_______________________________________________
pmtud mailing list
pmtud at ietf.org
https://www1.ietf.org/mailman/listinfo/pmtud