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

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?

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

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

---

From: Archie Cobbs <[email-masked]>
Date: Wed, 02 Apr 2003 08:34:10 -0800

> or if PMTU was not enabled at all.

That's true.. although this falls under "what normally happens"
rather than "what is required". E.g., there's nothing that
says that a host can't initiate another PMTU discovery
every 3 minutes if it wants to.

> unfragmented packet size in the L2TP pipe may differ from 

The problem is that you don't control your PPP MTU, the peer
does, and the peer is allowed to reject any values greater
than 1500 bytes if it wants to. So the local configuration
only sets an upper limit, not a lower limit in effect.

> or side effects when doing this?

There are two levels at which IP fragmentation can happen, on the
inner IP packet and on the outer IP packet. Outer packet fragments
are a potential performance hit but otherwise not a problem. But
if the inner IP packet must be fragmented - because you're not
doing multi-link and your MTU for the L2TP link is too small for
the original packet plus overhead - then your L2TP router is
required to fragment the IP packet or send back an ICMP "must
fragment" response if DF is set.

You could avoid "inner" IP fragmentation if your L2TP link MTU
were large enough, but your MTU setting is at the mercy of the
remote PPP peer, because it is allowed to reject anything larger
than 1500 bytes (and typically the inner IP packet is up to 1500
bytes because it came from an Ethernet port). So you can't avoid
this possibility in general.

If you're talking about a UNIX type device, then you would normally
configure the L2TP interface to have an MTU of 1460 (or whatever)
so that the kernel handles the fragmentation and ICMP stuff for you.

With multi-link PPP, inner IP fragmentation is no longer necessary
as you can fragment at the PPP frame level instead.

So in summary:

- You must be prepared to fragment and/or send ICMP "must fragment"
   packets (don't forget to decrement TTL's too)
- Life gets easier if you enable multi-link PPP (even with just
   one link)
- Life gets easier if you can get the peer to accept a large
   enough MTU for the L2TP link, but don't count on it.

FYI, WinXP is "friendlier" than earlier versions of Windows
on these points...

>       again to try to determine if the path has changed.

You want to avoid having the application timeout.. it's much better to
have all routers able to send ICMP "need fragmentation" packets and
all intermediate firewalls not block these packets.

Hope this helps.

-Archie

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

---

From: Archie Cobbs <[email-masked]>
Date: Wed, 02 Apr 2003 08:34:10 -0800

So in summary:

Hope this helps.

-Archie