rfc2341.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,513 行 · 第 1/5 页
TXT
1,513 行
Network Working Group A. Valencia
Request for Comments: 2341 M. Littlewood
Category: Historic T. Kolar
Cisco Systems
May 1998
Cisco Layer Two Forwarding (Protocol) "L2F"
Status of Memo
This memo describes a historic protocol for the Internet community.
It does not specify an Internet standard of any kind. Distribution
of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
Virtual dial-up allows many separate and autonomous protocol domains
to share common access infrastructure including modems, Access
Servers, and ISDN routers. Previous RFCs have specified protocols
for supporting IP dial-up via SLIP [1] and multiprotocol dial-up via
PPP [2]. This document describes the Layer Two Forwarding protocol
(L2F) which permits the tunneling of the link layer (i.e., HDLC,
async HDLC, or SLIP frames) of higher level protocols. Using such
tunnels, it is possible to divorce the location of the initial dial-
up server from the location at which the dial-up protocol connection
is terminated and access to the network provided.
Table of Contents
1.0 Introduction 3
1.1 Conventions 3
2.0 Problem Space Overview 3
2.1 Initial Assumptions 3
2.2 Topology 4
2.3 Virtual dial-up Service - a walk-though 5
3.0 Service Model Issues 7
3.1 Security 7
3.2 Address allocation 8
3.3 Authentication 8
3.4 Accounting 8
4.0 Protocol Definition 9
4.1 Encapsulation within L2F 10
4.1.1 Encapsulation of PPP within L2F 10
Valencia, et. al. Historic [Page 1]
RFC 2341 Cisco L2F May 1998
4.1.2 Encapsulation of SLIP within L2F 10
4.2 L2F Packet Format 10
4.2.1 Overall Packet Format 10
4.2.2 Packet Header 11
4.2.3 Version field 11
4.2.4 Protocol field 11
4.2.5 Sequence Number 12
4.2.6 Packet Multiplex ID 12
4.2.7 Client ID 13
4.2.8 Length 13
4.2.9 Packet Checksum 13
4.2.10 Payload Offset 14
4.2.11 Packet Key 14
4.2.12 Packet priority 14
4.3 L2F Tunnel Establishment 14
4.3.1 Normal Tunnel Negotiation Sequence 15
4.3.2 Normal Client Negotiation Sequence 17
4.4 L2F management message types 18
4.4.1 L2F message type: Invalid 18
4.4.2 L2F_CONF 19
4.4.3 L2F_OPEN, tunnel establishment 20
4.4.4 L2F_OPEN, client establishment 20
4.4.5 L2F_CLOSE 22
4.4.6 L2F_ECHO 22
4.4.7 L2F_ECHO_RESP 23
4.5 L2F Message Delivery 23
4.5.1 Sequenced Delivery 23
4.5.2 Flow Control 23
4.5.3 Tunnel State Table 24
4.5.4 Client State Table 25
5.0 Protocol Considerations 26
5.1 PPP Features 26
5.2 Termination 26
5.3 Extended Authentication 26
5.4 MNP4 and Apple Remote Access Protocol 27
5.5 Operation over IP/UDP 27
6.0 Acknowledgments 27
7.0 References 27
8.0 Security Considerations 28
9.0 Authors' Addresses 28
10.0 Full Copyright Statement 29
Valencia, et. al. Historic [Page 2]
RFC 2341 Cisco L2F May 1998
1.0 Introduction
The traditional dial-up network service on the Internet is for
registered IP addresses only. A new class of virtual dial-up
application which allows multiple protocols and unregistered IP
addresses is also desired on the Internet. Examples of this class of
network application are support for privately addressed IP, IPX, and
AppleTalk dial-up via SLIP/PPP across existing Internet
infrastructure.
The support of these multiprotocol virtual dial-up applications is of
significant benefit to end users and Internet Service providers as it
allows the sharing of very large investments in access and core
infrastructure and allows local calls to be used. It also allows
existing investments in non-IP protocol applications to be supported
in a secure manner while still leveraging the access infrastructure
of the Internet.
It is the purpose of this RFC to identify the issues encountered in
integrating multiprotocol dial-up services into an existing Internet
Service Provider's Point of Presence (hereafter referred to as ISP
and POP, respectively), and to describe the L2F protocol which
permits the leveraging of existing access protocols.
1.1. Conventions
The following language conventions are used in the items of
specification in this document:
o MUST, SHALL, or MANDATORY -- This item is an absolute
requirement of the specification.
o SHOULD or RECOMMEND -- This item should generally be followed
for all but exceptional circumstances.
o MAY or OPTIONAL -- This item is truly optional and may be
followed or ignored according to the needs of the implementor.
2.0 Problem Space Overview
In this section we describe in high level terms the scope of the
problem that will be explored in more detail in later sections.
2.1 Initial Assumptions
We begin by assuming that Internet access is provided by an ISP and
that the ISP wishes to offer services other than traditional
registered IP address based services to dial-up users of the network.
Valencia, et. al. Historic [Page 3]
RFC 2341 Cisco L2F May 1998
We also assume that the user of such a service wants all of the
security facilities that are available to him in a dedicated dial-up
configuration. In particular, the end user requires:
+ End System transparency: Neither the remote end system nor his
home site hosts should require any special software to use this
service in a secure manner.
+ Authentication as provided via dial-up PPP CHAP or PAP, or through
other dialogs as needed for protocols without authentication
(e.g., SLIP). This will include TACACS+ and RADIUS solutions as
well as support for smart cards and one-time passwords. The
authentication should be manageable by the user independently of
the ISP.
+ Addressing should be as manageable as dedicated dial-up solutions.
The address should be assigned by the home site and not the ISP.
+ Authorization should be managed by the home site as it would in a
direct dial-up solution.
+ Accounting should be performed both by the ISP (for billing
purposes) and by the user (for charge-back and auditing).
2.2 Topology
Shown below is a generic Internet with Public switched Telephone
Network (PSTN) access (i.e., async PPP via modems) and Integrated
Services Digital Network (ISDN) access (i.e., synchronous PPP
access). Remote users (either async PPP or SLIP, or ISDN) will
access the Home LAN as if they were dialed into the Home Gateway,
although their physical dial-up is via the ISP Network Access Server.
Valencia, et. al. Historic [Page 4]
RFC 2341 Cisco L2F May 1998
...----[L]----+---[L]-----...
|
|
[H]
|
________|________________________
| |
________|__ ______|________
| | | |
| PSTN [R] [R] ISDN |
| Cloud | | Cloud [N]__[U]
| | Internet | |
| | [R] |
[N]______[R] |_____________|
| | |
| | |
[U] |________________________________|
[H] = Home Gateway
[L] = Home LAN(s)
[R] = Router
[U] = Remote User
[N] = ISP Network Access Server ("NAS")
2.3 Providing Virtual dial-up Services - a walk-through
To motivate the following discussion, this section walks through an
example of what might happen when a Virtual dial-up client initiates
access.
The Remote User initiates a PPP connection to an ISP via either the
PSTN or ISDN. The Network Access Server (NAS) accepts the connection
and the PPP link is established.
The ISP undertakes a partial authentication of the end system/user
via CHAP or PAP. Only the username field is interpreted to determine
whether the user requires a Virtual dial-up service. It is
expected-- but not required--that usernames will be structured (e.g.
littlewo@cisco.com). Alternatively, the ISP may maintain a database
mapping users to services. In the case of Virtual dial-up, the
mapping will name a specific endpoint, the Home Gateway.
If a virtual dial-up service is not required, standard access to the
Internet may be provided.
Valencia, et. al. Historic [Page 5]
RFC 2341 Cisco L2F May 1998
If no tunnel connection currently exists to the desired Home Gateway,
one is initiated. L2F is designed to be largely insulated from the
details of the media over which the tunnel is established; L2F
requires only that the tunnel media provide packet oriented point-
to-point connectivity. Obvious examples of such media are UDP, Frame
Relay PVC's, or X.25 VC's. Details for L2F operation over UDP are
provided in section 5.5. The specification for L2F packet formats is
provided in section 4.2, and the message types and semantics starting
in section 4.4.
Once the tunnel exists, an unused Multiplex ID (hereafter, "MID") is
allocated, and a connect indication is sent to notify the Home
Gateway of this new dial-up session. The Home Gateway either accepts
the connection, or rejects. Rejection may include a reason
indication, which may be displayed to the dial-up user, after which
the call should be disconnected.
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?