5. Protocol Considerations
Several aspects of operation over L2F, while outside the realm of the
protocol description itself, serve to clarify the operation of L2F.
5.1 PPP Features
Because L2F in operation carries uninterpreted frames, it permits
operation of features without explicit knowledge of these features.
For instance, if a PPP session is carried, L2F is simply transporting
HDLC frames. The two PPP endpoints can negotiate higher-level
features, such as reliable link, compression, multi-link, or
encryption. These features then operate between the two PPP
endpoints (the dial-in client on one end, and the Home Gateway on the
other), with L2F continuing to simply ship HDLC frames back and
forth.
For similar reasons, PPP echo requests, NCP configuration
negotiation, and even termination requests, are all simply tunneled
HDLC frames.
5.2 Termination
As L2F simply tunnels link-layer frames, it does not detect frames
like PPP TERMREQ. L2F termination in these scenarios is driven from
a protocol endpoint; for instance, if a Home Gateway receives a
TERMREQ, its action will be to "hang up" the PPP session. It is the
responsibility of the L2F implementation at the Home Gateway to
convert a "hang up" into an L2F_CLOSE action, which will shut down
client's session in the tunnel cleanly. L2F_CLOSE_WHY and
L2F_CLOSE_STR may be included to describe the reason for the
shutdown.
5.3 Extended Authentication
L2F is compatible with both PAP and CHAP protocols. SLIP does not
provide authentication within the protocol itself, and thus requires
an ASCII exchange of username and password before SLIP is started.
L2F is compatible with this mode of operation as well.
One-time password cards have become very common. To the extent the
NAS can capture and forward the one-time password, L2F operation is
compatible with password cards. For the most general solution, an
arbitrary request/response exchange must be supported. In an L2F
environment, the protocol must be structured so that the NAS can
detect the apparent identity of the user and establish a tunnel
connection to the Home Gateway, where the arbitrary exchange can
occur.
5.4 MNP4 and Apple Remote Access Protocol
L2F appears compatible with Apple's ARAP protocol. Its operation
under L2F has not been described simply because this experimental RFC
does not have a corresponding implementation of such operation.
5.5 Operation of IP and UDP
L2F tries to be self-describing, operating at a level above the
particular media over which it is carried. However, some details of
its connection to media are required to permit interoperable
implementations. This section describes the issues which have been
found when operating L2F over IP and UDP.
L2F uses the well-known UDP port 1701 [4]. The entire L2F packet,
including payload and L2F header, is sent within a UDP datagram. The
source and destination ports are the same (1701), with demultiplexing
being achieved using CLID values. It is legal for the source IP
address of a given CLID to change over the life of a connection, as
this may correspond to a peer with multiple IP interfaces responding
to a network topology change. Responses should reflect the last
source IP address for that CLID.
IP fragmentation may occur as the L2F packet travels over the IP
substrate. L2F makes no special efforts to optimize this. A NAS
implementation MAY cause its LCP to negotiate for a specific MRU,
which could optimize for NAS environments in which the MTUs of the
path over which the L2F packets are likely to travel have a
consistent value.
6.0 Acknowledgments
L2F uses a packet format inspired by GRE [5]. Thanks to Fred Baker
for consultation, Dave Carrel for consulting on security aspects, and
to Paul Traina for philosophical guidance.
7.0 References
[1] Romkey, J., "A Nonstandard for Transmission of IP Datagrams over
Serial Lines: SLIP", RFC1055, June 1988.
[2] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC1661, July 1994.
[3] Simpson, W., "PPP in HDLC-like Framing", STD 51,, RFC1662,
July 1994.
[4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC1700,
October 1994.
[5] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing
Encapsulation (GRE)", RFC1701, October 1994.
8.0 Security Considerations
Security issues are discussed in Section 3.1.
9.0 Authors' Addresses
Tim Kolar
Cisco Systems
170 West Tasman Drive
San Jose CA 95134-1706
EMail: tkolar@cisco.com
Morgan Littlewood
Cisco Systems
170 West Tasman Drive
San Jose CA 95134-1706
EMail: littlewo@cisco.com
Andy Valencia
Cisco Systems
170 West Tasman Drive
San Jose CA 95134-1706
EMail: valencia@cisco.com
9.0 Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.