HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 06:37:19 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Sat, 02 Mar 1996 14:08:57 GMT ETag: "361b43-2f79-31385679" Accept-Ranges: bytes Content-Length: 12153 Connection: close Content-Type: text/plain Network Working Group Joel M. Halpern Internet Draft Newbridge Networks Inc. Expires in six months September 1994 PPP LCP Option for Data Encapsulation Selection draft-ietf-pppext-dataencap-03.txt Status of this Memo This document is a submission to the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list. Distribution of this memo is unlimited. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document defines a method for negotiating the encapsulation to be used for the transfer of data by PPP. It applies only to links for which there exists a "nominal" data encapsulation other than PPP. Joel M. Halpern expires in six months [Page i] DRAFT Data Encapsulation Selection September 1994 1. Introduction PPP is defined in the base specification [1] as a set of encapsulations (syntax) and state machines (semantics). The use of this combination results in the robust negotiation of options and transmission of data over Point-to-Point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. In recent years, several wide-area technologies with multi-point non-broadcast characteristics have developed. For each of these, data encapsulation syntax and operational semantics have been developed within the IETF ([2], [3], [4], [5]). The syntax used in each case was developed to meet a broad range of requirements. This syntax is herein referred to as the "nominal" encapsulation. As work with these technologies has advanced, the desire for parameter negotiation and additional capabilities has become clear. Different techniques have been used in different cases. For X.25, for example, the solution was to use PPP over separate circuits from other encapsulations. In the Frame-Relay case, that was considered insufficient. In particular, there was a desire to make use of the powerful PPP state machine and negotiation mechanism over Frame Relay circuits operating with previously defined syntax. Also, there was a desire to make the full power of the PPP machinery available to Frame Relay users. The first step in doing this was to define how to carry PPP | negotiation frames over Frame Relay. As the document on this [6] was discussed, it became clear that there was a further issue. The same encapsulation used to carry PPP negotiation frames is also used to carry PPP data frames. The question then arises as to the form of inter-operation. It is clearly desirable, when practical, that stations use uniform encapsulation. The first step towards resolving this was taken in the PPP | specifications for individual link technologies. As specified, for | example in [6], when a PPP protocol NCP is negotiated, the data transfer takes place using the PPP data encapsulation for that NCP. This gives strong operation of the PPP NCP and data transfer mechanisms. For any protocol whose related NCP has not been negotiated, data can be exchanged using the "nominal" encapsulation. This document defines an LCP option which, when negotiated, allows data to be transferred in the link "nominal" encapsulation even after the protocol NCP has been negotiated. Joel M. Halpern expires in six months [Page 1] DRAFT Data Encapsulation Selection September 1994 2. Nominal-Data-Encapsulation Description The LCP Nominal-Data-Encapsulation Configuration Option negotiates the use of the link nominal data encapsulation for NCP configured data, rather than the usual PPP encapsulation. If LCP reaches the Opened state without this option, the PPP protocol encapsulation is used for any protocol whose NCP is in the Opened state. As with all LCP options, use of this option is at the discretion of the implementation and operator. A node cannot force another node to use an option, and correct operation of the link is expected to continue without the option, although the performance might be less than optimal. Alternatively, such a node could open the LCP, but refuse to perform any NCP negotiations, so as to prevent the usage of any data encapsulations other than the nominal. Or, further, such a node could, after opening the LCP, close it again to indicate a desire NOT to communicate under the circumstances. These behaviors allow one to support the range of goals, including | full operation of PPP over Frame Relay (as given in [6]), and support for minimal parameter negotiation in addition to RFC 1490 support. A summary of the Nominal-Data-Encapsulation Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 14 Length 2 Joel M. Halpern expires in six months [Page 2] DRAFT Data Encapsulation Selection September 1994 3. Incompatibilities The PPP LCP Protocol-Reject MUST not be generated, since the nominal protocols will not be recognized by PPP. The PPP LCP Protocol-Field-Compression option MUST NOT be used, since ambiguities might result. This option is incompatible with NCP options which affect the data transfer syntax. Generally, any NCP option which would change the way the data is sent for that NCP cannot be used if the Nominal- Data-Encapsulation option has been negotiated. Some examples of facilities which MUST NOT be used: - the Bridging CP option for Bridge LAN ID. - the Compression CP, and any compression protocols defined for use by PPP. - the IP CP option for header compression. - the IPX CP option for header compression. Other NCP options SHOULD be carefully examined before implementation of this option, and proper operation is not guaranteed. 4. Loss of State There is a potential problem of undetected loss of shared state, as a result of the interaction between a PPP NCP and the use of nominal data encapsulation. When nominal encapsulation is used, either because the NCP has not been negotiated, or because the Nominal- Data-Encapsulation was negotiated, there is the possibility for invisible loss of shared state. If the two sides have agreed to use the LCP Nominal-Data- Encapsulation option, then they will be exchanging data using an encapsulation which is not recognized by PPP. If the "remote" unit is then transparently reset or replaced, it could choose to send data without initiating any LCP (or NCP) negotiation. Since it would use the same data format, communication would appear to be taking place properly, when in fact the shared state does not exist. This problem affects LCP shared state even in the absence of the LCP Nominal-Data-Encapsulation Configuration Option, since the nominal Joel M. Halpern expires in six months [Page 3] DRAFT Data Encapsulation Selection September 1994 encapsulation is used for any protocols for which no NCP has been negotiated. Thus, shared LCP state can be lost, even when no NCPs have been negotiated. The use of the Nominal-Data-Encapsulation option causes the problem to apply to shared NCP state as well. This includes such attributes as: - address assignment for IP, IPX, AppleTalk, etc. - routing protocol negotiation. - broadcast suppression. Virtually every NCP negotiation of naming or which affects choice of traffic over the link is subject to the problem of undetected loss of shared state. Joel M. Halpern expires in six months [Page 4] DRAFT Data Encapsulation Selection September 1994 Security Considerations As outlined in the section on Loss of State, the use of the LCP Nominal-Data-Encapsulation option leaves the systems open to certain undetected restart or replacement scenarios. In particular, the strength of the identity associated with any initial authentication protocol is weakened, since there is the possibility of replacement of the remote system transparently. Said replacement includes redirection of the underlying communications technology. References [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP), RFC 1548, 1993 December. [2] Piscitello, D.; Lawrence, J. Transmission of IP datagrams over the SMDS Service, RFC 1209, 1991 March [3] Bradley, T.; Brown, C.; Malis, A. Multiprotocol Interconnect over Frame Relay, RFC 1490, 1993 July. [4] Malis, A.; Robinson, D.; Ullmann, R. Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode, RFC 1356, 1992 August [5] Heinanen, J. Multiprotocol Encapsulation over ATM Adaptation Layer 5, RFC 1483, 1993 July [6] Simpson, W. A. PPP in Frame Relay, Internet Draft Acknowledgments Joel M. Halpern expires in six months [Page 5] DRAFT Data Encapsulation Selection September 1994 Chair's Address The working group can be contacted via the current chair: Fred Baker Advanced Computer Communications 315 Bollay Drive Santa Barbara, California 93117 EMail: fbaker@acc.com Author's Address Questions about this memo can also be directed to: Joel M. Halpern Newbridge Networks Inc. 593 Herndon Parkway Herndon, VA 22070-5241 +1 703 708-5954 EMail: jhalpern@newbridge.com Joel M. Halpern expires in six months [Page 6] DRAFT Data Encapsulation Selection September 1994 Table of Contents 1. Introduction .......................................... 1 2. Nominal-Data-Encapsulation ............................ 2 3. Incompatibilities ..................................... 3 4. Loss of State ......................................... 3 SECURITY CONSIDERATIONS ...................................... 5 REFERENCES ................................................... 5 ACKNOWLEDGEMENTS ............................................. 5 CHAIR'S ADDRESS .............................................. 6 AUTHOR'S ADDRESS ............................................. 6