rfc2341.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,585 行 · 第 1/5 页

   (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.





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


   [4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
       October 1994.

   [5] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing
       Encapsulation (GRE)", RFC 1701, October 1994.

8.0 Security Considerations

   Security issues are discussed in Section 3.1.

9.0 Authors' Addresses

   Tim Kolar
   Cisco Systems
   170 West Tasman Drive
   San Jose CA 95134-1706

   EMail: [e-mail]


   Morgan Littlewood
   Cisco Systems
   170 West Tasman Drive
   San Jose CA 95134-1706

   EMail: [e-mail]


   Andy Valencia
   Cisco Systems
   170 West Tasman Drive
   San Jose CA 95134-1706

   EMail: [e-mail]

















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


9.0  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this