Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation
RFC 3437

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 07

Network Working Group                                          W. Palter
Request for Comments: 3437                                       zev.net
Category: Standards Track                                    W. Townsley
                                                           Cisco Systems
                                                           December 2002

              Layer-Two Tunneling Protocol Extensions for
                 PPP Link Control Protocol Negotiation

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document defines extensions to the Layer Two Tunneling Protocol
   (L2TP) for enhanced support of link-specific Point to Point Protocol
   (PPP) options.  PPP endpoints typically have direct access to the
   common physical media connecting them and thus have detailed
   knowledge about the media that is in use.  When the L2TP is used, the
   two PPP peers are no longer directly connected over the same physical
   media.  Instead, L2TP inserts a virtual connection over some or all
   of the PPP connection by tunneling PPP frames over a packet switched
   network such as IP.  Under some conditions, an L2TP endpoint may need
   to negotiate PPP Link Control Protocol (LCP) options at a location
   which may not have access to all of the media information necessary
   for proper participation in the LCP negotiation.  This document
   provides a mechanism for communicating desired LCP options between
   L2TP endpoints in advance of PPP LCP negotiation at the far end of an
   L2TP tunnel, as well as a mechanism for communicating the negotiated
   LCP options back to where the native PPP link resides.

Palter & Townsley           Standards Track                     [Page 1]
RFC 3437        L2TP Extensions for PPP LCP Negotiation    December 2002

Table of Contents

   1. Introduction...............................................  2
     1.1 Specification of Requirements...........................  3
   2. LCP Options From LAC to LNS................................  3
     2.1 LCP Want Options (iccn, occn)...........................  4
     2.2 LCP Allow Options (iccn, occn)..........................  6
     2.3 LCP Options From LNS to LAC.............................  7
   3. Security Considerations....................................  8
   4. IANA Considerations........................................  8
   5. Normative References.......................................  8
   6. Author's Addresses.........................................  9
   7. Full Copyright Statement................................... 10

1. Introduction

   L2TP [RFC2661] provides a very limited amount of guidance to the LNS
   as to what type of interface a tunneled PPP session arrived on at an
   LAC.  Such information is limited to whether the interface was
   "synchronous" or "asynchronous", "digital" or "analog."  These
   indications provide some guidance when negotiating PPP LCP at the
   LNS, but they are not as robust as they could be.

   This document defines a more robust way to inform the LAC of LCP
   negotiated options, and provides guidance to the LNS on the limits
   and values that the LAC requires during LCP negotiation.  Deep
   knowledge of PPP [RFC1661] and L2TP [RFC2661] are expected for the
   remainder of this document.

   L2TP Proxy LCP allows options to be negotiated where the native PPP
   link resides, thus circumventing issues with ACCM, Alternate FCS, and
   other LCP Options that the LNS would not necessarily know how to
   properly negotiate without access to the physical media for the
   native PPP connection, interface type, or configuration.  However,
   use of Proxy LCP introduces other problems as well as there are
   options within LCP PPP negotiation which should be set or adjusted by
   the LNS, such as the PPP Authentication Type and MRU.  Finally, the
   PPP Client may reinitiate LCP negotiation at any time, and unless the
   LAC is sniffing every PPP data packet it forwards, it would not be
   aware that this is even occurring.

   LCP options may be classified into roughly three different categories
   with respect to their affect on L2TP; (1) options which affect
   framing in a way that the LAC may need to know about or handle
   specifically (e.g., ALT-FCS, ACCM, MRU), (2) options that are mostly
   transparent to the LAC (e.g., AUTH-TYPE), and (3) options that the

Palter & Townsley           Standards Track                     [Page 2]
RFC 3437        L2TP Extensions for PPP LCP Negotiation    December 2002

   LAC may wish to influence because they are dependent on the media