Subject: LCP interception in the LAC

From: Klausberger Walter <[email-masked]>
Date: Tue, 21 Aug 2001 13:42:34 +0200

Hi,

I think the limited size of an L2TP payload packet over IP is a well known
problem. If you have a PPP link with an MRU of 1500 Byte, you have to
fragment the L2TP packet to get it over UDP/IP/Ethernet and vice versa. This
leads to additional performance requirements in the LAC.

One idea (also listed in Richard Shea's book regarding L2TP, page 159ff) is
the interception and manipulation of LCP packets in the LAC in case of LNS
and client end-to-end negotiation in order to lower the MRU. Is this quite
common practice, because I really don't like the idea? Isn't it task of the
LNS to negotiate a lower MRU and set it's own PPP interface MTU to a lower
value, so that a whole PPP packet can be sent within one
L2TP/UDP/IP/Ethernet frame? Fragmentation and defragmentation is thus done
at LNS and Client.

regards
- walter

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 21 Aug 2001 14:54:24 +0200

> and client end-to-end negotiation in order to lower the MRU. Is this quite

I don't know of any implementations that do a full replication of LCP as
suggested in Rich's book, but I certainly could wrong (please let me know if I
am!). If done correctly, neither the LNS nor the client would ever know it was
being done. I *have* heard of some implementations doing some light "sniffing"
and manipulation of LCP parameters in transit (though this is not necessarily a
recommended practice).

As an aside, this is reminiscent of the ISDN terminal adapter days where MLPPP
was negotiated in the adapter because the most widely deployed PC OS could not
do PPP multilink. The PC thought it was doing regular single serial line PPP
over an RS232 interface, but the adapter was doing 2 channel MLPPP on the other
side. When it worked, it was a nifty gadget that served a reasonable purpose
given the state of affairs at the time, when it didn't it caused all sorts of
interoperability headaches!

> L2TP/UDP/IP/Ethernet frame? Fragmentation and defragmentation is thus done

Ideally, the LAC and LNS is configured with an MRU that will be negotiated with
the PPP client such that fragmentation will never occur. This requires good
network management of MRU/MTU across segments.

Also, the LAC may participate in PMTU discovery by sending an ICMP unreachable
to the client suggesting that it reduce its MTU.

---

From: Bill Baumann <[email-masked]>
Date: Tue, 21 Aug 2001 08:58:30 -0700 (PDT)

Hello Walter,

One should expect the the LNS will behave well.  However, unless I'm
mistaken, there isn't any specification that requires the LNS choose a
reasonable MRU.  For a general purpose LAC implementation, I think its a
good idea to monitor LCP negotiations and intercept when required.  My
Linux open source LAC does this with minor modifications to Linux's stock
ppp (www.ratdevil.com/l2tp).

Bill Baumann