rfc2341.txt
来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,585 行 · 第 1/5 页
TXT
1,585 行
Network Working Group A. ValenciaRequest for Comments: 2341 M. LittlewoodCategory: 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 10Valencia, 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 29Valencia, et. al. Historic [Page 2] RFC 2341 Cisco L2F May 19981.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. The initial setup notification may include the authentication information required to allow the Home Gateway to authenticate the user and decide to accept or decline the connection. In the case of CHAP, the set-up packet includes the challenge, username and raw response. For PAP or text dialog (i.e., for SLIP users), it includes username and clear text password. The Home Gateway may choose to use this information to complete its authentication, avoiding an additional cycle of authentication. For PPP, the initial setup notification may also include a copy of the the LCP CONFACKs sent in each direction which completed LCP negotiation. The Home Gateway may use this information to initialize its own PPP state (thus avoiding an additional LCP negotiation), or it may choose to initiate a new LCP CONFREQ exchange.⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?