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]
