rfc2341.txt

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

   considerations, as it can be used to probe user name space.

   The L2F_CLOSE_STR sub-option is encoded as the byte 0x02, followed by
   a two-byte length in network byte order, followed by the indicated
   number of bytes, which are interpreted as descriptive ASCII text
   associated with the disconnection.  This string may be ignored, but
   could be recorded in a log to provide detailed or auxiliary
   information associated with the L2F_CLOSE.

4.4.6 L2F_ECHO

   Transmission of L2F_ECHO messages is optional.  If an implementation
   transmits L2F_ECHO messages, it MUST not transmit more than one such
   request each second.  The payload size MUST be 64 bytes or less in
   length.  It is recommended that at least 5 L2F_ECHO messages be sent
   without response before an implementation assumes that its peer has
   terminated.




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


   The L2F_ECHO message is encoded as the single byte 0x04.  It may be
   sent by either side once the tunnel is established.  MID MUST be 0.
   An L2F_ECHO_RESP (documented below) MUST be sent back in response.

4.4.7 L2F_ECHO_RESP

   All implementations MUST respond to L2F_ECHO, using L2F_ECHO_RESP.
   The received packet MUST be sent back verbatim, except that the CLID,
   sequence number, and checksum (if any) MUST be updated, and the
   L2F_ECHO message type changed to an L2F_ECHO_RESP.  Payload data
   following the 0x04 octet, if any, MUST be preserved in the response.

   When an L2F_ECHO_RESP is received, the payload data may be used to
   associate this response with a previously sent L2F_ECHO, or the
   packet may be silently discarded.

4.5 L2F Message Delivery

   L2F is designed to operate over point-to-point unreliable links.  It
   is not designed to provide flow control of the data traffic, nor does
   it provide reliable delivery of this traffic; each protocol tunnel
   carried via L2F is expected to manage flow control and retry itself.
   Thus, it is only L2F control messages which must be retransmitted;
   this process is described in this section.

4.5.1 Sequenced delivery

   All L2F control messages (i.e., those L2F packets with a protocol
   type of 0x01) are transmitted with a sequence number.  The sequence
   number is a per-L2F tunnel free running counter which is incremented
   (modulo 256) after each packet is transmitted.  It is used to permit
   the receiving end to detect duplicated or out-of-order packets, and
   to discard such packets.  Section 4.2.5 describes the process in
   detail.

4.5.2 Flow control

   L2F control messages are expected to be exchanged lock-step.  Thus,
   per-client activities can not occur until tunnel setup is complete.
   Neither can one client be serviced until the L2F message exchange is
   complete for a previous client.  Thus, it is expected that rarely--if
   ever--should a flow control action be required.  If the input queue
   of L2F control messages reaches an objectionable level for an
   implementation, the implementation may silently discard all messages
   in the queue to stabilize the situation.






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


4.5.3 Tunnel State table

   The following enumerates the handling of L2F messages for tunnel
   creation in state table format.  Events name an L2F_ message type
   (the L2F_ portion of the named message is omitted to permit a more
   compact table).  A start ("*") matches any event not otherwise
   matched for the named state.

   A NAS starts at initial state Start0, sending a packet before waiting
   for its first event.  A Home Gateway starts at Start1, waiting for an
   initial packet to start service.

   If an event is not matched for a given state, the packet associated
   with that event is silently discarded.

   Tunnel establishment (MID == 0), NAS side.


      State   Event           Action                  New State
      -----   -----           ------                  ---------
      Start0                  Send CONF               Start1
      Start1  CONF            Send OPEN               Start2
      Start1  timeout 1-3     Send CONF               Start1
      Start1  timeout 4       Clean up tunnel         (done)
      Start2  OPEN            (initiate 1st client)   Open1
      Start2  timeout 1-3     Send OPEN               Start2
      Start2  timeout 4       Clean up tunnel         (done)
      Open1   OPEN            Send OPEN               Open1
      Open1   CLOSE           Send CLOSE              Close1
      Open1   no MIDs open    Send CLOSE              Close2
      Close1  CLOSE           Send CLOSE              Close1
      Close1  timeout 4       Clean up tunnel         (done)
      Close2  CLOSE           Clean up tunnel         (done)
      Close2  timeout 1-3     Send CLOSE              Close2
      Close2  timeout 4       Clean up tunnel         (done)

   Tunnel establishment (MID == 0), Home Gateway side.

      State   Event           Action                  New State
      -----   -----           ------                  ---------
      Start0  CONF            Send CONF               Start1
      Start1  CONF            Send CONF               Start1
      Start1  OPEN            Send OPEN               Open1
      Start1  timeout 4       Clean up tunnel         (done)
      Open1   OPEN            Send OPEN               Open1
      Open1   OPEN (MID > 0)  (1st client, below)     Open2
      Open1   CLOSE           Send CLOSE              Close1
      Open1   timeout 4       Clean up tunnel         (done)



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


      Open2   OPEN (MID > 0)  (below)                 Open2
      Open2   CLOSE           Send CLOSE              Close1
      Close1  CLOSE           Send CLOSE              Close1
      Close1  timeout 4       Clean up tunnel         (done)

4.5.4 Client State table

   This table is similar to the previous one, but enumerates the states
   for a client connection within a tunnel in the opened state from
   4.5.3.  As this sequence addresses clients, MID will be non-zero.

   Client establishment (MID != 0), NAS side.

      State   Event           Action                  New State
      -----   -----           ------                  ---------
      Start0                  Send OPEN               Start1
      Start1  OPEN            (enable forwarding)     Open1
      Start1  CLOSE           Clean up MID            (MID done)
      Start1  timeout 1-3     Send OPEN               Start1
      Start1  timeout 4       Clean up MID            (MID done)
      Start1  client done     Send CLOSE              Close2
      Open1   OPEN            (no change)             Open1
      Open1   CLOSE           Send CLOSE              Close1
      Open1   client done     Send CLOSE              Close2
      Close1  CLOSE           Send CLOSE              Close1
      Close1  timeout 4       Clean up MID            (MID done)
      Close2  CLOSE           Clean up MID            (MID done)
      Close2  timeout 1-3     Send CLOSE              Close2
      Close2  timeout 4       Clean up MID            (MID done)

   Client establishment (MID != 0), Home Gateway side.

      State   Event           Action                  New State
      -----   -----           ------                  ---------
      Start0  OPEN            Send OPEN               Open1
      Start0  OPEN (fail)     Send CLOSE              Close3
      Open1   OPEN            Send OPEN               Open1
      Open1   CLOSE           Send CLOSE              Close1
      Open1   client done     Send CLOSE              Close2
      Close1  CLOSE           Send CLOSE              Close1
      Close1  timeout 4       Clean up MID            (MID done)
      Close2  CLOSE           Clean up MID            (MID done)
      Close2  timeout 1-3     Send CLOSE              Close2
      Close2  timeout 4       Clean up MID            (MID done)
      Close3  OPEN            Send CLOSE              Close3
      Close3  timeout 4       Clean up MID            (MID done)





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


5. Protocol Considerations

   Several aspects of operation over L2F, while outside the realm of the
   protocol description itself, serve to clarify the operation of L2F.

5.1 PPP Features

   Because L2F in operation carries uninterpreted frames, it permits
   operation of features without explicit knowledge of these features.
   For instance, if a PPP session is carried, L2F is simply transporting
   HDLC frames.  The two PPP endpoints can negotiate higher-level
   features, such as reliable link, compression, multi-link, or
   encryption.  These features then operate between the two PPP
   endpoints (the dial-in client on one end, and the Home Gateway on the
   other), with L2F continuing to simply ship HDLC frames back and
   forth.

   For similar reasons, PPP echo requests, NCP configuration
   negotiation, and even termination requests, are all simply tunneled
   HDLC frames.

5.2 Termination

   As L2F simply tunnels link-layer frames, it does not detect frames
   like PPP TERMREQ.  L2F termination in these scenarios is driven from
   a protocol endpoint; for instance, if a Home Gateway receives a
   TERMREQ, its action will be to "hang up" the PPP session.  It is the
   responsibility of the L2F implementation at the Home Gateway to
   convert a "hang up" into an L2F_CLOSE action, which will shut down
   client's session in the tunnel cleanly.  L2F_CLOSE_WHY and
   L2F_CLOSE_STR may be included to describe the reason for the
   shutdown.

5.3 Extended Authentication

   L2F is compatible with both PAP and CHAP protocols.  SLIP does not
   provide authentication within the protocol itself, and thus requires
   an ASCII exchange of username and password before SLIP is started.
   L2F is compatible with this mode of operation as well.

   One-time password cards have become very common.  To the extent the
   NAS can capture and forward the one-time password, L2F operation is
   compatible with password cards.  For the most general solution, an
   arbitrary request/response exchange must be supported.  In an L2F
   environment, the protocol must be structured so that the NAS can
   detect the apparent identity of the user and establish a tunnel
   connection to the Home Gateway, where the arbitrary exchange can
   occur.



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


5.4 MNP4 and Apple Remote Access Protocol

   L2F appears compatible with Apple's ARAP protocol.  Its operation
   under L2F has not been described simply because this experimental RFC
   does not have a corresponding implementation of such operation.

5.5 Operation of IP and UDP

   L2F tries to be self-describing, operating at a level above the
   particular media over which it is carried.  However, some details of
   its connection to media are required to permit interoperable
   implementations.  This section describes the issues which have been
   found when operating L2F over IP and UDP.

   L2F uses the well-known UDP port 1701 [4].  The entire L2F packet,
   including payload and L2F header, is sent within a UDP datagram.  The
   source and destination ports are the same (1701), with demultiplexing
   being achieved using CLID values.  It is legal for the source IP
   address of a given CLID to change over the life of a connection, as
   this may correspond to a peer with multiple IP interfaces responding
   to a network topology change.  Responses should reflect the last
   source IP address for that CLID.

   IP fragmentation may occur as the L2F packet travels over the IP
   substrate.  L2F makes no special efforts to optimize this.  A NAS
   implementation MAY cause its LCP to negotiate for a specific MRU,
   which could optimize for NAS environments in which the MTUs of the
   path over which the L2F packets are likely to travel have a
   consistent value.

6.0 Acknowledgments

   L2F uses a packet format inspired by GRE [5].  Thanks to Fred Baker
   for consultation, Dave Carrel for consulting on security aspects, and
   to Paul Traina for philosophical guidance.

7.0 References

   [1] Romkey, J., "A Nonstandard for Transmission of IP Datagrams over
       Serial Lines: SLIP", RFC 1055, June 1988.

   [2] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
       RFC 1661, July 1994.

   [3] Simpson, W., "PPP in HDLC-like Framing", STD 51,, RFC 1662,
       July 1994.