idnits 2.17.1 draft-ietf-pppext-conversion-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC-1661]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1998) is 9385 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DayDreamer' is mentioned on line 2, but not defined == Missing Reference: 'RFC-1990' is mentioned on line 76, but not defined == Missing Reference: 'RFC-2125' is mentioned on line 77, but not defined ** Downref: Normative reference to an Informational RFC: RFC 1547 Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W A Simpson [DayDreamer] 3 Internet Draft 4 expires in six months August 1998 6 PPP with Framing Conversion 7 draft-ietf-pppext-conversion-01.txt 9 Status of this Memo 11 This document is an Internet-Draft. Internet Drafts are working doc- 12 uments of the Internet Engineering Task Force (IETF), its Areas, and 13 its Working Groups. Note that other groups may also distribute work- 14 ing documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months, and may be updated, replaced, or obsoleted by other documents 18 at any time. It is not appropriate to use Internet Drafts as refer- 19 ence material, or to cite them other than as a ``working draft'' or 20 ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 24 Directories on: 26 ftp.is.co.za (Africa) 27 nic.nordu.net (Northern Europe) 28 ftp.nis.garr.it (Southern Europe) 29 ftp.ietf.org (Eastern USA) 30 ftp.isi.edu (Western USA) 31 munnari.oz.au (Pacific Rim) 33 Distribution of this memo is unlimited. 35 Copyright Notice 37 Copyright (C) William Allen Simpson (1997-1998). All Rights 38 Reserved. 40 Abstract 42 The Point-to-Point Protocol (PPP) [RFC-1661] provides a standard 43 method for transporting multi-protocol datagrams over point-to-point 44 links. This document describes the use of converters for bridging 45 PPP encapsulated packets between links with different framing tech- 46 niques. 48 1. Introduction 50 Some forms of bridging convert PPP encapsulated packets between dif- 51 ferent framing formats. It is the responsibility of the bridge to do 52 all stuffing and framing conversions. 54 At one time, it was expected that such conversions would be rela- 55 tively rare, and would only occur between asynchronous and syn- 56 chronous links [RFC-1662]. Unfortunately, external converters have 57 since appeared that bridge PPP from bit-synchronous HDLC to bit- 58 synchronous X.25, bit-synchronous X.25 to bit-synchronous Frame 59 Relay, bit-synchronous to octet-synchronous HDLC and Frame Relay, and 60 that are daisy-chained together in sundry combinations. 62 Also, the interpretation of "high speed" has changed over time. When 63 the PPP specifications were originally written, high speed generally 64 began at 57.6 Kbps, and was assumed for most synchronous links. 65 Since then, implementors have applied the [RFC-1662] low speed recom- 66 mendations to link speeds of up to 622 Mbps, squeezing out the last 67 small percentage of performance. This ambiguity has resulted in 68 unanticipated proliferation of options. 70 Moreover, some implementors have interpreted the term "recognizable" 71 to mean that the implementation merely supports negotiation of an 72 option, although that option has no effect on the interface. This 73 misunderstanding has resulted in undesirable interaction of options. 75 Furthermore, the (committee designed) multi-link specification 76 [RFC-1990] introduced many LCP options, and the bandwidth allocation 77 protocol(s) [RFC-2125] introduced link management complexity, that 78 are not compatible with the conversion requirements of [RFC-1662]. 80 This specification describes the current practices necessary for 81 avoiding the failure modes of this ensuing cacaphony of options, and 82 numerous interoperability problems that have been identified with 83 bridging converters. 85 1.1. Terminology 87 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 88 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 89 described in [RFC-2119]. 91 2. Passive Converters 93 A "passive" converter relies on outside PPP peers to conduct all LCP 94 negotiation. The converter inspects any LCP Configure-Acks passing 95 through it, and dynamically updates its configuration accordingly. 96 For "Asynchronous to Synchronous Conversion" [RFC-1662], this tech- 97 nique works with only a minimum of implementation effort. 99 However, when more than one conversion is attempted, or when options 100 might be legitimately negotiated by the PPP peers that are not recog- 101 nized by intermediate converters, passive conversion can inexplicably 102 fail. The link will successfully pass Link Establishment phase, but 103 appear to be disfunctional to the user. This does not meet PPP 104 requirements [RFC-1547]. 106 For example, two converters might be placed back-to-back: 108 async --- converter --- sync --- converter --- async 110 The async implementations could negotiate LCP framing-related options 111 (such as Address-and-Control-Field-Compression, FCS-Alternatives, or 112 another vendor specific option), without any guarantee that the 113 intervening converters can successfully receive the resulting modi- 114 fied frames. Because LCP is extensible, there can be no requirement 115 that any converter recognize and interpret all current and future 116 options. 118 This problem also applies to a single converter, where the "high 119 speed" sync implementation requests "low speed" options that mimic an 120 async implementation. But, there is no guarantee that the interven- 121 ing converter will recognize the option and can successfully receive 122 the resulting modified frames. 124 Therefore, the use of passive converters is deprecated. For backward 125 compatibility, bit-synchronous and octet-synchronous implementations 126 SHOULD respond to the LCP Async-Control-Character-Map (ACCM) Configu- 127 ration Option with a Configure-Ack, but MUST NOT include the ACCM in 128 a Configure-Request. 130 3. Active Converters 132 An "active" converter intercepts LCP configuration negotiation, while 133 allowing other PPP traffic to pass unimpeded. The converter becomes 134 the PPP LCP peer on each interface, examining all LCP Link Configura- 135 tion packets (Configure-Request, Configure-Ack, Configure-Nak, and 136 Configure-Reject). 138 Inappropriate or ineffectual options that arrive in LCP Configure- 139 Requests (such as ACCM from synchronous links or ACFC from variable- 140 framed links) indicate that another (passive) converter is present in 141 the path. Separate LCP negotiation on each interface prevents these 142 options from propagating incorrect configuration information. 144 However, when explicitly configured on a per option basis, an imple- 145 mentation MAY negotiate ineffectual options seen in a Configure-Nak, 146 and MAY respond to such requested options with a Configure-Ack. 148 4. Multi-Link Conversion 150 Framing conversion requires that each link be paired with another 151 single link. Multi-link negotiation is not compatible with active or 152 passive converters. 154 Instead, all PPP multi-link capable devices MUST terminate all PPP 155 traffic on each interface. That is, multi-link devices are consid- 156 ered routers, and MUST conform to the requirements for routers. 158 Security Considerations 160 This specification introduces no known security vulnerabilities. 162 Acknowledgements 164 Dirk Van Aken provided useful critiques of earlier versions of this 165 document. 167 References 169 [RFC-1547] Perkins, D., "Requirements for an Internet Standard 170 Point-to-Point Protocol", Carnegie-Mellon University, 171 (June 1989) December 1993. 173 [RFC-1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", 174 STD-51, DayDreamer, July 1994. 176 [RFC-1662] Simpson, W., Editor, "PPP in HDLC-like Framing", STD-51, 177 DayDreamer, July 1994. 179 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 180 Requirement Levels", BCP-14, Harvard University, March 181 1997. 183 Contacts 185 Comments about this document should be discussed on the ietf- 186 ppp@merit.edu mailing list. 188 This document was reviewed by the Point-to-Point Protocol Working 189 Group of the Internet Engineering Task Force (IETF). The working 190 group can be contacted via the current chair: 192 Karl Fox 193 Ascend Communications 194 655 Metro Place South, Suite 370 195 Dublin, Ohio 43017 197 karl@Ascend.com 199 Questions about this document can also be directed to: 201 William Allen Simpson 202 DayDreamer 203 Computer Systems Consulting Services 204 1384 Fontaine 205 Madison Heights, Michigan 48071 207 wsimpson@UMich.edu 208 wsimpson@GreenDragon.com (preferred) 210 Full Copyright Statement 212 Copyright (C) William Allen Simpson (1997-1998). All Rights 213 Reserved. 215 This document and translations of it may be copied and furnished to 216 others, and derivative works that comment on or otherwise explain it 217 or assist in its implementation may be prepared, copied, published 218 and distributed, in whole or in part, without restriction of any 219 kind, provided that the above copyright notice and this paragraph are 220 included on all such copies and derivative works. However, this doc- 221 ument itself may not be modified in any way, except as required to 222 translate it into languages other than English. 224 This document and the information contained herein is provided on an 225 "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES, EXPRESS OR 226 IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF 227 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 228 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.