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