[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
Network Working Group                           W A Simpson [DayDreamer]
Internet Draft
expires in six months                                        August 1998

                            PPP LCP CallBack                             -
                  draft-ietf-pppext-callback-ds-02.txt                   |

Status of this Memo

   This document is an Internet-Draft.  Internet Drafts are working doc- -
   uments of the Internet Engineering Task Force (IETF), its Areas, and
   its Working Groups.  Note that other groups may also distribute work-
   ing documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months, and may be updated, replaced, or obsoleted by other documents
   at any time.  It is not appropriate to use Internet Drafts as refer-
   ence 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:

      ftp.is.co.za (Africa)
      nic.nordu.net (Northern Europe)                                    |
      ftp.nis.garr.it (Southern Europe)                                  |
      ftp.ietf.org (Eastern USA)                                         |
      ftp.isi.edu (Western USA)                                          |
      munnari.oz.au (Pacific Rim)

   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) William Allen Simpson (1992-1994, 1996-1998).  All
   Rights Reserved.


   The Point-to-Point Protocol (PPP) [RFC-1661] provides a standard
   method for transporting multi-protocol datagrams over point-to-point
   links.  PPP defines an extensible Link Control Protocol (LCP) for
   establishing, configuring, and testing the data-link connection.
   This document defines the CallBack option.

Simpson                   expires in six months                 [Page i]

DRAFT                         PPP CallBack                   August 1998

1.  Introduction

   CallBack is a facility that permits a call originating party (caller)
   to request that the call terminating party (callee) originate a sub-
   sequent call in the reverse direction.  This might be used for many
   diverse purposes, such as savings on toll charges.

   Unlike most PPP operations, CallBack is not a strictly peer-to-peer
   service.  The semantics of CallBack differ depending on which peers
   are the caller and callee.

   The successful operation of CallBack requires a significant amount of
   administrative configuration.  Such configuration might include per-
   mission to use the CallBack facility, locations and time of day for
   which the CallBack is allowed, and time delays prior to and following

   -  The callee might disconnect quickly, and return the call as soon
      as possible.

   -  CallBack might be used to re-establish service at later time, when
      sufficient additional traffic arrives at the callee to warrant
      another connection.

   -  When the user is roaming, CallBack might be used to register a
      variable contact location.

   Such policy considerations are beyond the scope of this specifica-

1.1.  Terminology

   In this document, the key words "MAY", "MUST", "MUST NOT", "recom-    +
   mended", and "SHOULD", are to be interpreted as described in          +
   [RFC-2119].                                                           +

2.  Additional LCP Configuration Options

   The Configuration Option format and basic options are already defined
   for LCP [RFC-1661].                                                   |

   Up-to-date values of the LCP Option Type field are specified in the   |
   most recent "Assigned Numbers" [RFC-1700].  This document concerns
   the following values:

Simpson                   expires in six months                 [Page 1]

DRAFT                         PPP CallBack                   August 1998

      13      CallBack

2.1.  CallBack


      This Configuration Option provides a method for an implementation
      to request a dial-up peer to call back.  By default, no call back

      Nota Bene:

         Like all such PPP options, this indicates that the installation
         has the capability to be called back.  If the option is
         rejected, link operation continues normally [1 page 39].

         Moreover, acknowlegement of the option does not require that
         the peer take any additional action [ibid].

      A peer that Configure-Acks this option SHOULD Configure-Request
      the Authentication-Protocol option.  The user information learned
      during authentication can be used to determine the user location,
      or limit a user to certain locations, or merely to determine whom
      to bill for the service.

      When CallBack is successfully negotiated, and the Authentication
      phase is complete, the peer will eventually enter the Link Termi-
      nation phase.  At the conclusion of the Link Termination phase,
      the peer will disconnect the link.

      Then, after a suitable interval of time, the peer will re-
      establish the link.  When mutual authentication is desired, the
      implementation SHOULD Configure-Request the Authentication-
      Protocol option as it answers the call.

      Implementation Notes:

         The delay times between calls are characteristics of the call-
         ing environment, and MUST be configured on a per user and loca-
         tion basis.

         Since the information is redundant, the implementation is not
         required to Configure-Request the CallBack option as it answers
         the call.  However, inclusion MUST NOT affect the operation of
         the protocol.

Simpson                   expires in six months                 [Page 2]

DRAFT                         PPP CallBack                   August 1998

   A summary of the CallBack Option format is shown below.  The fields
   are transmitted from left to right.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     -
   |     Type      |    Length     |   Operation   |  Message ...




      >= 3


      The Operation field is one octet and indicates the contents of the
      Message field.

      Up-to-date values of the CallBack Operation field are specified in
      the most recent "Assigned Numbers" [2].  This document defines the
      following values:

      0       Identification from the Authentication phase will be used
              for a database lookup to determine the callback parame-
              ters.  The Message field is not present.

              This method is required to be supported in all conformant

      1       Dialing string, the format and contents of which assumes
              configuration knowledge of the specific device that is
              making the callback.

              A North American example might be: 10222,,,(800)555-1212.

              This method is commonly supported, but suffers from fre-
              quent configuration error.

      2       Location identifier, which may or may not be human read-
              able, used together with Authentication phase information
              for a database lookup to determine the callback parame-

      3       E.164 number.  The implementation converts this to an
              appropriate signalling sequence.

Simpson                   expires in six months                 [Page 3]

DRAFT                         PPP CallBack                   August 1998

      4       X.500 distinguished name, used together with Authentica-
              tion phase information for a database lookup to determine
              the callback parameters.

      5       E.165 number.  The implementation converts this to an
              appropriate signalling sequence.


      The Message field is zero or more octets, and its general contents
      are determined by the Operation field.  The actual format of the
      information is site or application specific, and a robust imple-
      mentation SHOULD support the field as undistinguished octets.  The
      size is determined from the Length field.

      It is intended that only an authorized user will have correct site
      specific information to make use of the CallBack.  The codifica-
      tion of the range of allowed usage of this field is beyond the
      scope of this specification.

Security Considerations

   Unauthenticated and unrestricted use of CallBack could lead to a sig-
   nificant denial of service, or excessive service charges.  Authenti-
   cation is required to be supported.  In addition, it is recommended
   that an implementation be capable of logging usage.

Changes from RFC-1570                                                    +

   LCP Configuration Options were removed to separate documents.         +

   Minor reorganization.  Abbreviations have been expanded.  Additional  +
   Rationale has been added.                                             +

Simpson                   expires in six months                 [Page 4]

DRAFT                         PPP CallBack                   August 1998


   Special thanks to Ascend Communications for providing computing
   resources and network access support for writing this specification.


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

   [RFC-1700]  Reynolds, J.K., Postel, J.B., "Assigned Numbers", STD-2,  |
               USC/Information Sciences Institute, October 1994.         |

   [RFC-2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP-14, Harvard University, March    |

Simpson                   expires in six months                 [Page 5]

DRAFT                         PPP CallBack                   August 1998


   Comments about this document should be discussed on the ietf-
   ppp@merit.edu mailing list.

   This document was reviewed by the Point-to-Point Protocol Working     |
   Group of the Internet Engineering Task Force (IETF).  The working
   group can be contacted via the current chair:

      Karl Fox
      Ascend Communications
      3518 Riverside Drive  Suite 101
      Columbus, Ohio  43221

          karl@Ascend.com                                                -

   Questions about this document can also be directed to:

      William Allen Simpson
      Computer Systems Consulting Services
      1384 Fontaine
      Madison Heights, Michigan  48071

          wsimpson@GreenDragon.com (preferred)

Simpson                   expires in six months                 [Page 6]

DRAFT                         PPP CallBack                   August 1998

Full Copyright Statement                                                 +

   Copyright (C) William Allen Simpson (1992-1994, 1996-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 doc- +
   ument itself may not be modified in any way, except as required to    +
   translate it into languages other than English.                       +

   This document and the information contained herein is provided on an  +
   "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES, EXPRESS OR   +

Simpson                   expires in six months                 [Page 7]