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: Archie Cobbs <[email-masked]>
Date: Tue, 01 Apr 2003 08:34:47 -0800

> should actively prevent fragmention using the DF Bit.

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

http://www.google.com/search?q=path+MTU+discovery+TCP&sourceid=mozilla-search&start=0&start=0

> care for the DF bit and drop too large packets (+ return an

Yes; more generally, this is required for all IP routers.

> long as it is => the maximum tunnel width for data of 

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.

Otherwise, yes there should be no problem receiving packets because
they'll all be <= MRU.

> and uses packet sizes between 1460 and 1500?

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

> Q: Can L2TP transport packet sizes > 1500?

Sure, use multi-link PPP and use whatever MRRU setting you want.

-Archie

__________________________________________________________________________
Archie Cobbs     *     Precision I/O      *     http://www.precisionio.com

---

From: Archie Cobbs <[email-masked]>
Date: Tue, 01 Apr 2003 08:34:47 -0800

-Archie