idnits 2.17.1 draft-ietf-pppext-dataencap-03.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-26) 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 135: '... Protocol-Reject MUST not be generated...' RFC 2119 keyword, line 138: '...mpression option MUST NOT be used, sin...' RFC 2119 keyword, line 146: '... of facilities which MUST NOT be used:...' RFC 2119 keyword, line 157: '...ther NCP options SHOULD be carefully e...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The PPP LCP Protocol-Reject MUST not be generated, since the nominal protocols will not be recognized by PPP. -- 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 (September 1994) is 10816 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) ** Obsolete normative reference: RFC 1548 (ref. '1') (Obsoleted by RFC 1661) ** Obsolete normative reference: RFC 1490 (ref. '3') (Obsoleted by RFC 2427) ** Obsolete normative reference: RFC 1483 (ref. '5') (Obsoleted by RFC 2684) -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Joel M. Halpern 2 Internet Draft Newbridge Networks Inc. 3 Expires in six months September 1994 5 PPP LCP Option for Data Encapsulation Selection 6 draft-ietf-pppext-dataencap-03.txt 8 Status of this Memo 10 This document is a submission to the Point-to-Point Protocol Working 11 Group of the Internet Engineering Task Force (IETF). Comments should 12 be submitted to the ietf-ppp@merit.edu mailing list. 14 Distribution of this memo is unlimited. 16 This document is an Internet Draft. Internet Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its Areas, 18 and its Working Groups. Note that other groups may also distribute 19 working documents as Internet Drafts. 21 Internet Drafts are draft documents valid for a maximum of six 22 months. Internet Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use Internet 24 Drafts as reference material or to cite them other than as a 25 ``working draft'' or ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 29 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 30 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 32 Abstract 34 The Point-to-Point Protocol (PPP) [1] provides a standard method for 35 transporting multi-protocol datagrams over point-to-point links. 37 This document defines a method for negotiating the encapsulation to 38 be used for the transfer of data by PPP. It applies only to links 39 for which there exists a "nominal" data encapsulation other than PPP. 41 1. Introduction 43 PPP is defined in the base specification [1] as a set of 44 encapsulations (syntax) and state machines (semantics). The use of 45 this combination results in the robust negotiation of options and 46 transmission of data over Point-to-Point links. PPP defines an 47 extensible Link Control Protocol (LCP) for establishing, configuring, 48 and testing the data-link connection. 50 In recent years, several wide-area technologies with multi-point 51 non-broadcast characteristics have developed. For each of these, 52 data encapsulation syntax and operational semantics have been 53 developed within the IETF ([2], [3], [4], [5]). The syntax used in 54 each case was developed to meet a broad range of requirements. This 55 syntax is herein referred to as the "nominal" encapsulation. 57 As work with these technologies has advanced, the desire for 58 parameter negotiation and additional capabilities has become clear. 59 Different techniques have been used in different cases. For X.25, 60 for example, the solution was to use PPP over separate circuits from 61 other encapsulations. 63 In the Frame-Relay case, that was considered insufficient. In 64 particular, there was a desire to make use of the powerful PPP state 65 machine and negotiation mechanism over Frame Relay circuits operating 66 with previously defined syntax. Also, there was a desire to make the 67 full power of the PPP machinery available to Frame Relay users. 69 The first step in doing this was to define how to carry PPP 70 | negotiation frames over Frame Relay. As the document on this [6] was 71 discussed, it became clear that there was a further issue. The same 72 encapsulation used to carry PPP negotiation frames is also used to carry 73 PPP data frames. The question then arises as to the form of 74 inter-operation. It is clearly desirable, when practical, that stations 75 use uniform encapsulation. 77 The first step towards resolving this was taken in the PPP 78 | specifications for individual link technologies. As specified, for 79 | example in [6], when a PPP protocol NCP is negotiated, the data transfer 80 takes place using the PPP data encapsulation for that NCP. This gives 81 strong operation of the PPP NCP and data transfer mechanisms. For any 82 protocol whose related NCP has not been negotiated, data can be exchanged 83 using the "nominal" encapsulation. 85 This document defines an LCP option which, when negotiated, allows 86 data to be transferred in the link "nominal" encapsulation even after 87 the protocol NCP has been negotiated. 89 2. Nominal-Data-Encapsulation 91 Description 93 The LCP Nominal-Data-Encapsulation Configuration Option negotiates 94 the use of the link nominal data encapsulation for NCP configured 95 data, rather than the usual PPP encapsulation. If LCP reaches the 96 Opened state without this option, the PPP protocol encapsulation 97 is used for any protocol whose NCP is in the Opened state. 99 As with all LCP options, use of this option is at the discretion 100 of the implementation and operator. A node cannot force another 101 node to use an option, and correct operation of the link is 102 expected to continue without the option, although the performance 103 might be less than optimal. 105 Alternatively, such a node could open the LCP, but refuse to 106 perform any NCP negotiations, so as to prevent the usage of any 107 data encapsulations other than the nominal. Or, further, such a 108 node could, after opening the LCP, close it again to indicate a 109 desire NOT to communicate under the circumstances. 111 These behaviors allow one to support the range of goals, including 112 | full operation of PPP over Frame Relay (as given in [6]), and support 113 for minimal parameter negotiation in addition to RFC 1490 support. 115 A summary of the Nominal-Data-Encapsulation Configuration Option 116 format is shown below. The fields are transmitted from left to 117 right. 119 0 1 120 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Type | Length | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 Type 127 14 129 Length 131 2 133 3. Incompatibilities 135 The PPP LCP Protocol-Reject MUST not be generated, since the nominal 136 protocols will not be recognized by PPP. 138 The PPP LCP Protocol-Field-Compression option MUST NOT be used, since 139 ambiguities might result. 141 This option is incompatible with NCP options which affect the data 142 transfer syntax. Generally, any NCP option which would change the 143 way the data is sent for that NCP cannot be used if the Nominal- 144 Data-Encapsulation option has been negotiated. 146 Some examples of facilities which MUST NOT be used: 148 - the Bridging CP option for Bridge LAN ID. 150 - the Compression CP, and any compression protocols defined for use 151 by PPP. 153 - the IP CP option for header compression. 155 - the IPX CP option for header compression. 157 Other NCP options SHOULD be carefully examined before implementation 158 of this option, and proper operation is not guaranteed. 160 4. Loss of State 162 There is a potential problem of undetected loss of shared state, as a 163 result of the interaction between a PPP NCP and the use of nominal 164 data encapsulation. When nominal encapsulation is used, either 165 because the NCP has not been negotiated, or because the Nominal- 166 Data-Encapsulation was negotiated, there is the possibility for 167 invisible loss of shared state. 169 If the two sides have agreed to use the LCP Nominal-Data- 170 Encapsulation option, then they will be exchanging data using an 171 encapsulation which is not recognized by PPP. If the "remote" unit 172 is then transparently reset or replaced, it could choose to send data 173 without initiating any LCP (or NCP) negotiation. Since it would use 174 the same data format, communication would appear to be taking place 175 properly, when in fact the shared state does not exist. 177 This problem affects LCP shared state even in the absence of the LCP 178 Nominal-Data-Encapsulation Configuration Option, since the nominal 179 encapsulation is used for any protocols for which no NCP has been 180 negotiated. Thus, shared LCP state can be lost, even when no NCPs 181 have been negotiated. The use of the Nominal-Data-Encapsulation 182 option causes the problem to apply to shared NCP state as well. This 183 includes such attributes as: 185 - address assignment for IP, IPX, AppleTalk, etc. 187 - routing protocol negotiation. 189 - broadcast suppression. 191 Virtually every NCP negotiation of naming or which affects choice of 192 traffic over the link is subject to the problem of undetected loss of 193 shared state. 195 Security Considerations 197 As outlined in the section on Loss of State, the use of the LCP 198 Nominal-Data-Encapsulation option leaves the systems open to certain 199 undetected restart or replacement scenarios. 201 In particular, the strength of the identity associated with any 202 initial authentication protocol is weakened, since there is the 203 possibility of replacement of the remote system transparently. Said 204 replacement includes redirection of the underlying communications 205 technology. 207 References 209 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP), RFC 210 1548, 1993 December. 212 [2] Piscitello, D.; Lawrence, J. Transmission of IP datagrams over 213 the SMDS Service, RFC 1209, 1991 March 215 [3] Bradley, T.; Brown, C.; Malis, A. Multiprotocol Interconnect 216 over Frame Relay, RFC 1490, 1993 July. 218 [4] Malis, A.; Robinson, D.; Ullmann, R. Multiprotocol 219 Interconnect on X.25 and ISDN in the Packet Mode, RFC 1356, 220 1992 August 222 [5] Heinanen, J. Multiprotocol Encapsulation over ATM Adaptation 223 Layer 5, RFC 1483, 1993 July 225 [6] Simpson, W. A. PPP in Frame Relay, Internet Draft 227 Acknowledgments 228 Chair's Address 230 The working group can be contacted via the current chair: 232 Fred Baker 233 Advanced Computer Communications 234 315 Bollay Drive 235 Santa Barbara, California 93117 237 EMail: fbaker@acc.com 239 Author's Address 241 Questions about this memo can also be directed to: 243 Joel M. Halpern 244 Newbridge Networks Inc. 245 593 Herndon Parkway 246 Herndon, VA 22070-5241 248 +1 703 708-5954 250 EMail: jhalpern@newbridge.com 251 Table of Contents 253 1. Introduction .......................................... 1 255 2. Nominal-Data-Encapsulation ............................ 2 257 3. Incompatibilities ..................................... 3 259 4. Loss of State ......................................... 3 261 SECURITY CONSIDERATIONS ...................................... 5 263 REFERENCES ................................................... 5 265 ACKNOWLEDGEMENTS ............................................. 5 267 CHAIR'S ADDRESS .............................................. 6 269 AUTHOR'S ADDRESS ............................................. 6