idnits 2.17.1 draft-ietf-pppext-ether-00.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-19) 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 9379 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 -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-ffff' Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 3 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 in Ether-like Framing 7 draft-ietf-pppext-ether-00.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 (1998). All Rights Reserved. 39 Abstract 41 The Point-to-Point Protocol (PPP) [RFC-1661] provides a standard 42 method for transporting multi-protocol datagrams over point-to-point 43 links. This document describes the use of ethernet-like framing for 44 PPP encapsulated packets. 46 1. Introduction 48 This specification provides for framing over both bit-oriented and 49 octet-oriented synchronous links, and asynchronous links with 8 bits 50 of data and no parity. These links MUST be full-duplex, but MAY be 51 either dedicated or circuit-switched. 53 Some protocols expect error free transmission, and either provide 54 error detection only on a conditional basis, or do not provide it at 55 all. PPP uses the Ethernet 32-bit Frame Check Sequence for error 56 detection. This is commonly available in hardware implementations, 57 and a software implementation is provided in [RFC-1662]. 59 1.1. Terminology 61 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 62 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 63 described in [RFC-2119]. 65 To remain consistent with standard Internet practice, and avoid con- 66 fusion for people used to reading RFCs, all binary numbers in the 67 following descriptions are in Most Significant Bit to Least Signifi- 68 cant Bit order, from Most Significant Byte to Least Significant Byte, 69 reading from left to right, unless otherwise indicated. Note that 70 this is contrary to ISO and ITU practice, which orders bits as trans- 71 mitted (network bit order). Keep this in mind when comparing this 72 document with the other documents. 74 2. Physical Layer Requirements 76 The only absolute requirement imposed by PPP is the provision of a 77 bi-directional full-duplex circuit, either dedicated (permanent) or 78 frame-switched, that can operate in either a bit-synchronous, or 79 octet-synchronous mode, transparent to PPP Data Link Layer frames. 81 Interface Format 83 PPP presents an octet interface to the physical layer. There is 84 no provision for sub-octets to be supplied or accepted. 86 Transmission Rate 88 PPP does not impose any restrictions regarding transmission rate, 89 other than that of the particular DTE/DCE interface. 91 Control Signals 93 PPP does not require the use of control signals. When available, 94 using such signals can allow greater functionality and perfor- 95 mance. Implications are discussed in [RFC-1662]. 97 2.1. Transmission Considerations 99 The definition of various encodings is the responsibility of the 100 DTE/DCE equipment in use, and is outside the scope of this speci- 101 fication. 103 3. The Data Link Layer 105 This specification uses the principles, terminology, and frame 106 structure described in [IEEE-802?]. 108 The purpose of this specification is not to document what is 109 already standardized in [IEEE-802?]. Instead, this document 110 attempts to give a concise summary and point out specific options 111 and features used by PPP. 113 3.1. Frame Header 115 This specification describes the PPP Protocol encapsulation. 116 These fields are transmitted from left to right. 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Length | PPP Protocol | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Information* | Padding* | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | 32-bit FCS | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 The PPP Protocol field and the following Information and Padding 127 fields are described in the Point-to-Point Protocol Encapsulation 128 [RFC-1661]. 130 3.2. Modification of the Basic Frame 132 The Link Control Protocol can negotiate modifications to the basic 133 frame structure. This is not compatible with ethernet-like fram- 134 ing. 136 Address-and-Control-Field-Compression 138 Since the Address and Control fields are not present, Address- 139 and-Control-Field-Compression cannot affect the frame format. 141 FCS-Alternatives 143 Since ethernet-like framing requires a 32-bit FCS, FCS- 144 Alternatives cannot affect the frame format. 146 In general, framing-related LCP Configuration Options are not rec- 147 ognizable, and are not acceptable for negotiation. The implemen- 148 tation MUST NOT send ineffectual options in a Configure-Request, 149 and SHOULD respond to such requested options with a Configure- 150 Reject. See [RFC-ffff] for details. 152 3.3. Modification of the Basic Packet 154 The Link Control Protocol can negotiate modifications to the basic 155 packet structure. These are transparent to Frame Relay. 157 Protocol-Field-Compression 159 The fixed header aligns the PPP Information field on a 32-bit 160 boundary. The implementation MUST respond with a Configure- 161 Reject. 163 Self-Describing-Padding 165 Negotiation of Self-Describing-Padding to a 4-byte multiple is 166 required. 168 4. Configuration Details 170 The standard LCP configuration defaults apply to ethernet-like 171 framing, except that 32-bit FCS is assumed (instead of 16-bit 172 FCS). 174 The following Configuration Options are recommended: 176 Magic Number 177 No Address and Control Field Compression 178 No Protocol Field Compression 179 Link Quality Monitoring 180 Self Describing Padding 182 Security Considerations 184 This specification introduces no known security vulnerabilities. 186 Acknowledgements 188 PPP using a simple non-HDLC framing was first proposed by Peter 189 Lothberg (Sprint). 191 References 193 [RFC-1661] Simpson, W., Editor, "The Point-to-Point Protocol 194 (PPP)", STD-51, DayDreamer, July 1994. 196 [RFC-1662] Simpson, W., Editor, "PPP in HDLC-like Framing", 197 STD-51, DayDreamer, July 1994. 199 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 200 Requirement Levels", BCP-14, Harvard University, March 201 1997. 203 [RFC-ffff] Simpson, W., "PPP with Framing Conversion", work in 204 progress. 206 Contacts 208 Comments about this document should be discussed on the ietf- 209 ppp@merit.edu mailing list. 211 This document was reviewed by the Point-to-Point Protocol Working 212 Group of the Internet Engineering Task Force (IETF). The working 213 group can be contacted via the current chair: 215 Karl Fox 216 Ascend Communications 217 655 Metro Place South, Suite 370 218 Dublin, Ohio 43017 220 karl@Ascend.com 222 Questions about this document can also be directed to: 224 William Allen Simpson 225 DayDreamer 226 Computer Systems Consulting Services 227 1384 Fontaine 228 Madison Heights, Michigan 48071 230 wsimpson@UMich.edu 231 wsimpson@GreenDragon.com (preferred) 233 Full Copyright Statement 235 Copyright (C) William Allen Simpson (1998). All Rights Reserved. 237 This document and translations of it may be copied and furnished 238 to others, and derivative works that comment on or otherwise 239 explain it or assist in its implementation may be prepared, 240 copied, published and distributed, in whole or in part, without 241 restriction of any kind, provided that the above copyright notice 242 and this paragraph are included on all such copies and derivative 243 works. However, this document itself may not be modified in any 244 way, except as required to translate it into languages other than 245 English. 247 This document and the information contained herein is provided on 248 an "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES, 249 EXPRESS OR IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY 250 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 251 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR 252 A PARTICULAR PURPOSE.