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]