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

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


                      PPP with Framing Conversion
                  draft-ietf-pppext-conversion-01.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 (1997-1998).  All Rights
   Reserved.

Abstract

   The Point-to-Point Protocol (PPP) [RFC-1661] provides a standard
   method for transporting multi-protocol datagrams over point-to-point
   links.  This document describes the use of converters for bridging
   PPP encapsulated packets between links with different framing tech-
   niques.




Simpson                   expires in six months                 [Page i]


DRAFT                    PPP Framing Conversion              August 1998


1.  Introduction

   Some forms of bridging convert PPP encapsulated packets between dif-
   ferent framing formats.  It is the responsibility of the bridge to do
   all stuffing and framing conversions.

   At one time, it was expected that such conversions would be rela-
   tively rare, and would only occur between asynchronous and syn-
   chronous links [RFC-1662].  Unfortunately, external converters have
   since appeared that bridge PPP from bit-synchronous HDLC to bit-
   synchronous X.25, bit-synchronous X.25 to bit-synchronous Frame
   Relay, bit-synchronous to octet-synchronous HDLC and Frame Relay, and
   that are daisy-chained together in sundry combinations.

   Also, the interpretation of "high speed" has changed over time.  When
   the PPP specifications were originally written, high speed generally
   began at 57.6 Kbps, and was assumed for most synchronous links.
   Since then, implementors have applied the [RFC-1662] low speed recom-
   mendations to link speeds of up to 622 Mbps, squeezing out the last
   small percentage of performance.  This ambiguity has resulted in
   unanticipated proliferation of options.

   Moreover, some implementors have interpreted the term "recognizable"
   to mean that the implementation merely supports negotiation of an
   option, although that option has no effect on the interface.  This
   misunderstanding has resulted in undesirable interaction of options.

   Furthermore, the (committee designed) multi-link specification
   [RFC-1990] introduced many LCP options, and the bandwidth allocation
   protocol(s) [RFC-2125] introduced link management complexity, that
   are not compatible with the conversion requirements of [RFC-1662].

   This specification describes the current practices necessary for
   avoiding the failure modes of this ensuing cacaphony of options, and
   numerous interoperability problems that have been identified with
   bridging converters.


1.1.  Terminology

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








Simpson                   expires in six months                 [Page 1]


DRAFT                    PPP Framing Conversion              August 1998


2.  Passive Converters

   A "passive" converter relies on outside PPP peers to conduct all LCP
   negotiation.  The converter inspects any LCP Configure-Acks passing
   through it, and dynamically updates its configuration accordingly.
   For "Asynchronous to Synchronous Conversion" [RFC-1662], this tech-
   nique works with only a minimum of implementation effort.

   However, when more than one conversion is attempted, or when options
   might be legitimately negotiated by the PPP peers that are not recog-
   nized by intermediate converters, passive conversion can inexplicably
   fail.  The link will successfully pass Link Establishment phase, but
   appear to be disfunctional to the user.  This does not meet PPP
   requirements [RFC-1547].

   For example, two converters might be placed back-to-back:

      async --- converter --- sync --- converter --- async

   The async implementations could negotiate LCP framing-related options
   (such as Address-and-Control-Field-Compression, FCS-Alternatives, or
   another vendor specific option), without any guarantee that the
   intervening converters can successfully receive the resulting modi-
   fied frames.  Because LCP is extensible, there can be no requirement
   that any converter recognize and interpret all current and future
   options.

   This problem also applies to a single converter, where the "high
   speed" sync implementation requests "low speed" options that mimic an
   async implementation.  But, there is no guarantee that the interven-
   ing converter will recognize the option and can successfully receive
   the resulting modified frames.

   Therefore, the use of passive converters is deprecated.  For backward
   compatibility, bit-synchronous and octet-synchronous implementations
   SHOULD respond to the LCP Async-Control-Character-Map (ACCM) Configu-
   ration Option with a Configure-Ack, but MUST NOT include the ACCM in
   a Configure-Request.


3.  Active Converters

   An "active" converter intercepts LCP configuration negotiation, while
   allowing other PPP traffic to pass unimpeded.  The converter becomes
   the PPP LCP peer on each interface, examining all LCP Link Configura-
   tion packets (Configure-Request, Configure-Ack, Configure-Nak, and
   Configure-Reject).




Simpson                   expires in six months                 [Page 2]


DRAFT                    PPP Framing Conversion              August 1998


   Inappropriate or ineffectual options that arrive in LCP Configure-
   Requests (such as ACCM from synchronous links or ACFC from variable-
   framed links) indicate that another (passive) converter is present in
   the path.  Separate LCP negotiation on each interface prevents these
   options from propagating incorrect configuration information.

   However, when explicitly configured on a per option basis, an imple-
   mentation MAY negotiate ineffectual options seen in a Configure-Nak,
   and MAY respond to such requested options with a Configure-Ack.


4.  Multi-Link Conversion

   Framing conversion requires that each link be paired with another
   single link.  Multi-link negotiation is not compatible with active or
   passive converters.

   Instead, all PPP multi-link capable devices MUST terminate all PPP
   traffic on each interface.  That is, multi-link devices are consid-
   ered routers, and MUST conform to the requirements for routers.


Security Considerations

   This specification introduces no known security vulnerabilities.


Acknowledgements

   Dirk Van Aken provided useful critiques of earlier versions of this
   document.


References

   [RFC-1547]  Perkins, D., "Requirements for an Internet Standard
               Point-to-Point Protocol", Carnegie-Mellon University,
               (June 1989) December 1993.

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

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

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



Simpson                   expires in six months                 [Page 3]


DRAFT                    PPP Framing Conversion              August 1998


Contacts

   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
      655 Metro Place South,  Suite 370
      Dublin, Ohio  43017

          karl@Ascend.com

   Questions about this document can also be directed to:

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

          wsimpson@UMich.edu
          wsimpson@GreenDragon.com (preferred)


Full Copyright Statement

   Copyright (C) William Allen Simpson (1997-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
   IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



Simpson                   expires in six months                 [Page 4]