Subject: [L2tpext] fragmentation and MRU setting in L2TPv2 scenarios

From: [email-masked]
Date: Tue, 1 Apr 2003 15:29:45 +0100

Colleagues,

I have observed problems regarding the treatment of packets 
with DF bit set in L2TPv2 architectures. Unfortunately the
statement in the RFC 2661 is not too verbose:

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

I also saw a document "draft-ietf-pwe3-fragmentation-00.txt"
but this also appears not to answer my questions.

I have formulated several questions below, that might help
to clarify the problem and possible solutions to it.

a) consider a dial setup similar to the following:

client ----- LAC ------ LNS
  |---------ppp---------|

Due to required L2TP overhead fragmentation
of packets larger than 1460 bytes should happen
no matter what the MRU/MTU settings on client, LAC
or LNS are. This is true, if the DF bit is not set
in the packet. Normally only testing applications
should actively prevent fragmention using the DF Bit.

However there are some applications (e.g ftp server) 
and clients in the internet that set the DF bit in requests 
or responses. I think they should not do that (except if 
it is for testing), but they do and customers use those 
applications. This generally does not cause problems if the 
packet size transported without fragmentation
is 1500. But we've seen problems when L2TP is used as
some of the data packets are between 1460 and 1500 
bytes and some applications stop communication, if they 
are lost.

Q: Can You confirm that L2TP implementations should always 
care for the DF bit and drop too large packets (+ return an
ICMP)? 

Q: Can You confirm that the setting of the MRU on the
LNS does not matter with respect to fragmentation as 
long as it is => the maximum tunnel width for data of 
1460 bytes?

Q: Are there any best-practice workarounds if a broken
application continues to set the DF bit in its packets
and uses packet sizes between 1460 and 1500?

b) consider a DSL setup similar to the following:

client ---atmPVC--- LAC ------ LNS
  |---------ppp-----------------|

In this scenario we might have considerably larger
maximum packet sizes between client and LNS than
1500, e.g. 1572. Then appearantly the MRU setting 
on the LNS has impact as it might be lower than the 
otherwise maximum width of the pipe. 

Q: Can L2TP transport packet sizes > 1500?

Q: Are there any reasons to set a lower MRU than
1500 on the LNS, if the overall width of the tunnel pipe
is e.g. 1572? 

best regards & thank You for Your help!

Andreas
_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext

---

From: [email-masked]
Date: Wed, 2 Apr 2003 10:38:07 +0100

Archie,

thank You for helping to reduce my confusion ;-)
it's getting less but still a few things:

> The DF flag is set as a normal part of TCP's path-MTU
> discovery process:

sure, but I thought it should not be set in any normal
application data packet, once the path is discovered
or if PMTU was not enabled at all.

> If peer A's MRU is < peer B's MTU, then there is a bug
> in somebody's PPP stack, as PPP negotiation should never
> allow this to happen.

The negotiated MRU/MTU value agreed on by both sides could 
still be larger than the actual maximum packet size for 
unfragmented transport over the wire. My interpretation of 
the PPP logs I have seen is that negotiation usally only depends 
on the (manual) settings on both sides. The actual maximum 
unfragmented packet size in the L2TP pipe may differ from 
the negotiated value.
The question is now whether it makes sense to adapt the settings
of the MRU on the LNS and/or LAC (used as proposal for PPP negotiation) 
to the maximum unfragmented packet size. Or are there any caveats
or side effects when doing this?

> The application is not broken. Probably a firewall somewhere
> is blocking the ICMP "need fragmentation" packets from getting
> back to the application. See http://www.faqs.org/rfcs/rfc2923.html

I understand that an application using PMTU sends periodically large 
packets with the DF bit set. However I'm not sure, whether these testing
packets are already normal data packets or just ICMP trials BEFORE
actually sending data. One way or another I understand now, that
the problem only happens if the application has PMTU enabled and 
does not have a timeout mechanism as described in RFC 2923

   How to fix
      TCP should notice that the connection is timing out.  After
      several timeouts, TCP should attempt to send smaller packets,
      perhaps turning off the DF flag for each packet.  If this
      succeeds, it should continue to turn off PMTUD for the connection
      for some reasonable period of time, after which it should probe
      again to try to determine if the path has changed.

best regards

Andreas