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

[Pekka Savola <pekkas at netcore.fi>]

Sorry for delaying the response..

On Wed, 16 Jun 2004, Michael Richardson wrote:
> 1) you might extend applicability IP-in-IP to many in the abstract.
>    might want to add PPPoE situations too.

I prefer to do deal with in-the-network tunneling only, because this
is a perspective for high-end equipment (non-high-end can just
fragment and reassemble, and work just fine).. and PPPoE and friends 
aren't really used except in the last hop..

That said, I'll include a paragraph on this:

                <t>It is worth noting that most of this discussion
applies to a more generic case, where there exists a link with lower
MTU in the path.  A concrete and widely deployed example of this is
the usage of <xref target="RFC2516">PPP over Ethernet (PPPoE)</xref>
at the customers' access link.  These lower-MTU links, and
particularly PPPoE links, are typically not deployed in topologies
where fragmentation and reassembly might be unfeasible (e.g., a
backbone), so this may be a slightly easier problem. However, this
more generic case is considered out of scope of this memo.</t>

> >   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.

Agreed.  Added:

                <t>A related technique, which works under specific
scenarios only is so-called "MSS clamping".  In that technique or
rather a "hack", the TCP packets' Maximum Segment Size is reduced by
middleboxes so that the TCP connection automatically restricts itself
to the maximum available packet size.  Obviously this does not work
for UDP or other protocols which have no MSS. This approach is most
applicable and used with PPPoE, but could be applied otherwise as
well; the approach also assumes that all the traffic goes through
middleboxes which do MSS clamping -- this is trivial for the
single-homed access links, but could be a challenge otherwise.</t>

 
> 3.3.... is this ever actually used?

Yes.  When you tunnel in the core network, that's practically the only 
choice..
 
> 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 just added this in security considerations, as I'd guess that if 
you'd run high-speed cryptography between two nodes, you'll have to 
have the hardware in any case..:

                        <t>It is worth considering the cryptographic
expense (which is typically more significant than the reassembly, if
done in software) with fragmentation of the inner or outer packet.  
If an outer fragment goes missing, no cryptographic operations have
been yet performed; if an inner fragment goes missing, cryptographic
operations have already been performed.  Therefore, which of these
approaches is preferable also depends on whether cryptography or
reassembly are already provided in hardware; for high-speed routers,
at least, one should be able to assume that if it is performing
relatively heavy cryptography, it already requires hardware support
for it.</t>

 
> 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)

I purposefully excluded this at this point because it seems that there 
is no "in-the-network" tunneling here (but rather, tunneling between 
an end-point (host) and a gateway).  With that in mind, if you have 
suggestions how to address this and how (and where -- an appendix?), 
I'm all ears..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


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