home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2341.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  66.6 KB  |  1,628 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         A. Valencia
  8. Request for Comments: 2341                                  M. Littlewood
  9. Category: Historic                                               T. Kolar
  10.                                                             Cisco Systems
  11.                                                                  May 1998
  12.  
  13.  
  14.               Cisco Layer Two Forwarding (Protocol) "L2F"
  15.  
  16. Status of Memo
  17.  
  18.    This memo describes a historic protocol for the Internet community.
  19.    It does not specify an Internet standard of any kind.  Distribution
  20.    of this memo is unlimited.
  21.  
  22. Copyright Notice
  23.  
  24.    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  25.  
  26. Abstract
  27.  
  28.    Virtual dial-up allows many separate and autonomous protocol domains
  29.    to share common access infrastructure including modems, Access
  30.    Servers, and ISDN routers.  Previous RFCs have specified protocols
  31.    for supporting IP dial-up via SLIP [1] and multiprotocol dial-up via
  32.    PPP [2].  This document describes the Layer Two Forwarding protocol
  33.    (L2F) which permits the tunneling of the link layer (i.e., HDLC,
  34.    async HDLC, or SLIP frames) of higher level protocols.  Using such
  35.    tunnels, it is possible to divorce the location of the initial dial-
  36.    up server from the location at which the dial-up protocol connection
  37.    is terminated and access to the network provided.
  38.  
  39. Table of Contents
  40.  
  41.    1.0 Introduction                                                3
  42.    1.1 Conventions                                                 3
  43.    2.0 Problem Space Overview                                      3
  44.    2.1 Initial Assumptions                                         3
  45.    2.2 Topology                                                    4
  46.    2.3 Virtual dial-up Service - a walk-though                     5
  47.    3.0 Service Model Issues                                        7
  48.    3.1 Security                                                    7
  49.    3.2 Address allocation                                          8
  50.    3.3 Authentication                                              8
  51.    3.4 Accounting                                                  8
  52.    4.0 Protocol Definition                                         9
  53.    4.1 Encapsulation within L2F                                   10
  54.    4.1.1 Encapsulation of PPP within L2F                          10
  55.  
  56.  
  57.  
  58. Valencia, et. al.               Historic                        [Page 1]
  59.  
  60. RFC 2341                       Cisco L2F                        May 1998
  61.  
  62.  
  63.    4.1.2 Encapsulation of SLIP within L2F                         10
  64.    4.2 L2F Packet Format                                          10
  65.    4.2.1 Overall Packet Format                                    10
  66.    4.2.2 Packet Header                                            11
  67.    4.2.3 Version field                                            11
  68.    4.2.4 Protocol field                                           11
  69.    4.2.5 Sequence Number                                          12
  70.    4.2.6 Packet Multiplex ID                                      12
  71.    4.2.7 Client ID                                                13
  72.    4.2.8 Length                                                   13
  73.    4.2.9 Packet Checksum                                          13
  74.    4.2.10 Payload Offset                                          14
  75.    4.2.11 Packet Key                                              14
  76.    4.2.12 Packet priority                                         14
  77.    4.3 L2F Tunnel Establishment                                   14
  78.    4.3.1 Normal Tunnel Negotiation Sequence                       15
  79.    4.3.2 Normal Client Negotiation Sequence                       17
  80.    4.4 L2F management message types                               18
  81.    4.4.1 L2F message type: Invalid                                18
  82.    4.4.2 L2F_CONF                                                 19
  83.    4.4.3 L2F_OPEN, tunnel establishment                           20
  84.    4.4.4 L2F_OPEN, client establishment                           20
  85.    4.4.5 L2F_CLOSE                                                22
  86.    4.4.6 L2F_ECHO                                                 22
  87.    4.4.7 L2F_ECHO_RESP                                            23
  88.    4.5 L2F Message Delivery                                       23
  89.    4.5.1 Sequenced Delivery                                       23
  90.    4.5.2 Flow Control                                             23
  91.    4.5.3 Tunnel State Table                                       24
  92.    4.5.4 Client State Table                                       25
  93.    5.0 Protocol Considerations                                    26
  94.    5.1 PPP Features                                               26
  95.    5.2 Termination                                                26
  96.    5.3 Extended Authentication                                    26
  97.    5.4 MNP4 and Apple Remote Access Protocol                      27
  98.    5.5 Operation over IP/UDP                                      27
  99.    6.0 Acknowledgments                                            27
  100.    7.0 References                                                 27
  101.    8.0 Security Considerations                                    28
  102.    9.0 Authors' Addresses                                         28
  103.    10.0 Full Copyright Statement                                  29
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Valencia, et. al.               Historic                        [Page 2]
  115.  
  116. RFC 2341                       Cisco L2F                        May 1998
  117.  
  118.  
  119. 1.0 Introduction
  120.  
  121.    The traditional dial-up network service on the Internet is for
  122.    registered IP addresses only.  A new class of virtual dial-up
  123.    application which allows multiple protocols and unregistered IP
  124.    addresses is also desired on the Internet. Examples of this class of
  125.    network application are support for privately addressed IP, IPX, and
  126.    AppleTalk dial-up via SLIP/PPP across existing Internet
  127.    infrastructure.
  128.  
  129.    The support of these multiprotocol virtual dial-up applications is of
  130.    significant benefit to end users and Internet Service providers as it
  131.    allows the sharing of very large investments in access and core
  132.    infrastructure and allows local calls to be used.  It also allows
  133.    existing investments in non-IP protocol applications to be supported
  134.    in a secure manner while still leveraging the access infrastructure
  135.    of the Internet.
  136.  
  137.    It is the purpose of this RFC to identify the issues encountered in
  138.    integrating multiprotocol dial-up services into an existing Internet
  139.    Service Provider's Point of Presence (hereafter referred to as ISP
  140.    and POP, respectively), and to describe the L2F protocol which
  141.    permits the leveraging of existing access protocols.
  142.  
  143. 1.1. Conventions
  144.  
  145.    The following language conventions are used in the items of
  146.    specification in this document:
  147.  
  148.       o   MUST, SHALL, or MANDATORY -- This item is an absolute
  149.           requirement of the specification.
  150.  
  151.       o   SHOULD or RECOMMEND -- This item should generally be followed
  152.           for all but exceptional circumstances.
  153.  
  154.       o   MAY or OPTIONAL -- This item is truly optional and may be
  155.           followed or ignored according to the needs of the implementor.
  156.  
  157. 2.0 Problem Space Overview
  158.  
  159.    In this section we describe in high level terms the scope of the
  160.    problem that will be explored in more detail in later sections.
  161.  
  162. 2.1 Initial Assumptions
  163.  
  164.    We begin by assuming that Internet access is provided by an ISP and
  165.    that the ISP wishes to offer services other than traditional
  166.    registered IP address based services to dial-up users of the network.
  167.  
  168.  
  169.  
  170. Valencia, et. al.               Historic                        [Page 3]
  171.  
  172. RFC 2341                       Cisco L2F                        May 1998
  173.  
  174.  
  175.    We also assume that the user of such a service wants all of the
  176.    security facilities that are available to him in a dedicated dial-up
  177.    configuration.  In particular, the end user requires:
  178.  
  179.    +  End System transparency: Neither the remote end system nor his
  180.       home site hosts should require any special software to use this
  181.       service in a secure manner.
  182.  
  183.    +  Authentication as provided via dial-up PPP CHAP or PAP, or through
  184.       other dialogs as needed for protocols without authentication
  185.       (e.g., SLIP).  This will include TACACS+ and RADIUS solutions as
  186.       well as support for smart cards and one-time passwords.  The
  187.       authentication should be manageable by the user independently of
  188.       the ISP.
  189.  
  190.    +  Addressing should be as manageable as dedicated dial-up solutions.
  191.       The address should be assigned by the home site and not the ISP.
  192.  
  193.    +  Authorization should be managed by the home site as it would in a
  194.       direct dial-up solution.
  195.  
  196.    +  Accounting should be performed both by the ISP (for billing
  197.       purposes) and by the user (for charge-back and auditing).
  198.  
  199. 2.2 Topology
  200.  
  201.    Shown below is a generic Internet with Public switched Telephone
  202.    Network (PSTN) access (i.e., async PPP via modems) and Integrated
  203.    Services Digital Network (ISDN) access (i.e., synchronous PPP
  204.    access).  Remote users (either async PPP or SLIP, or ISDN) will
  205.    access the Home LAN as if they were dialed into the Home Gateway,
  206.    although their physical dial-up is via the ISP Network Access Server.
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Valencia, et. al.               Historic                        [Page 4]
  227.  
  228. RFC 2341                       Cisco L2F                        May 1998
  229.  
  230.  
  231.            ...----[L]----+---[L]-----...
  232.                          |
  233.                          |
  234.                         [H]
  235.                          |
  236.                  ________|________________________
  237.                  |                                |
  238.          ________|__                        ______|________
  239.          |         |                        |             |
  240.          |  PSTN  [R]                      [R]  ISDN      |
  241.          |  Cloud  |                        |   Cloud    [N]__[U]
  242.          |         |             Internet   |             |
  243.          |         |                       [R]            |
  244.          [N]______[R]                       |_____________|
  245.           |      |                                |
  246.           |      |                                |
  247.          [U]     |________________________________|
  248.  
  249.  
  250.       [H] = Home Gateway
  251.       [L] = Home LAN(s)
  252.       [R] = Router
  253.       [U] = Remote User
  254.       [N] = ISP Network Access Server ("NAS")
  255.  
  256. 2.3 Providing Virtual dial-up Services - a walk-through
  257.  
  258.    To motivate the following discussion, this section walks through an
  259.    example of what might happen when a Virtual dial-up client initiates
  260.    access.
  261.  
  262.    The Remote User initiates a PPP connection to an ISP via either the
  263.    PSTN or ISDN.  The Network Access Server (NAS) accepts the connection
  264.    and the PPP link is established.
  265.  
  266.    The ISP undertakes a partial authentication of the end system/user
  267.    via CHAP or PAP.  Only the username field is interpreted to determine
  268.    whether the user requires a Virtual dial-up service.  It is
  269.    expected-- but not required--that usernames will be structured (e.g.
  270.    littlewo@cisco.com).  Alternatively, the ISP may maintain a database
  271.    mapping users to services.  In the case of Virtual dial-up, the
  272.    mapping will name a specific endpoint, the Home Gateway.
  273.  
  274.    If a virtual dial-up service is not required, standard access to the
  275.    Internet may be provided.
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Valencia, et. al.               Historic                        [Page 5]
  283.  
  284. RFC 2341                       Cisco L2F                        May 1998
  285.  
  286.  
  287.    If no tunnel connection currently exists to the desired Home Gateway,
  288.    one is initiated.  L2F is designed to be largely insulated from the
  289.    details of the media over which the tunnel is established; L2F
  290.    requires only that the tunnel media provide packet oriented point-
  291.    to-point connectivity.  Obvious examples of such media are UDP, Frame
  292.    Relay PVC's, or X.25 VC's.  Details for L2F operation over UDP are
  293.    provided in section 5.5.  The specification for L2F packet formats is
  294.    provided in section 4.2, and the message types and semantics starting
  295.    in section 4.4.
  296.  
  297.    Once the tunnel exists, an unused Multiplex ID (hereafter, "MID") is
  298.    allocated, and a connect indication is sent to notify the Home
  299.    Gateway of this new dial-up session.  The Home Gateway either accepts
  300.    the connection, or rejects.  Rejection may include a reason
  301.    indication, which may be displayed to the dial-up user, after which
  302.    the call should be disconnected.
  303.  
  304.    The initial setup notification may include the authentication
  305.    information required to allow the Home Gateway to authenticate the
  306.    user and decide to accept or decline the connection.  In the case of
  307.    CHAP, the set-up packet includes the challenge, username and raw
  308.    response.  For PAP or text dialog (i.e., for SLIP users), it includes
  309.    username and clear text password.  The Home Gateway may choose to use
  310.    this information to complete its authentication, avoiding an
  311.    additional cycle of authentication.
  312.  
  313.    For PPP, the initial setup notification may also include a copy of
  314.    the the LCP CONFACKs sent in each direction which completed LCP
  315.    negotiation.  The Home Gateway may use this information to initialize
  316.    its own PPP state (thus avoiding an additional LCP negotiation), or
  317.    it may choose to initiate a new LCP CONFREQ exchange.
  318.  
  319.    If the Home Gateway accepts the connection, it creates a "virtual
  320.    interface" for SLIP or PPP in a manner analogous to what it would use
  321.    for a direct-dialed connection.  With this "virtual interface" in
  322.    place, link layer frames may now pass over this tunnel in both
  323.    directions.  Frames from the remote user are received at the POP,
  324.    stripped of any link framing or transparency bytes, encapsulated in
  325.    L2F, and forwarded over the appropriate tunnel.
  326.  
  327.    The Home Gateway accepts these frames, strips L2F, and processes them
  328.    as normal incoming frames for the appropriate interface and protocol.
  329.    The "virtual interface" behaves very much like a hardware interface,
  330.    with the exception that the hardware in this case is physically
  331.    located at the ISP POP.  The other direction behaves analogously,
  332.    with the Home Gateway encapsulating the packet in L2F, and the POP
  333.    stripping L2F before transmitting it out the physical interface to
  334.    the remote user.
  335.  
  336.  
  337.  
  338. Valencia, et. al.               Historic                        [Page 6]
  339.  
  340. RFC 2341                       Cisco L2F                        May 1998
  341.  
  342.  
  343.    At this point, the connectivity is a point-to-point PPP or SLIP
  344.    connection whose endpoints are the remote user's networking
  345.    application on one end and the termination of this connectivity into
  346.    the Home Gateway's SLIP or PPP support on the other.  Because the
  347.    remote user has become simply another dial-up client of the Home
  348.    Gateway access server, client connectivity can now be managed using
  349.    traditional mechanisms with respect to further authorization,
  350.    protocol access, and filtering.
  351.  
  352.    Accounting can be performed at both the NAS as well as the Home
  353.    Gateway.  This document illustrates some Accounting techniques which
  354.    are possible using L2F, but the policies surrounding such Accounting
  355.    are outside the scope of this specification.
  356.  
  357.    Because L2F connect notifications for PPP clients contain sufficient
  358.    information for a Home Gateway to authenticate and initialize its LCP
  359.    state machine, it is not required that the remote user be queried a
  360.    second time for CHAP authentication, nor that the client undergo
  361.    multiple rounds of LCP negotiation and convergence.  These techniques
  362.    are intended to optimize connection setup, and are not intended to
  363.    deprecate any functions required by the PPP specification.
  364.  
  365. 3.0 Service Model Issues
  366.  
  367.    There are several significant differences between the standard
  368.    Internet access service and the Virtual dial-up service with respect
  369.    to authentication, address allocation, authorization and accounting.
  370.    The details of the differences between these services and the
  371.    problems presented by these differences are described below.  The
  372.    mechanisms used for Virtual Dial-up service are intended to coexist
  373.    with more traditional mechanisms; it is intended that an ISP's POP
  374.    can simultaneously service ISP clients as well as Virtual dial-up
  375.    clients.
  376.  
  377. 3.1 Security
  378.  
  379.    For the Virtual dial-up service, the ISP pursues authentication only
  380.    to the extent required to discover the user's apparent identity (and
  381.    by implication, their desired Home Gateway).  As soon as this is
  382.    determined, a connection to the Home Gateway is initiated with the
  383.    authentication information gathered by the ISP.  The Home Gateway
  384.    completes the authentication by either accepting the connection, or
  385.    rejecting it.
  386.  
  387.    The Home Gateway must also protect against attempts by third parties
  388.    to establish tunnels to the Home Gateway.  Tunnel establishment
  389.    involves an ISP-to-Home Gateway authentication phase to protect
  390.    against such attacks.
  391.  
  392.  
  393.  
  394. Valencia, et. al.               Historic                        [Page 7]
  395.  
  396. RFC 2341                       Cisco L2F                        May 1998
  397.  
  398.  
  399. 3.2 Address Allocation
  400.  
  401.    For an Internet service, the user accepts that the IP address may be
  402.    allocated dynamically from a pool of Service provider addresses.
  403.    This model often means that the remote user has little or no access
  404.    to their home network's resources, due to firewalls and other
  405.    security policies applied by the home network to accesses from
  406.    external IP addresses.
  407.  
  408.    For the Virtual dial-up service, the Home Gateway can exist behind
  409.    the home firewall, allocating addresses which are internal (and, in
  410.    fact, can be RFC1597 addresses, or non-IP addresses).  Because L2F
  411.    tunnels exclusively at the frame layer, the actual policies of such
  412.    address management are irrelevant to correct Virtual dial-up service;
  413.    for all purposes of PPP or SLIP protocol handling, the dial-in user
  414.    appears to have connected at the Home Gateway.
  415.  
  416. 3.3 Authentication
  417.  
  418.    The authentication of the user occurs in three phases; the first at
  419.    the ISP, and the second and optional third at the Home gateway.
  420.  
  421.    The ISP uses the username to determine that a Virtual dial-up service
  422.    is required and initiate the tunnel connection to the appropriate
  423.    Home Gateway.  Once a tunnel is established, a new MID is allocated
  424.    and a session initiated by forwarding the gathered authentication
  425.    information.
  426.  
  427.    The Home Gateway undertakes the second phase by deciding whether or
  428.    not to accept the connection.  The connection indication may include
  429.    CHAP, PAP, or textual authentication information.  Based on this
  430.    information, the Home Gateway may accept the connection, or may
  431.    reject it (for instance, it was a PAP request and the
  432.    username/password are found to be incorrect).
  433.  
  434.    Once the connection is accepted, the Home Gateway is free to pursue a
  435.    third phase of authentication at the PPP or SLIP layer.  These
  436.    activities are outside the scope of this specification, but might
  437.    include an additional cycle of LCP authentication, proprietary PPP
  438.    extensions, or textual challenges carried via a TCP/IP telnet
  439.    session.
  440.  
  441. 3.4 Accounting
  442.  
  443.    It is a requirement that both the Access gateway and the Home Gateway
  444.    can provide accounting data and hence both may count packets, octets
  445.    and connection start and stop times.
  446.  
  447.  
  448.  
  449.  
  450. Valencia, et. al.               Historic                        [Page 8]
  451.  
  452. RFC 2341                       Cisco L2F                        May 1998
  453.  
  454.  
  455.    Since Virtual dial-up is an access service, accounting of connection
  456.    attempts (in particular, failed connection attempts) is of
  457.    significant interest.  The Home Gateway can reject new connections
  458.    based on the authentication information gathered by the ISP, with
  459.    corresponding logging.  For cases where the Home Gateway accepts the
  460.    connection and then continues with further authentication, the Home
  461.    Gateway might subsequently disconnect the client.  For such
  462.    scenarios, the disconnection indication back to the ISP may also
  463.    include a reason.
  464.  
  465.    Because the Home Gateway can decline a connection based on the
  466.    authentication information collected by the ISP, accounting can
  467.    easily draw a distinction between a series of failed connection
  468.    attempts and a series of brief successful connections.  Lacking this
  469.    facility, the Home Gateway must always accept connection requests,
  470.    and would need to exchange a number of PPP packets with the remote
  471.    system.
  472.  
  473. 4.0 Protocol Definition
  474.  
  475.    The protocol definition for Virtual dial-up services requires two
  476.    areas of standardization:
  477.  
  478.    +  Encapsulation of PPP packets within L2F.  The ISP NAS and the
  479.       Home gateway require a common understanding of the encapsulation
  480.       protocol so that SLIP/PPP packets can be successfully transmitted
  481.       and received across the Internet.
  482.  
  483.    +  Connection management of L2F and MIDs.  The tunnel must be
  484.       initiated and terminated, as must MIDs within the tunnel.
  485.       Termination includes diagnostic codes to assist in the diagnosis
  486.       of problems and to support accounting.
  487.  
  488.    While providing these services, the protocol must address the
  489.    following required attributes:
  490.  
  491.    +  Low overhead.  The protocol must impose a minimal additional
  492.       overhead.  This requires a compact encapsulation, and a structure
  493.       for omitting some portions of the encapsulation where their
  494.       function is not required.
  495.  
  496.    +  Efficiency.  The protocol must be efficient to encapsulate and
  497.       deencapsulate.
  498.  
  499.    +  Protocol independence.  The protocol must make very few
  500.       assumptions about the substrate over which L2F packets are
  501.       carried.
  502.  
  503.  
  504.  
  505.  
  506. Valencia, et. al.               Historic                        [Page 9]
  507.  
  508. RFC 2341                       Cisco L2F                        May 1998
  509.  
  510.  
  511.    +  Simple deployment.  The protocol must not rely on additional
  512.       telecommunication support (for instance, unique called numbers,
  513.       or caller ID) to operate.
  514.  
  515. 4.1 Encapsulation within L2F
  516.  
  517. 4.1.1 Encapsulation of PPP within L2F
  518.  
  519.    The PPP packets may be encapsulated within L2F.  The packet
  520.    encapsulated is the packet as it would be transmitted over a physical
  521.    link.  The following are NOT present in the packet:
  522.  
  523.    + Flags
  524.    + Transparency data (ACCM for async, bit stuffing for sync)
  525.    + CRC
  526.  
  527.    The following ARE still present:
  528.  
  529.    + Address and control flags (unless negotiated away by LCP)
  530.    + Protocol value
  531.  
  532. 4.1.2 Encapsulation of SLIP within L2F
  533.  
  534.    SLIP is encapsulated within L2F in much the same way as PPP.  The
  535.    transparency characters are removed before encapsulating within L2F,
  536.    as is the framing.
  537.  
  538. 4.2 L2F Packet Format
  539.  
  540. 4.2.1 Overall Packet Format
  541.  
  542.    The entire encapsulated packet has the form:
  543.  
  544.  
  545.                  ---------------------------------
  546.                  |                               |
  547.                  |         L2F Header            |
  548.                  |                               |
  549.                  ---------------------------------
  550.                  |                               |
  551.                  |  Payload packet (SLIP/PPP)    |
  552.                  |                               |
  553.                  ---------------------------------
  554.                  |                               |
  555.                  |    L2F Checksum (optional)    |
  556.                  |                               |
  557.                  ---------------------------------
  558.  
  559.  
  560.  
  561.  
  562. Valencia, et. al.               Historic                       [Page 10]
  563.  
  564. RFC 2341                       Cisco L2F                        May 1998
  565.  
  566.  
  567. 4.2.2 Packet Format
  568.  
  569.    An L2F packet has the form:
  570.  
  571.  0                   1                   2                   3
  572.  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
  573. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  574. |F|K|P|S|0|0|0|0|0|0|0|0|C| Ver |    Protocol   |Sequence (opt)|\
  575. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
  576. |          Multiplex ID         |           Client ID           | |
  577. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2F
  578. |             Length            |       Offset (opt)            | |Header
  579. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
  580. |                         Key (opt)                             | /
  581. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
  582. +                                 (payload)                     |
  583. +                             .....                             |
  584. +                             .....                             |
  585. +                             .....                             |
  586. +                                 (payload)                     |
  587. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  588. |   L2F Checksum (optional)     |
  589. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  590.  
  591. 4.2.3 Version field
  592.  
  593.    The Ver ("Version") field represents the major version of the L2F
  594.    software creating the packet.  It MUST contain the value 001.
  595.  
  596.    If Ver holds a value other than 1, or any bits are non-zero after bit
  597.    S but before bit C, this corresponds to a packet containing
  598.    extensions not understood by the receiving end.  The packet is
  599.    handled as an invalid packet as defined in 4.4.1.
  600.  
  601. 4.2.4 Protocol field
  602.  
  603.    The Protocol specifies the protocol carried within the L2F packet.
  604.    Legal values (represented here in hexadecimal) are:
  605.  
  606.       Value           Type                   Description
  607.       0x00            L2F_ILLEGAL            Illegal
  608.       0x01            L2F_PROTO              L2F management packets
  609.       0x02            L2F_PPP                PPP tunneled inside L2F
  610.       0x03            L2F_SLIP               SLIP tunneled inside L2F
  611.  
  612.    If a packet is received with a Protocol of L2F_ILLEGAL or any other
  613.    unrecognized value, it MUST be treated as an illegal packet as
  614.    defined in 4.4.1.
  615.  
  616.  
  617.  
  618. Valencia, et. al.               Historic                       [Page 11]
  619.  
  620. RFC 2341                       Cisco L2F                        May 1998
  621.  
  622.  
  623. 4.2.5 Sequence Number
  624.  
  625.    The Sequence number is present if the S bit in the L2F header is set
  626.    to 1.  This bit MUST be 1 for all L2F management packets.  It MAY be
  627.    set to 1 for non-L2F management packets.  If a non-L2F management
  628.    packet is received with the S bit set, all future L2F packets sent
  629.    for that MID MUST have the S bit set (and, by implication, be sent
  630.    using sequence numbers).  For instance, the Home Gateway might choose
  631.    to force sequenced packet delivery if it detects an NCP opening for a
  632.    protocol which can not operate with out-of-sequence packets.
  633.  
  634.    The Sequence number starts at 0 for the first sequenced L2F packet.
  635.    Each subsequent packet is sent with the next increment of the
  636.    sequence number.  The sequence number is thus a free running counter
  637.    represented modulo 256.  There is distinct Sequence number state
  638.    (i.e., counter) for each distinct MID value.
  639.  
  640.    For packets with S bit and sequence number, the sequence number is
  641.    used to protect against duplication of packets, as follows:
  642.  
  643.    The receiving side of the tunnel records the sequence number of each
  644.    valid L2F packet it receives.  If a received packet appears to have a
  645.    value less than or equal to the last received value, the packet MUST
  646.    be silently discarded.  Otherwise, the packet is accepted and the
  647.    sequence number in the packet recorded as the latest value last
  648.    received.
  649.  
  650.    For purposes of detecting duplication, a received sequence value is
  651.    considered less than or equal to the last received value if its value
  652.    lies in the range of the last value and its 127 successor values.
  653.    For example, if the last received sequence number was 15, then
  654.    packets with sequence numbers 0 through 15, as well as 144 through
  655.    255, would be considered less than or equal to, and would be silently
  656.    discarded.  Otherwise it would be accepted.
  657.  
  658. 4.2.6 Packet Multiplex ID
  659.  
  660.    The Multiplex ID ("MID") identifies a particular connection within
  661.    the tunnel.  Each new connection is assigned a MID currently unused
  662.    within the tunnel.  It is recommended that the MID cycle through the
  663.    entire 16-bit namespace, to reduce aliasing between previous and
  664.    current sessions.  A MID value which has been previously used within
  665.    a tunnel, has been closed, and will now be used again, must be
  666.    considered as an entirely new MID, and initialised as such.
  667.  
  668.    The MID with value 0 is special; it is used to communicate the state
  669.    of the tunnel itself, as distinct from any connection within the
  670.    tunnel.  Only L2F_PROTO packets may be sent using an MID of 0; if any
  671.  
  672.  
  673.  
  674. Valencia, et. al.               Historic                       [Page 12]
  675.  
  676. RFC 2341                       Cisco L2F                        May 1998
  677.  
  678.  
  679.    other type is sent on MID 0, the packet is illegal and MUST be
  680.    processed as defined in 4.4.1.
  681.  
  682. 4.2.7 Client ID
  683.  
  684.    The Client ID ("CLID") is used to assist endpoints in demultiplexing
  685.    tunnels when the underlying point-to-point substrate lacks an
  686.    efficient or dependable technique for doing so directly.  Using the
  687.    CLID, it is possible to demultiplex multiple tunnels whose packets
  688.    arrive over the point-to-point media interleaved, without requiring
  689.    media-specific semantics.
  690.  
  691.    When transmitting the L2F_CONF message (described below), the peer's
  692.    CLID must be communicated via the Assigned_CLID field.  This MUST be
  693.    a unique non-zero value on the sender's side, which is to be expected
  694.    in the Home Gateway's L2F_CONF response, as well as all future non-
  695.    L2F_CONF packets received.
  696.  
  697.    The CLID value from the last valid L2F_CONF message received MUST be
  698.    recorded and used as the CLID field value for all subsequent packets
  699.    sent to the peer.
  700.  
  701.    Packets with an unknown Client ID MUST be silently discarded.
  702.  
  703.    For the initial packet sent during tunnel establishment, where no
  704.    L2F_CONF has yet been received, the CLID field MUST be set to 0.
  705.  
  706.    Thus, during L2F_CONF each side is told its CLID value.  All later
  707.    packets sent, tagged with this CLID value, serve as a tag which
  708.    uniquely identifies this peer.
  709.  
  710. 4.2.8 Length
  711.  
  712.    Length is the size in octets of the entire packet, including header,
  713.    all fields present, and payload.  Length does not reflect the
  714.    addition of the checksum, if one is present.  The packet should be
  715.    silently discarded if the received packet is shorter than the
  716.    indicated length.  Additional bytes present in the packet beyond the
  717.    indicated length MUST be silently ignored.
  718.  
  719. 4.2.9 Packet Checksum
  720.  
  721.    The Checksum is present if the C bit is present in the header flags.
  722.    It is a 16-bit CRC as used by PPP/HDLC (specifically, FCS-16 [3]).
  723.    Is is applied over the entire packet starting with the first byte of
  724.    L2F flags, through the last byte of payload data.  The checksum is
  725.    then added as two bytes immediately following the last byte of
  726.    payload data.
  727.  
  728.  
  729.  
  730. Valencia, et. al.               Historic                       [Page 13]
  731.  
  732. RFC 2341                       Cisco L2F                        May 1998
  733.  
  734.  
  735. 4.2.10 Payload Offset
  736.  
  737.    The Offset is present if the F bit is set in the header flags.  This
  738.    field specifies the number of bytes past the L2F header at which the
  739.    payload data is expected to start.  If it is 0, or the F bit is not
  740.    set, the first byte following the last byte of L2F header is the
  741.    first byte of payload data.
  742.  
  743.    It is recommended that data skipped due to the payload offset be
  744.    initialized to 0's.
  745.  
  746.    For architectures where it is more efficient to have the payload
  747.    start at an aligned 32-bit boundary with respect to the L2F header,
  748.    it is recommended that the F bit be set, and an offset of 0 be used.
  749.  
  750. 4.2.11 Packet Key
  751.  
  752.    The Key field is present if the K bit is set in the L2F header.  The
  753.    Key is based on the authentication response last given to the peer
  754.    during tunnel creation (the details of tunnel creation are provided
  755.    in the next section).  It serves as a key during the life of a
  756.    session to resist attacks based on spoofing.  If a packet is received
  757.    in which the Key does not match the expected value, the packet MUST
  758.    be silently discarded.  Such handling takes precedence over 4.4.1.
  759.  
  760.    The Key value is generated by taking the 128-bit authentication
  761.    response from the peer, interpreting it as four adjacent 32-bit words
  762.    in network byte order, XOR'ing these words together, and using the
  763.    resulting 32-bit value as the Key.
  764.  
  765. 4.2.12 Packet priority
  766.  
  767.    If the P bit in the L2F header is set, this packet is a "priority"
  768.    packet.  When possible for an implementation, a packet received with
  769.    the P bit should be processed in preference to previously received
  770.    unprocessed packets without the P bit.
  771.  
  772.    The P bit may be set by an implementation based on criteria beyond
  773.    the scope of this specification.  However, it is recommended that PPP
  774.    keepalive traffic, if any, be sent with this bit set.
  775.  
  776. 4.3 L2F Tunnel Establishment
  777.  
  778.    When the point-to-point link is first initiated between the NAS and
  779.    the Home Gateway, the endpoints communicate on MID 0 prior to
  780.    providing general L2F services to clients.  This communication is
  781.    used to verify the presence of L2F on the remote end, and to permit
  782.    any needed authentication.
  783.  
  784.  
  785.  
  786. Valencia, et. al.               Historic                       [Page 14]
  787.  
  788. RFC 2341                       Cisco L2F                        May 1998
  789.  
  790.  
  791.    The protocol for such negotiation is always 1, indicating L2F
  792.    management.  The message itself is structured as a sequence of single
  793.    octets indicating an option, followed by zero or more further octets
  794.    formatted as needed for the option.
  795.  
  796. 4.3.1 Normal Tunnel Negotiation Sequence
  797.  
  798.    The establishment sequence is best illustrated by a "typical"
  799.    connection sequence.  Detailed description of each functions follows,
  800.    along with descriptions of the handling of exceptional conditions.
  801.  
  802.    Each packet is described as a source->destination on one line, a
  803.    description of the L2F packet field contents on the next, and the
  804.    contents of the packet's body on following lines.  The exact encoding
  805.    of octets will be described later.
  806.  
  807.    Note that this example uses the Key option, but does not use the
  808.    Offset and Checksum options.  The Length field would be present,
  809.    reflecting the actual length of the packets as encoded as an octet
  810.    stream.
  811.  
  812.       1. NAS->GW:
  813.           Proto=L2F, Seq=0, MID=0, CLID=0, Key=0
  814.           L2F_CONF
  815.               Name: NAS_name
  816.               Challenge: Rnd
  817.               Assigned_CLID: 22
  818.  
  819.    The NAS decides that a tunnel must be initiated from the NAS to the
  820.    GW.  An L2F packet is sent with the Proto field indicating an L2F
  821.    management message is contained.
  822.  
  823.    Because the tunnel is being initiated, Key is set to 0.  The sequence
  824.    number starts at 0; the MID is 0 to reflect the establishment of the
  825.    tunnel itself.  Since the NAS has not yet received an L2F_CONF, the
  826.    CLID is set to 0.
  827.  
  828.    The body of the packet specifies the claimed name of the NAS, and a
  829.    challenge random number which GW will use in authenticating itself as
  830.    a valid tunnel endpoint.  Assigned_CLID is generated to be a value
  831.    not currently assigned out to any other tunnel to any other Home
  832.    Gateway.
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Valencia, et. al.               Historic                       [Page 15]
  843.  
  844. RFC 2341                       Cisco L2F                        May 1998
  845.  
  846.  
  847.       2. GW->NAS:
  848.           Proto=L2F, Seq=0, MID=0, CLID=22, Key=0
  849.           L2F_CONF
  850.               Name: GW_name
  851.               Challenge: Rnd2
  852.               Assigned_CLID: 73
  853.  
  854.    The Home Gateway has processed the previous packet, and sends a
  855.    response.  The protocol continues to be L2F, with a sequence number 0
  856.    (each side maintains its own sequence number for transmissions).  MID
  857.    continues to be 0 to reflect tunnel establishment.  CLID reflects the
  858.    Assigned_CLID field of the L2F_CONF received.  The Key continues to
  859.    be 0 during this phase of tunnel establishment.
  860.  
  861.    The body contains the Home Gateway's name, its own random number
  862.    challenge, and its own Assigned_CLID for the NAS to place in the CLID
  863.    field of future packets.  The CLID is generated in an analogous
  864.    manner to that of the NAS.  After this, all packets received from the
  865.    NAS must be tagged with a CLID field containing 73, and all packets
  866.    sent to the NAS must be tagged with a CLID field containing 22.
  867.  
  868.       3. NAS->GW
  869.           Proto=L2F, Seq=1, MID=0, CLID=73, Key=C(Rnd2)
  870.           L2F_OPEN
  871.               Response: C(Rnd2)
  872.  
  873.    The NAS responds with its Key now set to reflect the shared secret.
  874.    The Key is a CHAP-style hash of the random number received; each
  875.    packet hereafter will reflect this calculated value, which serves as
  876.    a key for the life of the tunnel.  Both the Home Gateway and the NAS
  877.    use such Keys for the life of the tunnel.  The Key is a 32-bit
  878.    representation of the MD5 digest resulting from encrypting the shared
  879.    secret; the full MD5 digest is included in the L2F_OPEN response, in
  880.    the "response" field.
  881.  
  882.       4. GW->NAS
  883.           Proto=L2F, Seq=1, MID=0, CLID=22, Key=C(Rnd)
  884.           L2F_OPEN
  885.               Response: C(Rnd)
  886.  
  887.    The Home Gateway provides closure of the key from the NAS, reflected
  888.    in both the Key field as well as the "response" field.  The tunnel is
  889.    now available for clients to be established.
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Valencia, et. al.               Historic                       [Page 16]
  899.  
  900. RFC 2341                       Cisco L2F                        May 1998
  901.  
  902.  
  903. 4.3.2 Normal Client Negotiation Sequence
  904.  
  905.    This section describes the establishment of a Virtual dial-up client
  906.    on a NAS into a Home Gateway.  It assumes a tunnel has been created
  907.    in the way described in 4.3.1.  The client for this example is a PPP
  908.    client configured for CHAP.
  909.  
  910.    Treatment of Checksum, Length, and Offset are as in 4.3.1.
  911.  
  912.          1. NAS->GW
  913.              Proto=L2F, Seq=2, MID=1, CLID=73, Key=C(Rnd2)
  914.              L2F_OPEN
  915.                  Type: CHAP
  916.                  Name: CHAP-name
  917.                  Challenge: Rnd3
  918.                  Response: <Value received, presumably C(Rnd3)>
  919.                  ID: <ID used in challenge>
  920.  
  921.    The NAS has received a call, tried CHAP with a challenge value of
  922.    Rnd3, and found that the client responded.  The claimed name lead the
  923.    NAS to believe it was a Virtual dial-up client hosted by the Home
  924.    Gateway.  The next free MID is allocated, and the information
  925.    associated with the CHAP challenge/response is included in the
  926.    connect notification.
  927.  
  928.       2. GW->NAS
  929.           Proto=L2F, Seq=2, MID=1, CLID=22, Key=C(Rnd)
  930.           L2F_OPEN
  931.  
  932.    The Home Gateway, by sending back the L2F_OPEN, accepts the client.
  933.  
  934.       3. NAS->GW
  935.           Proto=PPP, Seq=0, MID=1, CLID=73, Key=C(Rnd2)
  936.           <Frame follows>
  937.  
  938.       4. GW->NAS
  939.           Proto=PPP, Seq=0, MID=1, CLID=22, Key=C(Rnd)
  940.           <Frame follows>
  941.  
  942.    Traffic is now free to flow in either direction as sent by the remote
  943.    client or the home site.  The contents is uninterpreted data, HDLC in
  944.    this case.  Data traffic, since it is not the L2F protocol, does not
  945.    usually use the Seq field, which is set to 0 in non-L2F messages (see
  946.    the S bit in section 4.2.5 for details on an exception to this).
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Valencia, et. al.               Historic                       [Page 17]
  955.  
  956. RFC 2341                       Cisco L2F                        May 1998
  957.  
  958.  
  959. 4.4 L2F management message types
  960.  
  961.    When an L2F packet's Proto field specifies L2F management, the body
  962.    of the packet is encoded as zero or more options.  An option is a
  963.    single octet "message type", followed by zero or more sub-options.
  964.    Each sub-option is a single byte sub-option value, and further bytes
  965.    as appropriate for the sub-option.
  966.  
  967.    Options in L2F are:
  968.  
  969.  
  970.    Hex Value       Abbreviation       Description
  971.    --------        ------------       -----------
  972.     0x00            Invalid           Invalid message
  973.     0x01            L2F_CONF          Request configuration
  974.     0x02            L2F_CONF_NAME     Name of peer sending L2F_CONF
  975.     0x03            L2F_CONF_CHAL     Random number peer challenges with
  976.     0x04            L2F_CONF_CLID     Assigned_CLID for peer to use
  977.     0x02            L2F_OPEN          Accept configuration
  978.     0x01            L2F_OPEN_NAME     Name received from client
  979.     0x02            L2F_OPEN_CHAL     Challenge client received
  980.     0x03            L2F_OPEN_RESP     Challenge response from client
  981.     0x04            L2F_ACK_LCP1      LCP CONFACK accepted from client
  982.     0x05            L2F_ACK_LCP2      LCP CONFACK sent to client
  983.     0x06            L2F_OPEN_TYPE     Type of authentication used
  984.     0x07            L2F_OPEN_ID       ID associated with authentication
  985.     0x08            L2F_REQ_LCP0      First LCP CONFREQ from client
  986.     0x03            L2F_CLOSE         Request disconnect
  987.     0x01            L2F_CLOSE_WHY     Reason code for close
  988.     0x02            L2F_CLOSE_STR     ASCII string description
  989.     0x04            L2F_ECHO          Verify presence of peer
  990.     0x05            L2F_ECHO_RESP     Respond to L2F_ECHO
  991.  
  992. 4.4.1 L2F message type: Invalid
  993.  
  994.    If a message is received with this value, or any value higher than
  995.    the last recognized option value, or if an illegal packet as defined
  996.    by other parts of this specification is received, the packet is
  997.    considered invalid.  The packet MUST be discarded, and an L2F_CLOSE
  998.    of the entire tunnel MUST be requested.  Upon receipt of an
  999.    L2F_CLOSE, the tunnel itself may be closed.  All other received
  1000.    message MUST be discarded.  An implementation MAY close the tunnel
  1001.    after an interval of time appropriate to the characteristics of the
  1002.    tunnel.
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Valencia, et. al.               Historic                       [Page 18]
  1011.  
  1012. RFC 2341                       Cisco L2F                        May 1998
  1013.  
  1014.  
  1015.    Note that packets with an invalid Key are discarded, but disconnect
  1016.    is not initiated.  This prevents denial-of-service attacks.  Invalid
  1017.    option types within a message MUST be treated as if the entire
  1018.    message type was invalid.
  1019.  
  1020. 4.4.2 L2F_CONF
  1021.  
  1022.    The L2F message type is used to establish the tunnel between the NAS
  1023.    and the Home Gateway.  MID is always set to 0.  The body of such a
  1024.    message starts with the octet 0x01 (L2F_CONF), followed by all three
  1025.    of the sub-options below.
  1026.  
  1027.    The L2F_CONF_NAME sub-option MUST be present.  It is encoded as the
  1028.    octet value 0x02, followed by an octet specifying a non-zero length,
  1029.    followed by the indicated number of bytes, which are interpreted as
  1030.    the sender's ASCII name.
  1031.  
  1032.    The L2F_CONF_CHAL sub-option MUST be present.  It is encoded as the
  1033.    octet value 0x03, followed by a non-zero octet, followed by a number
  1034.    of bytes specified by this non-zero octet.
  1035.  
  1036.    The challenge value should be generated using whatever techniques
  1037.    provide the highest quality of random numbers available to a given
  1038.    implementation.
  1039.  
  1040.    The L2F_CONF_CLID sub-option MUST be present.  It is encoded as the
  1041.    octet 0x04, followed by four bytes of Assigned_CLID value.  The
  1042.    Assigned_CLID value is generated as a non-zero 16-bit integer value
  1043.    unique across all tunnels which exist on the sending system.  The
  1044.    least significant two octets of Assigned_CLID are set to this value,
  1045.    and the most significant two octets MUST be set to 0.
  1046.  
  1047.    The CLID field is sent as 0 in the initial L2F_CONF packet from NAS
  1048.    to Home Gateway, and otherwise MUST be sent containing the value
  1049.    specified in the Assigned_CLID field of the last L2F_CONF message
  1050.    received.
  1051.  
  1052.    Key MUST be set to 0 in all L2F_CONF packets, and no key field is
  1053.    included in the packet.
  1054.  
  1055.    When sent from a NAS to a Home Gateway, the L2F_CONF is the initial
  1056.    packet in the conversation.
  1057.  
  1058.    When sent from the Home Gateway to the NAS, an L2F_CONF indicates the
  1059.    Home Gateway's recognition of the tunnel creation request.  The Home
  1060.    Gateway MUST provide its name and its own challenge in the message
  1061.    body.
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Valencia, et. al.               Historic                       [Page 19]
  1067.  
  1068. RFC 2341                       Cisco L2F                        May 1998
  1069.  
  1070.  
  1071.    In all packets following the L2F_CONF, the Key MUST be set to the
  1072.    CHAP-style hash of the received challenge bytes.  The CHAP-style hash
  1073.    is done over the concatenation of the low 8 bits of the assigned
  1074.    CLID, the secret, and the challenge value.  Generation of the 32-bit
  1075.    key value is discussed in section 4.2.11.
  1076.  
  1077. 4.4.3 L2F_OPEN, tunnel establishment
  1078.  
  1079.    The L2F_OPEN message is used to provide tunnel setup closure (for a
  1080.    MID of 0) or to establish a client connection within a tunnel
  1081.    previously established by L2F_CONF and L2F_OPEN messages (MID not
  1082.    equal to 0).  This section describes tunnel establishment; section
  1083.    4.4.4 following describes clients established within the tunnel.
  1084.  
  1085.    An L2F_OPEN for tunnel establishment MUST contain only the sub-option
  1086.    0x03, L2F_OPEN_RESP.  This option MUST be followed by the octet 0x10,
  1087.    specifying the size of the 128-bit MD5 digest resulting from
  1088.    encrypting the challenge value in the L2F_CONF, along with the low
  1089.    byte of the Assigned_CLID.  After this byte MUST be the sixteen bytes
  1090.    of the generated MD5 digest.
  1091.  
  1092.    If during tunnel establishment an L2F_OPEN is received with an
  1093.    incorrect L2F_OPEN_RESP, the packet MUST be silently discarded.  It
  1094.    is recommended that such an event generate a log event as well.
  1095.  
  1096. 4.4.4 L2F_OPEN, client establishment
  1097.  
  1098.    An L2F_OPEN (with non-zero MID) sent from the NAS to the Home Gateway
  1099.    indicates the presence of a new dial-in client.  When sent back from
  1100.    the Home Gateway to the NAS, it indicates acceptance of the client.
  1101.    This message starts with the octet 0x02.  When sent from the NAS, it
  1102.    may contain further sub-options.  When sent from the Home Gateway, it
  1103.    may not contain any sub-options.  All further discussion of sub-
  1104.    options in this section apply only to the NAS to Home Gateway
  1105.    direction.
  1106.  
  1107.    The L2F_OPEN_TYPE sub-option MUST be present.  It is encoded as the
  1108.    octet 0x06, followed by a single byte describing the type of
  1109.    authentication the NAS exchanged with the client in detecting the
  1110.    client's claimed identification.  Implicit in the authentication type
  1111.    is the encapsulation to be carried over the life of the session.  The
  1112.    authentication types are:
  1113.  
  1114.       0x01 Textual username/password exchange for SLIP
  1115.       0x02 PPP CHAP
  1116.       0x03 PPP PAP
  1117.       0x04 PPP no authentication
  1118.       0x05 SLIP no authentication
  1119.  
  1120.  
  1121.  
  1122. Valencia, et. al.               Historic                       [Page 20]
  1123.  
  1124. RFC 2341                       Cisco L2F                        May 1998
  1125.  
  1126.  
  1127.    The L2F_OPEN_NAME sub-option is encoded as the octet 0x01, followed
  1128.    by an octet specifying the length of the name, followed by the
  1129.    indicated number of bytes of the name.  This field MUST be present
  1130.    for any authentication type except 0x04 (None).  It MUST contain the
  1131.    name specified in the client's authentication response.
  1132.  
  1133.    The L2F_OPEN_CHAL sub-option is encoded as the octet 0x02, followed
  1134.    by an octet specifying the length of the challenge sent, followed by
  1135.    the challenge itself.  This field is only present for CHAP, and MUST
  1136.    contain the challenge value sent to the client by the NAS.
  1137.  
  1138.    The L2F_OPEN_RESP sub-option is encoded as the octet 0x03, followed
  1139.    by an octet specifying the length of the response received, followed
  1140.    by the client's response to the challenge.  For CHAP, this field
  1141.    contains the response value received by the NAS.  For PAP or textual
  1142.    authentication, it contains the clear text password received from the
  1143.    client by the NAS.  This field is absent for authentication 0x04
  1144.    "None".
  1145.  
  1146.    The L2F_ACK_LCP1 and L2F_ACK_LCP2 sub-options are encoded as the
  1147.    octets 0x04 and 0x05 respectively, followed in either case by two
  1148.    octets in network byte order specifying the length of the LCP CONFACK
  1149.    last received from or sent to the client.  Following these octets is
  1150.    an exact copy of the CONFACK packet.  L2F_ACK_LCP1 specifies a copy
  1151.    of the closing CONFACK received from the client, and L2F_ACK_LCP2
  1152.    specifies a copy of the closing CONFACK sent to the client by the
  1153.    NAS.
  1154.  
  1155.    The L2F_REQ_LCP0 sub-option is encoded as the octet 0x08, followed by
  1156.    two octets in network byte order specifying the length of the LCP
  1157.    CONFREQ initially received from the client.  This may be used by the
  1158.    Home Gateway to detect capabilities of the client which were
  1159.    negotiated away while starting LCP with the NAS.  Detection of such
  1160.    options may be used by the Home Gateway to decide to renegotiate LCP.
  1161.  
  1162.    The L2F_OPEN_ID sub-option is encoded as the octet 0x06, followed by
  1163.    a single octet.  This sub-option is only present for CHAP; the single
  1164.    octet contains the CHAP Identifier value sent to the client during
  1165.    the CHAP challenge.
  1166.  
  1167.    The Home Gateway may choose to ignore any sub-option of the L2F_OPEN,
  1168.    and accept the connection anyway.  The Home Gateway would then have
  1169.    to undertake its own LCP negotiations and authentication.  To
  1170.    maximize the transparency of the L2F tunnel, it is recommended that
  1171.    extra negotiations and authentication be avoided if possible.
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Valencia, et. al.               Historic                       [Page 21]
  1179.  
  1180. RFC 2341                       Cisco L2F                        May 1998
  1181.  
  1182.  
  1183. 4.4.5 L2F_CLOSE
  1184.  
  1185.    This message is encoded as the byte 0x03.  An L2F_CLOSE may be sent
  1186.    by either side of the tunnel at any time.  When sent with MID of 0,
  1187.    it indicates the desire to terminate the entire tunnel and all
  1188.    clients within the tunnel.  When sent from the Home Gateway in
  1189.    response to an L2F_OPEN, it indicates that the Home Gateway has
  1190.    declined the connection.  When sent with a non-zero MID, it indicates
  1191.    the termination of that client within the tunnel.
  1192.  
  1193.    The L2F_CLOSE_WHY sub-option is encoded as the byte 0x01 followed
  1194.    four bytes in network byte order specifying a bit mask of reasons for
  1195.    the disconnection.  The bits are encoded as:
  1196.  
  1197.       0x00000001 Authentication failed
  1198.       0x00000002 Out of resources
  1199.       0x00000004 Administrative intervention
  1200.       0x00000008 User quota exceeded
  1201.       0x00000010 Protocol error
  1202.       0x00000020 Unknown user
  1203.       0x00000040 Incorrect password
  1204.       0x00000080 PPP configuration incompatible
  1205.       0x00000100 Wrong multilink PPP destination
  1206.  
  1207.    Bits in the mask 0xFF000000 are reserved for per-vendor
  1208.    interpretation.
  1209.  
  1210.    An implementation can choose to not provide status bits even if it
  1211.    detects a condition described by one of these bits.  For instance, an
  1212.    implementation may choose to not use 0x00000020 due to security
  1213.    considerations, as it can be used to probe user name space.
  1214.  
  1215.    The L2F_CLOSE_STR sub-option is encoded as the byte 0x02, followed by
  1216.    a two-byte length in network byte order, followed by the indicated
  1217.    number of bytes, which are interpreted as descriptive ASCII text
  1218.    associated with the disconnection.  This string may be ignored, but
  1219.    could be recorded in a log to provide detailed or auxiliary
  1220.    information associated with the L2F_CLOSE.
  1221.  
  1222. 4.4.6 L2F_ECHO
  1223.  
  1224.    Transmission of L2F_ECHO messages is optional.  If an implementation
  1225.    transmits L2F_ECHO messages, it MUST not transmit more than one such
  1226.    request each second.  The payload size MUST be 64 bytes or less in
  1227.    length.  It is recommended that at least 5 L2F_ECHO messages be sent
  1228.    without response before an implementation assumes that its peer has
  1229.    terminated.
  1230.  
  1231.  
  1232.  
  1233.  
  1234. Valencia, et. al.               Historic                       [Page 22]
  1235.  
  1236. RFC 2341                       Cisco L2F                        May 1998
  1237.  
  1238.  
  1239.    The L2F_ECHO message is encoded as the single byte 0x04.  It may be
  1240.    sent by either side once the tunnel is established.  MID MUST be 0.
  1241.    An L2F_ECHO_RESP (documented below) MUST be sent back in response.
  1242.  
  1243. 4.4.7 L2F_ECHO_RESP
  1244.  
  1245.    All implementations MUST respond to L2F_ECHO, using L2F_ECHO_RESP.
  1246.    The received packet MUST be sent back verbatim, except that the CLID,
  1247.    sequence number, and checksum (if any) MUST be updated, and the
  1248.    L2F_ECHO message type changed to an L2F_ECHO_RESP.  Payload data
  1249.    following the 0x04 octet, if any, MUST be preserved in the response.
  1250.  
  1251.    When an L2F_ECHO_RESP is received, the payload data may be used to
  1252.    associate this response with a previously sent L2F_ECHO, or the
  1253.    packet may be silently discarded.
  1254.  
  1255. 4.5 L2F Message Delivery
  1256.  
  1257.    L2F is designed to operate over point-to-point unreliable links.  It
  1258.    is not designed to provide flow control of the data traffic, nor does
  1259.    it provide reliable delivery of this traffic; each protocol tunnel
  1260.    carried via L2F is expected to manage flow control and retry itself.
  1261.    Thus, it is only L2F control messages which must be retransmitted;
  1262.    this process is described in this section.
  1263.  
  1264. 4.5.1 Sequenced delivery
  1265.  
  1266.    All L2F control messages (i.e., those L2F packets with a protocol
  1267.    type of 0x01) are transmitted with a sequence number.  The sequence
  1268.    number is a per-L2F tunnel free running counter which is incremented
  1269.    (modulo 256) after each packet is transmitted.  It is used to permit
  1270.    the receiving end to detect duplicated or out-of-order packets, and
  1271.    to discard such packets.  Section 4.2.5 describes the process in
  1272.    detail.
  1273.  
  1274. 4.5.2 Flow control
  1275.  
  1276.    L2F control messages are expected to be exchanged lock-step.  Thus,
  1277.    per-client activities can not occur until tunnel setup is complete.
  1278.    Neither can one client be serviced until the L2F message exchange is
  1279.    complete for a previous client.  Thus, it is expected that rarely--if
  1280.    ever--should a flow control action be required.  If the input queue
  1281.    of L2F control messages reaches an objectionable level for an
  1282.    implementation, the implementation may silently discard all messages
  1283.    in the queue to stabilize the situation.
  1284.  
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290. Valencia, et. al.               Historic                       [Page 23]
  1291.  
  1292. RFC 2341                       Cisco L2F                        May 1998
  1293.  
  1294.  
  1295. 4.5.3 Tunnel State table
  1296.  
  1297.    The following enumerates the handling of L2F messages for tunnel
  1298.    creation in state table format.  Events name an L2F_ message type
  1299.    (the L2F_ portion of the named message is omitted to permit a more
  1300.    compact table).  A start ("*") matches any event not otherwise
  1301.    matched for the named state.
  1302.  
  1303.    A NAS starts at initial state Start0, sending a packet before waiting
  1304.    for its first event.  A Home Gateway starts at Start1, waiting for an
  1305.    initial packet to start service.
  1306.  
  1307.    If an event is not matched for a given state, the packet associated
  1308.    with that event is silently discarded.
  1309.  
  1310.    Tunnel establishment (MID == 0), NAS side.
  1311.  
  1312.  
  1313.       State   Event           Action                  New State
  1314.       -----   -----           ------                  ---------
  1315.       Start0                  Send CONF               Start1
  1316.       Start1  CONF            Send OPEN               Start2
  1317.       Start1  timeout 1-3     Send CONF               Start1
  1318.       Start1  timeout 4       Clean up tunnel         (done)
  1319.       Start2  OPEN            (initiate 1st client)   Open1
  1320.       Start2  timeout 1-3     Send OPEN               Start2
  1321.       Start2  timeout 4       Clean up tunnel         (done)
  1322.       Open1   OPEN            Send OPEN               Open1
  1323.       Open1   CLOSE           Send CLOSE              Close1
  1324.       Open1   no MIDs open    Send CLOSE              Close2
  1325.       Close1  CLOSE           Send CLOSE              Close1
  1326.       Close1  timeout 4       Clean up tunnel         (done)
  1327.       Close2  CLOSE           Clean up tunnel         (done)
  1328.       Close2  timeout 1-3     Send CLOSE              Close2
  1329.       Close2  timeout 4       Clean up tunnel         (done)
  1330.  
  1331.    Tunnel establishment (MID == 0), Home Gateway side.
  1332.  
  1333.       State   Event           Action                  New State
  1334.       -----   -----           ------                  ---------
  1335.       Start0  CONF            Send CONF               Start1
  1336.       Start1  CONF            Send CONF               Start1
  1337.       Start1  OPEN            Send OPEN               Open1
  1338.       Start1  timeout 4       Clean up tunnel         (done)
  1339.       Open1   OPEN            Send OPEN               Open1
  1340.       Open1   OPEN (MID > 0)  (1st client, below)     Open2
  1341.       Open1   CLOSE           Send CLOSE              Close1
  1342.       Open1   timeout 4       Clean up tunnel         (done)
  1343.  
  1344.  
  1345.  
  1346. Valencia, et. al.               Historic                       [Page 24]
  1347.  
  1348. RFC 2341                       Cisco L2F                        May 1998
  1349.  
  1350.  
  1351.       Open2   OPEN (MID > 0)  (below)                 Open2
  1352.       Open2   CLOSE           Send CLOSE              Close1
  1353.       Close1  CLOSE           Send CLOSE              Close1
  1354.       Close1  timeout 4       Clean up tunnel         (done)
  1355.  
  1356. 4.5.4 Client State table
  1357.  
  1358.    This table is similar to the previous one, but enumerates the states
  1359.    for a client connection within a tunnel in the opened state from
  1360.    4.5.3.  As this sequence addresses clients, MID will be non-zero.
  1361.  
  1362.    Client establishment (MID != 0), NAS side.
  1363.  
  1364.       State   Event           Action                  New State
  1365.       -----   -----           ------                  ---------
  1366.       Start0                  Send OPEN               Start1
  1367.       Start1  OPEN            (enable forwarding)     Open1
  1368.       Start1  CLOSE           Clean up MID            (MID done)
  1369.       Start1  timeout 1-3     Send OPEN               Start1
  1370.       Start1  timeout 4       Clean up MID            (MID done)
  1371.       Start1  client done     Send CLOSE              Close2
  1372.       Open1   OPEN            (no change)             Open1
  1373.       Open1   CLOSE           Send CLOSE              Close1
  1374.       Open1   client done     Send CLOSE              Close2
  1375.       Close1  CLOSE           Send CLOSE              Close1
  1376.       Close1  timeout 4       Clean up MID            (MID done)
  1377.       Close2  CLOSE           Clean up MID            (MID done)
  1378.       Close2  timeout 1-3     Send CLOSE              Close2
  1379.       Close2  timeout 4       Clean up MID            (MID done)
  1380.  
  1381.    Client establishment (MID != 0), Home Gateway side.
  1382.  
  1383.       State   Event           Action                  New State
  1384.       -----   -----           ------                  ---------
  1385.       Start0  OPEN            Send OPEN               Open1
  1386.       Start0  OPEN (fail)     Send CLOSE              Close3
  1387.       Open1   OPEN            Send OPEN               Open1
  1388.       Open1   CLOSE           Send CLOSE              Close1
  1389.       Open1   client done     Send CLOSE              Close2
  1390.       Close1  CLOSE           Send CLOSE              Close1
  1391.       Close1  timeout 4       Clean up MID            (MID done)
  1392.       Close2  CLOSE           Clean up MID            (MID done)
  1393.       Close2  timeout 1-3     Send CLOSE              Close2
  1394.       Close2  timeout 4       Clean up MID            (MID done)
  1395.       Close3  OPEN            Send CLOSE              Close3
  1396.       Close3  timeout 4       Clean up MID            (MID done)
  1397.  
  1398.  
  1399.  
  1400.  
  1401.  
  1402. Valencia, et. al.               Historic                       [Page 25]
  1403.  
  1404. RFC 2341                       Cisco L2F                        May 1998
  1405.  
  1406.  
  1407. 5. Protocol Considerations
  1408.  
  1409.    Several aspects of operation over L2F, while outside the realm of the
  1410.    protocol description itself, serve to clarify the operation of L2F.
  1411.  
  1412. 5.1 PPP Features
  1413.  
  1414.    Because L2F in operation carries uninterpreted frames, it permits
  1415.    operation of features without explicit knowledge of these features.
  1416.    For instance, if a PPP session is carried, L2F is simply transporting
  1417.    HDLC frames.  The two PPP endpoints can negotiate higher-level
  1418.    features, such as reliable link, compression, multi-link, or
  1419.    encryption.  These features then operate between the two PPP
  1420.    endpoints (the dial-in client on one end, and the Home Gateway on the
  1421.    other), with L2F continuing to simply ship HDLC frames back and
  1422.    forth.
  1423.  
  1424.    For similar reasons, PPP echo requests, NCP configuration
  1425.    negotiation, and even termination requests, are all simply tunneled
  1426.    HDLC frames.
  1427.  
  1428. 5.2 Termination
  1429.  
  1430.    As L2F simply tunnels link-layer frames, it does not detect frames
  1431.    like PPP TERMREQ.  L2F termination in these scenarios is driven from
  1432.    a protocol endpoint; for instance, if a Home Gateway receives a
  1433.    TERMREQ, its action will be to "hang up" the PPP session.  It is the
  1434.    responsibility of the L2F implementation at the Home Gateway to
  1435.    convert a "hang up" into an L2F_CLOSE action, which will shut down
  1436.    client's session in the tunnel cleanly.  L2F_CLOSE_WHY and
  1437.    L2F_CLOSE_STR may be included to describe the reason for the
  1438.    shutdown.
  1439.  
  1440. 5.3 Extended Authentication
  1441.  
  1442.    L2F is compatible with both PAP and CHAP protocols.  SLIP does not
  1443.    provide authentication within the protocol itself, and thus requires
  1444.    an ASCII exchange of username and password before SLIP is started.
  1445.    L2F is compatible with this mode of operation as well.
  1446.  
  1447.    One-time password cards have become very common.  To the extent the
  1448.    NAS can capture and forward the one-time password, L2F operation is
  1449.    compatible with password cards.  For the most general solution, an
  1450.    arbitrary request/response exchange must be supported.  In an L2F
  1451.    environment, the protocol must be structured so that the NAS can
  1452.    detect the apparent identity of the user and establish a tunnel
  1453.    connection to the Home Gateway, where the arbitrary exchange can
  1454.    occur.
  1455.  
  1456.  
  1457.  
  1458. Valencia, et. al.               Historic                       [Page 26]
  1459.  
  1460. RFC 2341                       Cisco L2F                        May 1998
  1461.  
  1462.  
  1463. 5.4 MNP4 and Apple Remote Access Protocol
  1464.  
  1465.    L2F appears compatible with Apple's ARAP protocol.  Its operation
  1466.    under L2F has not been described simply because this experimental RFC
  1467.    does not have a corresponding implementation of such operation.
  1468.  
  1469. 5.5 Operation of IP and UDP
  1470.  
  1471.    L2F tries to be self-describing, operating at a level above the
  1472.    particular media over which it is carried.  However, some details of
  1473.    its connection to media are required to permit interoperable
  1474.    implementations.  This section describes the issues which have been
  1475.    found when operating L2F over IP and UDP.
  1476.  
  1477.    L2F uses the well-known UDP port 1701 [4].  The entire L2F packet,
  1478.    including payload and L2F header, is sent within a UDP datagram.  The
  1479.    source and destination ports are the same (1701), with demultiplexing
  1480.    being achieved using CLID values.  It is legal for the source IP
  1481.    address of a given CLID to change over the life of a connection, as
  1482.    this may correspond to a peer with multiple IP interfaces responding
  1483.    to a network topology change.  Responses should reflect the last
  1484.    source IP address for that CLID.
  1485.  
  1486.    IP fragmentation may occur as the L2F packet travels over the IP
  1487.    substrate.  L2F makes no special efforts to optimize this.  A NAS
  1488.    implementation MAY cause its LCP to negotiate for a specific MRU,
  1489.    which could optimize for NAS environments in which the MTUs of the
  1490.    path over which the L2F packets are likely to travel have a
  1491.    consistent value.
  1492.  
  1493. 6.0 Acknowledgments
  1494.  
  1495.    L2F uses a packet format inspired by GRE [5].  Thanks to Fred Baker
  1496.    for consultation, Dave Carrel for consulting on security aspects, and
  1497.    to Paul Traina for philosophical guidance.
  1498.  
  1499. 7.0 References
  1500.  
  1501.    [1] Romkey, J., "A Nonstandard for Transmission of IP Datagrams over
  1502.        Serial Lines: SLIP", RFC 1055, June 1988.
  1503.  
  1504.    [2] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
  1505.        RFC 1661, July 1994.
  1506.  
  1507.    [3] Simpson, W., "PPP in HDLC-like Framing", STD 51,, RFC 1662,
  1508.        July 1994.
  1509.  
  1510.  
  1511.  
  1512.  
  1513.  
  1514. Valencia, et. al.               Historic                       [Page 27]
  1515.  
  1516. RFC 2341                       Cisco L2F                        May 1998
  1517.  
  1518.  
  1519.    [4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
  1520.        October 1994.
  1521.  
  1522.    [5] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing
  1523.        Encapsulation (GRE)", RFC 1701, October 1994.
  1524.  
  1525. 8.0 Security Considerations
  1526.  
  1527.    Security issues are discussed in Section 3.1.
  1528.  
  1529. 9.0 Authors' Addresses
  1530.  
  1531.    Tim Kolar
  1532.    Cisco Systems
  1533.    170 West Tasman Drive
  1534.    San Jose CA 95134-1706
  1535.  
  1536.    EMail: tkolar@cisco.com
  1537.  
  1538.  
  1539.    Morgan Littlewood
  1540.    Cisco Systems
  1541.    170 West Tasman Drive
  1542.    San Jose CA 95134-1706
  1543.  
  1544.    EMail: littlewo@cisco.com
  1545.  
  1546.  
  1547.    Andy Valencia
  1548.    Cisco Systems
  1549.    170 West Tasman Drive
  1550.    San Jose CA 95134-1706
  1551.  
  1552.    EMail: valencia@cisco.com
  1553.  
  1554.  
  1555.  
  1556.  
  1557.  
  1558.  
  1559.  
  1560.  
  1561.  
  1562.  
  1563.  
  1564.  
  1565.  
  1566.  
  1567.  
  1568.  
  1569.  
  1570. Valencia, et. al.               Historic                       [Page 28]
  1571.  
  1572. RFC 2341                       Cisco L2F                        May 1998
  1573.  
  1574.  
  1575. 9.0  Full Copyright Statement
  1576.  
  1577.    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  1578.  
  1579.    This document and translations of it may be copied and furnished to
  1580.    others, and derivative works that comment on or otherwise explain it
  1581.    or assist in its implementation may be prepared, copied, published
  1582.    and distributed, in whole or in part, without restriction of any
  1583.    kind, provided that the above copyright notice and this paragraph are
  1584.    included on all such copies and derivative works.  However, this
  1585.    document itself may not be modified in any way, such as by removing
  1586.    the copyright notice or references to the Internet Society or other
  1587.    Internet organizations, except as needed for the purpose of
  1588.    developing Internet standards in which case the procedures for
  1589.    copyrights defined in the Internet Standards process must be
  1590.    followed, or as required to translate it into languages other than
  1591.    English.
  1592.  
  1593.    The limited permissions granted above are perpetual and will not be
  1594.    revoked by the Internet Society or its successors or assigns.
  1595.  
  1596.    This document and the information contained herein is provided on an
  1597.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  1598.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  1599.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  1600.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  1601.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  1602.  
  1603.  
  1604.  
  1605.  
  1606.  
  1607.  
  1608.  
  1609.  
  1610.  
  1611.  
  1612.  
  1613.  
  1614.  
  1615.  
  1616.  
  1617.  
  1618.  
  1619.  
  1620.  
  1621.  
  1622.  
  1623.  
  1624.  
  1625.  
  1626. Valencia, et. al.               Historic                       [Page 29]
  1627.  
  1628.