Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation
RFC 3437
|
| Document |
Type |
|
RFC - Proposed Standard
(January 2003; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 3437 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Thomas Narten
|
|
IESG note |
|
Published as RFC 3437
|
|
Send notices to |
|
(None)
|
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
Show full document text