Subject: fragmentation

From: "Waters, Stephen" <[email-masked]>
Date: Fri, 14 Jan 2000 13:12:49 -0000

There used to be a lot of text somewhere in the L2TP drafts on fragmentation
and avoiding it by setting the virtual PPP MRU size appropriately.  Is this
being progressed?

Ideally, L2TP should detect the MTU of the underlying IP link (or ATM,
or...).  

In the case where L2TP is protected with IPSEC, the IPSEC architecture calls
for the support of DF propagation and PMTU discovery support. This is not
possible if L2TP has hidden the DF bit in side L2TP and PPP.

In our implementation, L2TP calculates the MTU on the outbound network, and
causes the virtual PPP instances to use an appropriate MRU size - it also
'asks' IPSEC how much overhead will be applied by the request IPSEC
proposal. 

IPSEC can set the DF independently of what L2TP has done, I guess, but
processing 'Too Big' ICMP messages will be hard without the participation of
L2TP.

Is this issue being worked in new drafts?

Cheers, Steve.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 18 Jan 2000 03:53:04 -0800

> and avoiding it by setting the virtual PPP MRU size appropriately.  Is this

Draft 12 and RFC2661 both say:

   IP fragmentation may occur as the L2TP packet travels over the IP
   substrate.  L2TP makes no special efforts to optimize this.  A LAC
   implementation MAY cause its LCP to negotiate for a specific MRU,
   which could optimize for LAC environments in which the MTU's of the
   path over which the L2TP packets are likely to travel have a
   consistent value.

> Is this issue being worked in new drafts?

Not that I know of. In your case you were able to do all of this without
the use of new protocols, etc. This *could* be an additional
recommendation in the spec, but I see no need for it from an
interoperability standpoint as it is all done locally and with existing
mechanisms.

I would be happy to hear suggestions for a more dynamic method as well.
e.g. It seems that your use of PPP would require a renegotiation of LCP
in order to alter the MRU if the PMTU changed during the life of the
session (arguably something that likely does not occur all that often). 

Perhaps there is something that can be done via projection of the DF bit
from the outer to the inner header...