rfc2341.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,513 行 · 第 1/5 页

   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.

   If the Home Gateway accepts the connection, it creates a "virtual
   interface" for SLIP or PPP in a manner analogous to what it would use
   for a direct-dialed connection.  With this "virtual interface" in
   place, link layer frames may now pass over this tunnel in both
   directions.  Frames from the remote user are received at the POP,
   stripped of any link framing or transparency bytes, encapsulated in
   L2F, and forwarded over the appropriate tunnel.

   The Home Gateway accepts these frames, strips L2F, and processes them
   as normal incoming frames for the appropriate interface and protocol.
   The "virtual interface" behaves very much like a hardware interface,
   with the exception that the hardware in this case is physically
   located at the ISP POP.  The other direction behaves analogously,
   with the Home Gateway encapsulating the packet in L2F, and the POP
   stripping L2F before transmitting it out the physical interface to
   the remote user.



Valencia, et. al.               Historic                        [Page 6]

RFC 2341                       Cisco L2F                        May 1998


   At this point, the connectivity is a point-to-point PPP or SLIP
   connection whose endpoints are the remote user's networking
   application on one end and the termination of this connectivity into
   the Home Gateway's SLIP or PPP support on the other.  Because the
   remote user has become simply another dial-up client of the Home
   Gateway access server, client connectivity can now be managed using
   traditional mechanisms with respect to further authorization,
   protocol access, and filtering.

   Accounting can be performed at both the NAS as well as the Home
   Gateway.  This document illustrates some Accounting techniques which
   are possible using L2F, but the policies surrounding such Accounting
   are outside the scope of this specification.

   Because L2F connect notifications for PPP clients contain sufficient
   information for a Home Gateway to authenticate and initialize its LCP
   state machine, it is not required that the remote user be queried a
   second time for CHAP authentication, nor that the client undergo
   multiple rounds of LCP negotiation and convergence.  These techniques
   are intended to optimize connection setup, and are not intended to
   deprecate any functions required by the PPP specification.

3.0 Service Model Issues

   There are several significant differences between the standard
   Internet access service and the Virtual dial-up service with respect
   to authentication, address allocation, authorization and accounting.
   The details of the differences between these services and the
   problems presented by these differences are described below.  The
   mechanisms used for Virtual Dial-up service are intended to coexist
   with more traditional mechanisms; it is intended that an ISP's POP
   can simultaneously service ISP clients as well as Virtual dial-up
   clients.

3.1 Security

   For the Virtual dial-up service, the ISP pursues authentication only
   to the extent required to discover the user's apparent identity (and
   by implication, their desired Home Gateway).  As soon as this is
   determined, a connection to the Home Gateway is initiated with the
   authentication information gathered by the ISP.  The Home Gateway
   completes the authentication by either accepting the connection, or
   rejecting it.

   The Home Gateway must also protect against attempts by third parties
   to establish tunnels to the Home Gateway.  Tunnel establishment
   involves an ISP-to-Home Gateway authentication phase to protect
   against such attacks.



Valencia, et. al.               Historic                        [Page 7]

RFC 2341                       Cisco L2F                        May 1998


3.2 Address Allocation

   For an Internet service, the user accepts that the IP address may be
   allocated dynamically from a pool of Service provider addresses.
   This model often means that the remote user has little or no access
   to their home network's resources, due to firewalls and other
   security policies applied by the home network to accesses from
   external IP addresses.

   For the Virtual dial-up service, the Home Gateway can exist behind
   the home firewall, allocating addresses which are internal (and, in
   fact, can be RFC1597 addresses, or non-IP addresses).  Because L2F
   tunnels exclusively at the frame layer, the actual policies of such
   address management are irrelevant to correct Virtual dial-up service;
   for all purposes of PPP or SLIP protocol handling, the dial-in user
   appears to have connected at the Home Gateway.

3.3 Authentication

   The authentication of the user occurs in three phases; the first at
   the ISP, and the second and optional third at the Home gateway.

   The ISP uses the username to determine that a Virtual dial-up service
   is required and initiate the tunnel connection to the appropriate
   Home Gateway.  Once a tunnel is established, a new MID is allocated
   and a session initiated by forwarding the gathered authentication
   information.

   The Home Gateway undertakes the second phase by deciding whether or
   not to accept the connection.  The connection indication may include
   CHAP, PAP, or textual authentication information.  Based on this
   information, the Home Gateway may accept the connection, or may
   reject it (for instance, it was a PAP request and the
   username/password are found to be incorrect).

   Once the connection is accepted, the Home Gateway is free to pursue a
   third phase of authentication at the PPP or SLIP layer.  These
   activities are outside the scope of this specification, but might
   include an additional cycle of LCP authentication, proprietary PPP
   extensions, or textual challenges carried via a TCP/IP telnet
   session.

3.4 Accounting

   It is a requirement that both the Access gateway and the Home Gateway
   can provide accounting data and hence both may count packets, octets
   and connection start and stop times.




Valencia, et. al.               Historic                        [Page 8]

RFC 2341                       Cisco L2F                        May 1998


   Since Virtual dial-up is an access service, accounting of connection
   attempts (in particular, failed connection attempts) is of
   significant interest.  The Home Gateway can reject new connections
   based on the authentication information gathered by the ISP, with
   corresponding logging.  For cases where the Home Gateway accepts the
   connection and then continues with further authentication, the Home
   Gateway might subsequently disconnect the client.  For such
   scenarios, the disconnection indication back to the ISP may also
   include a reason.

   Because the Home Gateway can decline a connection based on the
   authentication information collected by the ISP, accounting can
   easily draw a distinction between a series of failed connection
   attempts and a series of brief successful connections.  Lacking this
   facility, the Home Gateway must always accept connection requests,
   and would need to exchange a number of PPP packets with the remote
   system.

4.0 Protocol Definition

   The protocol definition for Virtual dial-up services requires two
   areas of standardization:

   +  Encapsulation of PPP packets within L2F.  The ISP NAS and the
      Home gateway require a common understanding of the encapsulation
      protocol so that SLIP/PPP packets can be successfully transmitted
      and received across the Internet.

   +  Connection management of L2F and MIDs.  The tunnel must be
      initiated and terminated, as must MIDs within the tunnel.
      Termination includes diagnostic codes to assist in the diagnosis
      of problems and to support accounting.

   While providing these services, the protocol must address the
   following required attributes:

   +  Low overhead.  The protocol must impose a minimal additional
      overhead.  This requires a compact encapsulation, and a structure
      for omitting some portions of the encapsulation where their
      function is not required.

   +  Efficiency.  The protocol must be efficient to encapsulate and
      deencapsulate.

   +  Protocol independence.  The protocol must make very few
      assumptions about the substrate over which L2F packets are
      carried.




Valencia, et. al.               Historic                        [Page 9]

RFC 2341                       Cisco L2F                        May 1998


   +  Simple deployment.  The protocol must not rely on additional
      telecommunication support (for instance, unique called numbers,
      or caller ID) to operate.

4.1 Encapsulation within L2F

4.1.1 Encapsulation of PPP within L2F

   The PPP packets may be encapsulated within L2F.  The packet
   encapsulated is the packet as it would be transmitted over a physical
   link.  The following are NOT present in the packet:

   + Flags
   + Transparency data (ACCM for async, bit stuffing for sync)
   + CRC

   The following ARE still present:

   + Address and control flags (unless negotiated away by LCP)
   + Protocol value

4.1.2 Encapsulation of SLIP within L2F

   SLIP is encapsulated within L2F in much the same way as PPP.  The
   transparency characters are removed before encapsulating within L2F,
   as is the framing.

4.2 L2F Packet Format

4.2.1 Overall Packet Format

   The entire encapsulated packet has the form:


                 ---------------------------------
                 |                               |
                 |         L2F Header            |
                 |                               |
                 ---------------------------------
                 |                               |
                 |  Payload packet (SLIP/PPP)    |
                 |                               |
                 ---------------------------------
                 |                               |
                 |    L2F Checksum (optional)    |
                 |                               |
                 ---------------------------------




Valencia, et. al.               Historic                       [Page 10]

RFC 2341                       Cisco L2F                        May 1998


4.2.2 Packet Format

   An L2F packet has the form:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|K|P|S|0|0|0|0|0|0|0|0|C| Ver |    Protocol   |Sequence (opt)|\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
|          Multiplex ID         |           Client ID           | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2F
|             Length            |       Offset (opt)            | |Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|                         Key (opt)                             | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
+                                 (payload)                     |
+                             .....                             |
+                             .....                             |
+                             .....                             |
+                                 (payload)                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   L2F Checksum (optional)     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2.3 Version field

   The Ver ("Version") field represents the major version of the L2F
   software creating the packet.  It MUST contain the value 001.

   If Ver holds a value other than 1, or any bits are non-zero after bit
   S but before bit C, this corresponds to a packet containing
   extensions not understood by the receiving end.  The packet is
   handled as an invalid packet as defined in 4.4.1.

4.2.4 Protocol field

   The Protocol specifies the protocol carried within the L2F packet.
   Legal values (represented here in hexadecimal) are:

      Value           Type                   Description